Jump to content


  • Content count

  • Joined

  • Last visited

Community Reputation

33 Good

About X0R

  • Rank

Profile Information

  • Gender
  • Location
    Manitoba, Canada
  • Interests
    !Coop !SystemsAutomation !AI !VideoGames !SystemicGames !SandboxGames !SimulationGames !ARMA3 !KSP !MSFX !DCS !Paramotoring !Python/C/Go/ArmaSqf

Recent Profile Visitors

268 profile views
  1. @=VG= Kavelenko the right direction is that which works & it is a crappy runway, just not a hard one;)
  2. Su'uP

    Indeed, though I usually crash trying to do creatively dumb shit like trying to land in creatively dumb places;) And by way 'too high',I meant, being high, not elevation high...;/
  3. Su'uP

    @Risiko94 it's more the later;) , funny how that works huh, the best encryption it seems is that which resides in plain sight, appreciate the attempt;)
  4. Su'uP

    @=VG= SemlerPDX Hey, I go by 'zor', some call me 'x o' & my favourite, when Spanish speakers call me 'WHORE', not even kidding, I guess 'x' is read as 'wh' or sth, cya.
  5. Su'uP

    @Risiko94 [OCCAM'S RAZOR is your best friend - trust your Google-fu]
  6. @=VG= keed A touch of Negative Throttle & Pitch Up....
  7. PR PiP Scopes

    True, a core requirement of mine was that 'pip' provide superior zoom while incurring minimal resolution loss, using a multiple post processing layers, which is why it looks as good as it does, given the level of zoom, and it is a d3d overlay where the original textures are actually being re-drawn multiple times. Unfortunately not, like melon said, it uses performance intensive post processing to magnify already drawn textures with minimal resolution loss, it can't draw anything that's not already in the viewport. Best case you get variable zoom scopes for different weapons. But it is indeed like most things in PR,an illusion of an equivalent feature integrated into the engine of similar games, like thermals for example.
  8. Su'uP

    Hi, Name's u5+RW8ISPJS6BLujxh/UBus1DLHAYEAXDtfk/6axrp8=, atm, i go by X0R. [I'm the dude playing the dude, disguised as another dude] Been playing PR a long-long while, but only 'recently' jumped on the forums & @=VG= Fastjack suggested i make formal introductions a 'while#monthsAgo' back, so hi. I'm good at just about everything but great at nothing, because i don't stick with any kit or asset long enough to be OP, though i'll more than likely end up being your pilot, i'm always chill, sometimes high & take nothing short of absolute stupidity seriously, so excuse me if i laugh my way to a fiery death, on occasion, it's just how i am. Not to worry though, i also fly my best when i'm high, so flip a coin when u hop in, i'll either wooooo u or u know crash & burn cos I'm way too high;) I mostly play Arma 3 now, but i've played with most of you for a lot longer than you know & U keep PR && VG alive,so stay chill & cya around. =ShackTac= u5+RW8ISPJS6BLujxh/UBus1DLHAYEAXDtfk/6axrp8=
  9. PR PiP Scopes

    I'm meant to have posted a server side script for randomized logic i talked about a couple of months ago, and a few people asked for a sitrep,So here it is... I've decide to expand the scope of the script(s) to extend to a number interlinked subsystems to make meaningful changes to coop, the original intent was too trivial in scope(spawner+randomiser), i.e it's become somewhat of a server-side mini-mod & taking proportionally longer, as i've also been busy with other (more useful) stuff, such as that, showcased in the video. I won't hype nothing, but i'll post the server side scripts when they're good & ready, figured, i might as well go big or go home with it, atm, it's one of only 3 things on my trello. TLDR; i'm killing time till time kills me, with hours of mindless debugging, when i get time;) PiP scopes in the Half Life Insurgency Mod were awesome, I recently worked on a PiP mod for Arma 3 & i figured, PR deserves one too;) *it's an external shader, using a similar method tr.exe(now integrated into PRLauncher) originally used to actualise 3D scopes & thermals in PR, but using d3d*dll instead of an external process, for the curious few. *video purposely recorded on a crappy old lenovo notebook w/ integrated graphics to showcase performance, while recording, at maxQ & 8xAA, locked @25fps for stability.
  10. So i revised & updated [REVISED][UPDATED] Tips Rarely 'Tipped' , cos i had some time away from home, so i figure i might as well bump it with a post that kills the myth of short/bad/difficult runways and steep slopes that trans isn't 'down with'.
  11. I understood what you meant, but if as you suggest you define a *_randomaiasset_type_* template in the gpo, it should be easy to do, difficulty only arises if it weren't. Either way, whatever you define in the server.zip gpo will be spawnable. Though i must add, unlike for other entities, placement of bipods must be utterly precise, so it would require <coord>+<rotation> from the bf2editor, so it would just use a different set of randomization coordinate arrays to all other assets. It should already be defined in the gpo,i.e consider a tank on jabal, if spawned in a randomly defined spawn point, coordinate only,it's existing rotation will be applied, which works just fine for existing map objects as they already have rotation defined,although I'll certainly add the bearing/heading component of rotation to the coordinate pool to make spawns more adaptable, like alleyway spawns. So for any object template you add to the gpo i suggest you create a dummy spawn without coordinates with rotation defined. Bipods are a unique case, so there's two ways you can deal with them, either decide which bipods spawned in the gpo actually spawn, or you can spawn 4 bipods in the gpo & have them spawn at any one of N positions+rotation defined in a list, so the purpose of such a list would solely be to randomize the location all bipods defined in gpo would spawn at, instead of simply defining where they spawn at to begin with. I'm fundamentally lazy , so when choosing a solution i prefer that which provides the best performance but also allows the least maintenance, so it was a performance, convenience & ease of use consideration that made me prefer this approach, just like you can easily modify AI configs, you should easily be able to modify asset spawn, asset type & spawn locations for any given map without needing to know much of anything about the internal workings or without having to load a map in the editor.
  12. I've been testing out a few approaches with deriving the 'Y' component of a coordinate from the height map for a randomly chosen coordinate,having trouble with that but beyond that, it should all be doable with perhaps a different but still effective approach, that features most of what you state above, except perhaps spawning assets not defined on gpo, the real power of python in bf2 is in rcon_invoke() which pretty much lets you do anything but is fairly locked down, infact almost everything in the PR UI is actually an rcon command, done through rcon_invoke(), see attachments & https://classic-battlefield-modding.fandom.com/wiki/BF2_Object_Reference . realityserver.py, pretty much controls rcon_invoke privileges, so the best solution is a combination of an internal & external scripts with some in game logic done externally,where possible. Occam's Razor, “the simplest solution is almost always the best.” I've yet to figure out how to do the 'xxx_randomaiasset_type1_xxx' object spawn reliably,without the server crashing, so I'm putting that at the bottom of my to do list, given it's an 'easteregg',I'll see what i can do about that once everything else is done. Regardless script solution will feature the following : //Assuming additional ability to modify(not add or remove from) the gpo of server.zip -*Scripted object spawner, highly unstable, working on it. -Randomization using a coordinate array that can easily be modified(added to && removed from by anyone with out having to navigate bf2editor) -'rcon position' was added in 1.50 update, should allow anyone to get coordinates for respective maps to populate randomization coordinates array, with coordinates being used logically, with respect to the type of object & distance to nearest CP, we wouldn't wanna spawn a tank inside a building on a coordinate intended for infantry spawn now would we. -Randomization logic that's not hard coded but instead applied logically, based on nothing more than coordinates defined for any given map, i.e provide coordinates for a given map & map will be randomized with respect to AI assets, spawn points & statics. -Config based object spawner, spawns entities defined in script on next map run at designated coordinates,or if coordinate array is defined, at a randomly chosen coordinate from array. ~(obj, minSpawn, maxSpawn, a, p, r, <x, y, z> || <x, y, z>array), simply specify an unreasonably long minSpawn to prevent respawn. ##OBJECTS MUST BE DEFINED IN MAP## i.e don't spawn an f15 on muttrah, just don't. -Randomized Spawn Points, pr does allow addition of new spawn points which are automatically added to a randomized spawn point pool , but I'm sure we all know that's a load of crock, spawn points are far too few & internal randomization is too lacking, so I'll use the config to further randomize spawn point coordinates with respect to their nearest CP, should work on every map, using an external spawn coordinate array. -Randomize Static Emplacements. -Randomized AI Assets, maybe they have a tank and a few techies, or maybe a dozen tanks, & 6 mortars who knows,.. -AI Asset spawn probability, lets you define spawn probability of an asset whose sub-string is specified, i.e (tank, 0.6), and the next randomization cycle has a 60% probability of making the tank spawn. -Randomized AI rally points, will mostly spawn farther to CP to complement spawn points as players tend to camp at a distance. -Randomized AI spawn delay. -Randomized Vehicle Depot Spawn Probability, forces you into a map where you have all the vehicles in the world, but no ability to repair them, no running back to mommy, i figure it forces players to be more conservative with their assets & perhaps for once use the combat engineer kit for something other than mines. -Won't require server restart for changes to script to take effect, changes should take effect on next map. -External script will apply logical config randomization every N hours to all maps, for which randomization coordinates are defined. -*Randomize AI behavior with in a defined scope, extent of randomization is hard to define,I'm figuring that out. The list above contains only things I've figured out how to do , using two server-side scripts, internal for server-side logic & external script for dynamic config modification, which will also alter the internal script's run-time behavior. *denotes conceptually WIP,i.e i haven't figured out how to do that reliably. Awesome, I'll send some your way when i get some time. Exactly, hence why I'm using a coordinate array to which one can easily make additions, as you can now retrieve coordinates for any map pos using 'rcon position'. Simplest to do, Volod will soon be running around like everyone else, And see above, no need for map editors, once it's done, anyone can just submit a list of coordinates for the spawn pool for a given map using normal PR to get coordinates. In summary, once i get everything above working & tested I'll post script & video here, no deadlines though, I've got a job & school so, y'know. realityevents - rcon commands.py realityrally.py
  13. Gotcha, I've got a few ideas on how to randomize spawn points on mission start, the tricky part is randomizing successive spawns after mission is loaded, I'll start with mission start randomization first though.
  14. Certainly flight physics as well, wouldn't we all like to take off in 50m< on irregular terrain in a jet like the bots do... But i stand corrected, i could have been clearer. ------------------------------------------------------------------------------------------------------------------------------------------ https://www.moddb.com/mods/sw33tsp0t BF2 Total War Realism Mod https://www.youtube.com/watch?v=TvPK6EKQkMQ Video which adequately illustrates the scope of the AI config for the mod above. https://www.moddb.com/mods/bf2-sp-128-professional-ai BF2 SP 128 Professional AI Both mods linked above feature quiet interesting AI configs, with decent results as shown in video, though i recommend you try both yourself, if you still happen to have bf2, or simply dissect & examine the config otherwise, i find both offer a superior single player experience, which would logically translate to coop, the configs for TWRM for instance could offer a known behavioral baseline around which PRBF2 AI configs could be optimized. ------------------------------------------------------------------------------------------------------------------------------------------ Regarding python spawner, have you considered defining the insurgent caches in the map config, perhaps replace one or two defined vehicles on a given map with a cache and then simply move/teleport the cache to any one of randomly selected coordinates or perhaps to a randomly selected CombatArea.<areaPoint> coordinate. It would be far simpler to implement, the rallypoint spawner can then be used to spawn rally points at random CombatArea.<areaPoint> coordinates surrounding(w/in 100m) cache coordinate. I don't know the extent of the insurgency logic you've implemented, so i'm just spitballing. -If i recall the add framework had a teleport script,which could be used to 'relocate' entities on map even without exact coordinates(i.e heading+distance+objPosition), you don't happen to have the old AdFramework files do you? -And are you using realityrally or realityspawner as basecode because both have cascading dependencies & use internal logic to spawn objects? The only other python spawning method I've identified is using rcon.invoke(), which can be used to spawn kits & so could certainly be used to spawn objects,given obj template is defined.
  15. Cheers guys, appreciate it. @=VG= Fastjack , I'll do that sometime.