=VG= XOR Posted February 28, 2020 at 10:44 PM Report Share Posted February 28, 2020 at 10:44 PM Hey there, so I've been playing PR for a long time, 8 years now, since i was 14 actually, i used to play PvP and I'd probably play more, but there are too many other things competing for my time to commit to a full round anymore - and I'm not one to just up and bail mid-game if I can help it. PR COOP, was always an adequate alternative,but repetitive & predictable with static emplacements & spawn points,to the extent where a simple duplication of an identical strategy in a previous round is all that is required to quickly win a round. As a matter of principle i never complain about things for which i have no solution, so what follows are tested suggestions & solutions to enhanced PR coop, eliminating some of the more nuanced complaints about coop through better game logic, ai configuration & server configuration, imho. I figured it's a new decade, i might as well create an account here on VG & reality-mod forum, given I'm still playing this damn game after all these years, and if nothing else, I'd hopefully have contributed something to the way people play PR. NUANCED WALL OF TEXT INCOMING... I've always avoided the tedium of repetition & boredom by playing as many roles & using as many varieties of assets as i can, occasionally taking a long break, while I've always mostly played Arma 3(6000hrs+), KSP, MSFX or Insurgency more so than PR. And what I've come to realize especially from playing Arma 3 more often now is PR Coop can be made better, with simple changes to server configuration or more precisely introduction of new game-play alterations by means of the tested methods below, i hope you indulge me in considering these suggestions with the function of making PR coop a more challenging & therefore more enjoyable experience, something it only ever truly was, at least for me, only when i got started with PR, nowadays PR to me is like tetris, i know all the pieces, where & how they go & i only ever loose or fuck up like when I'm distracted by my phone(which happens a lot) or bs irl. -Most of the suggestions below were functional on a private server i used to play on, server went under, but the methods remained, albeit only in thy head. 1.A new class of players, 'curators' (per designation for zeus in arma 3), permitted one command, '!switch', yes I'm volunteering & no I'm not looking for a legitimate excuse to kill volod ;). It's a role i believe can throw a wrench in the camping tactic that permeates coop,where bots do the same thing over & over again & players do the same in return. Granted PR doesn't even come close to having anything like Arma 3 zeus\highCommand, however having a player curate bot behavior, does not necessitate direct control, you can exercise emergent control; -build emplacements which bots will automatically occupy, -deny access to areas through mines & emplacements funneling player movement, -create a more extensive & randomized spawn network for bots through fobs & as SL -simply transporting bots manually from point a to point b other than on foot -strategic asset suppression to extend the effective life time of bots(i.e kill enemy CAS with AA/AT to let bots push up farther for example), -,..., basically render every strategy from spawn camping to hovering because there's no active AA emplacements to hunting known emplacement locations pointless, i think PR provides adequate command tools & systems to allow this to be a plausible strategy at the very least, i understand working with AI in general,even in Arma, let alone PR is an undesirable if not repugnant proposition to most people because they're not as responsive as people,which in my opinion is an unreasonable expectation to begin with, but taken for what they are, rudimentary behaviorally constrained reactive logic(trigger-constraint-action) & given you understand the limitations of the bots(see "aidefaultstrategies.ai, aibehaviours.ai, aipathfinding.ai" & Battlefield AI - Advanced Topics, then it's basically akin to playing an RTS, effectively a little explored nondescript game-mode in PR. And to be clear, i suggest an alternative to admins taking on this role, as i highly doubt given the temperament & patience it requires ENOUGH existing admins are willing to put in the effort, as it's as only ever as rewarding as your expectations & I'm guessing most will have too low or too high an expectation from this approach, and given the single command provided, which the AD framework allowed configuring, though I'm not sure about RealityAdmin, there's little risk to exploring new people for the role as not much authority comes with it, just !switch. And I've seen how admins switching to bot team, works in servers like SSG for instance, which is little more than trolling players imho & i understand that is a reasonable point of concern for this approach, but with a set of well defined rules similar to those that exist already & with the large extent to which VG is moderated, i don't think that's much of a concern. I've spent a lot of time configuring,modifying & testing ai behaviors in bf2 over the years as a consequence of my compulsive curiosity in the topic at large, if there's one thing I've learned,it's the simple fact that no amount of config changes will make the ai as challenging as they can be when their behavior is properly configured AND that behavior is systemically curated... 2.A few more server side scripts that i think ought to be included, with minor modifications if necessary, which I'm willing to make if called upon.My python isn't too bad ;p. https://projects.uturista.pt/bf2tech/index.php/Scripts:AntiBaseRape ^players, including myself do this a tad too much,especially muttrah,where the spawn point for shilka's & so on is technically a base... https://projects.uturista.pt/bf2tech/index.php/Scripts:AutoMap Or, MM_MapAutoSizer is more compatible with mapvotes from my experiencehttps://projects.uturista.pt/bf2tech/index.php/Scripts:MM_MapAutoSizer ^i understand there's already a map randomize active, but from what i understand, it's sole intent is to avoid repetition & does not factor in the number of players. https://projects.uturista.pt/bf2tech/index.php/Scripts:OfftimePy ^for the rare occasion no admin is online https://projects.uturista.pt/bf2tech/index.php/Scripts:ThreatAndWorth ^i much like this approach to the existing point system,in the abstract, it pretty much means a tank killed by infantry earns-looses more points than a tank killed by a tank, you get the drift. https://projects.uturista.pt/bf2tech/index.php/Scripts:TK_punish_announcer ^makes known the serial tk'ers in our midst with autokick, I'm nothing of the sort, i only had 200tk's in 2019, thanks for that damn list btw acro. >I've played with all the above & i think they'd make fine additions to the coop server, if you so agree. I authored none of these, scripts just happened to be used for the bf2-pr dedi of some arma 3 unit with which i used to play with, now defunct. 3.I understand that opfor events are few & far between because of the need for custom map config changes for each map,but I've experimented with a reliable alternative approach using autobalance that makes bots playable for either faction on a map. With a 0% AI balance where all AI are grouped to one side, a servers side script to teamswitch players on init will be unnecessary provided max AI defined exceeds the number of possible number of players 40pV40b for instance, now with autobalance enabled the sides chosen flip logically with the first round on mission start always deferring to opfor & the flipping the bot faction on every subsequent run, which logically flips player faction respectively, so take kashan for example, iff on init players are bluefor, with autobalance enabled, !reload, will reload the mission with bots as bluefor & players autobalance switched to opfor., Autobalance is disabled for a good number of reasons, but AUTOBALANCE + COMPATIBLE MAPLIST//where bots can put up an effective fight on either side,i.e Kashan NOT Jabal, Kamisiyah NOT MuttrahStd/Large, etc.. generally any map/layer(ex. ,muttrah inf vs std/lrg) where there is no body of water to traverse & player faction doesn't initially occupy the majority of sectors is a valid map//. So if nothing else, such a config that doesn't require individual map modification is a valid means of having playable opfor, but more so, such a variance will increase the variety of playable factions in coop and implicitly increase replayability. Too many people have this notion of the 'evil' autobalance, like all things, properly understood & configured, it can be put to great use, just a thought i feel warrants serious consideration. Maybe have an Autobalanced second server for greater variance, where you alternate between bluefor & opfor sequentially on suitable maps, using !reload to swap teams based on, say, a vote, see what people prefer? Or simpler still since i understand the reason for a single server, have days where server runs autobalanced with a logically selected maplist. 4.Modified AI Behavior, using core configs instead of map configs, the more practical means of doing so, I've attempted to see what such modifications are currently active & most modifications comprise individual map config changes which complicates updates though generally not tedious if scripted i guess,but even that contrasts the fact that the most meaningful(as a consequence of outcome) changes to ai behavior can be made in the core ai config. And based on what I've seen, there seem to be little divergence between stock ai behavior & in game behavior on VG,so maybe it's high time changes to ai are made, here are a few suggestions & examples... -Why Bots Swim? Water Weights for Infantry, the reason why bots swim in the open instead of walking where appropriate, aisettings.setVehicleMods Infantery StandardWeights aiSettings.setVehicleMaterialCost Infantery Ground 1 aiSettings.setVehicleMaterialCost Infantery Road 1 aiSettings.setVehicleMaterialCost Infantery Shallows 1.1 aiSettings.setVehicleMaterialCost Infantery DeepWater 6 ,this default config makes sense on very few maps & is the reason bots swim on pavlovsk or jabal & remember, if bots swim, they can't use weapons,so setting the DeepWater weight to 1, same as ground & road, will make them swim when no roads or ground exists in direction of travel,deferring otherwise, when not, with the occasional exception to the case, as is the nature of weights. Such simple changes are the difference between 40 bots LOADED ON MAP & 40 bots COMBAT EFFECTIVE ON MAP, an important difference, dare i say. More Examples Below: For example under standardweights (running on foot) aiSettings.createBehaviourModifiers StandardWeights aiSettings.setBehaviourModifier Avoid 1.0 aiSettings.setBehaviourModifier MoveTo 1.0 aiSettings.setBehaviourModifier Idle 0.1 aiSettings.setBehaviourModifier Fire 7.5 aiSettings.setBehaviourModifier Special 3.0 aiSettings.setBehaviourModifier TakeCover 2.0 aiSettings.setBehaviourModifier Change 1.9 aiSettings.setBehaviourModifier Revive 3.0 Revive from 3.0 to 8.0, meaning medics will revive before they shoot. aiSettings.setVehicleDefaultBehaviour Infantery Idle to aiSettings.setVehicleDefaultBehaviour Infantery MoveTo So that if the bot has nothing else to do, it's default action will be to move to the next objective. if you change these lines in the mod's \AI\Aibehaviors.ai file: aisettings.setVehicleMods Plane StandardWeights aisettings.setVehicleMods Helicopter StandardWeights to use custom weights as show (These lines are separate sections for planes and Helis) aisettings.setVehicleMods Plane StandardWeights aisettings.setVehicleMods Helicopter HeliMoveWeights where this is what the Planes and Helis currently use: aiSettings.createBehaviourModifiers StandardWeights aiSettings.setBehaviourModifier Avoid 1.0 aiSettings.setBehaviourModifier MoveTo 1.0 aiSettings.setBehaviourModifier Idle 0.1 aiSettings.setBehaviourModifier Fire 7.5 aiSettings.setBehaviourModifier Special 3.0 aiSettings.setBehaviourModifier TakeCover 2.0 aiSettings.setBehaviourModifier Change 1.9 aiSettings.setBehaviourModifier Revive 3.0 aiSettings.setBehaviourModifier c4 1.0 aiSettings.setBehaviourModifier Special2 1.0 aiSettings.setBehaviourModifier Special3 1.0 aiSettings.setBehaviourModifier Random 1.0 aiSettings.setBehaviourModifier Triggerable 1.0 Avoid is set to a weight of only 1, compared to fire which is 7.5. Where weights, used to adjust the chance of a bot choosing a specific action. The following modification to Plane & Helicopter weights respectively for instance make bot aircraft's far more dangerous & effective, remember, Bot Aircraft are disallowed to players because they mostly have unlimited ammo, changes below make it rain & the 'avoid' weights for planes for instance, though specified as a 2D collision avoidance weight seem to additionally influence the tendency of bot planes to attempt evasion towards their base, where AA emplacements are usually active so, the effects cascade, every change cascades. //Commented Lines Signify Default Values aiSettings.createBehaviourModifiers PlaneWeights // aiSettings.setBehaviourModifier Avoid 0.0 aiSettings.setBehaviourModifier Avoid 7.5 // aiSettings.setBehaviourModifier MoveTo 1.0 aiSettings.setBehaviourModifier MoveTo 2.2 aiSettings.setBehaviourModifier Idle 0.01 // aiSettings.setBehaviourModifier Fire 1.5 aiSettings.setBehaviourModifier Fire 8.5 // aiSettings.setBehaviourModifier Special 1.0 aiSettings.setBehaviourModifier Special 3.0 //^none primary weapons such as grenades, rockets, bombs,etc... // aiSettings.setBehaviourModifier TakeCover 0.0 aiSettings.setBehaviourModifier TakeCover 2.0 // aiSettings.setBehaviourModifier Change 0.0 aiSettings.setBehaviourModifier Change 1.9 // aiSettings.setBehaviourModifier Revive 1.0 aiSettings.setBehaviourModifier Revive 3.0 //^it has this weird effect where it makes them more likely to stay close to each other aiSettings.setBehaviourModifier c4 1.0 // aiSettings.setBehaviourModifier Special2 1.0 aiSettings.setBehaviourModifier Special2 3.0 // aiSettings.setBehaviourModifier Special3 1.0 aiSettings.setBehaviourModifier Special3 3.0 aiSettings.setBehaviourModifier Random 1.0 aiSettings.setBehaviourModifier Triggerable 1.0 aiSettings.createBehaviourModifiers HeliMoveWeights // aiSettings.setBehaviourModifier Avoid 0.0 aiSettings.setBehaviourModifier Avoid 8.5 // aiSettings.setBehaviourModifier MoveTo 1.0 aiSettings.setBehaviourModifier MoveTo 5.0 aiSettings.setBehaviourModifier Idle 0.01 // aiSettings.setBehaviourModifier Fire 1.5 aiSettings.setBehaviourModifier Fire 8.5 // aiSettings.setBehaviourModifier Special 1.0 aiSettings.setBehaviourModifier Special 3.0 // aiSettings.setBehaviourModifier TakeCover 0.0 aiSettings.setBehaviourModifier TakeCover 4.0 aiSettings.setBehaviourModifier Change 2.5 // aiSettings.setBehaviourModifier Revive 1.0 aiSettings.setBehaviourModifier Revive 3.0 aiSettings.setBehaviourModifier c4 1.0 aiSettings.setBehaviourModifier Special2 1.0 aiSettings.setBehaviourModifier Special3 1.0 aiSettings.setBehaviourModifier Random 1.0 aiSettings.setBehaviourModifier Triggerable 1.0 So for the most part bots don't suck because 'bots', but because they're handicapped by design in their configuration, which considers few players going up against them, Essentially, given VG is for the most part exclusively a COOP server, perhaps it's time to stop using stock AI configs for better custom configs, because the default configs simply weren't designed with 40v40 Coop in mind, they were seemingly optimized for single player & at most for just a few players. In the mean time i think playing with bots can be made more interesting & challenging through systems & tools already in the game without looking to the devs or scripts, which as awesome as they are, lets be real, bots are a low priority subsystem in PR,with primary focus on PvP, at least where R-DEV is concerned,so maybe it's time to consider pragmatic solutions such as those specified above. Here's a great article on gamasutra about how game mechanics translates to replayability, https://www.gamasutra.com/view/feature/131468/replayability_part_2_game_.php , a good read. SORRY FOR THE WALL OF TEXT, but despite all these years of playing PR, CooP is still little more than a shooting gallery,despite almost all suggestions above being made possible because of existing Battlefield 2 subsystems at the core & improving CooP using these subsystems is rare to see, i strongly believe there's still a lot of unexplored potential ,i play coop not as alternative to deployment, but as a discrete experience unto itself, with different challenges & fun to be had, bots are SHOCKINGLY not people & having SHOCKINGLY good aim, that's unrealistic as most would say, just a different set of challenges so far as I'm concerned, where people are smart bots are fast, where people are fast bots are faster, simple as that, where as i think most players especially new ones play coop for little more than practice or just the 'shooting gallery' bit, which it unfortunately is atm, especially when population exceeds 15. So perhaps it's high time you reconsider how we fundamentally play PR CooP as opposed to how it could practically be played to a more rewarding extent, using some of the suggestion above, which I've made certain are practical & well tested & not merely things I'd like to see happen. And please note, this comes not, from a place of entitlement nor prejudice(against bots;)) but of frustration & boredom at maps i know too well & bots i understand too well. Cheers & Regards, X0R. 2 2 Quote Link to comment Share on other sites More sharing options...
=VG= Fastjack Posted February 28, 2020 at 11:17 PM Report Share Posted February 28, 2020 at 11:17 PM 15 minutes ago, X0R said: My python isn't too bad Here i stopped reading because that got my absolute attention. If i, would give you some basecodes (python) for a random rallypoint spawn mechanic (exist in PR but isn't used at all), could you modify it to =VG='s liking and create for us a randomcode for bot assets? The pythoncode was created for mappers, to put rallypoints_ (faction)_placebales_random on maps and the pythoncode choose RANDOMLY one or two of them. The same mechanic as the ammocachespawns on PR insurgency. If i would have THIS, we can play end of next month coop insurgency for PR. We could change ai (temperature values) serverside to get mapstrategies working because that's the main Problem of PR ai. There existing Things that are to HOT and that overrides good strategy by simple math calculations. My Question is also, you aware about the BFSP SinglePlayerForum ? 2 2 Quote Link to comment Share on other sites More sharing options...
=VG= XOR Posted February 28, 2020 at 11:52 PM Author Report Share Posted February 28, 2020 at 11:52 PM 35 minutes ago, =VG= Fastjack said: Here i stopped reading because that got my absolute attention. If i, would give you some basecodes (python) for a random rallypoint spawn mechanic (exist in PR but isn't used at all), could you modify it to =VG='s liking and create for us a randomcode for bot assets? The pythoncode was created for mappers, to put rallypoints_ (faction)_placebales_random on maps and the pythoncode choose RANDOMLY one or two of them. The same mechanic as the ammocachespawns on PR insurgency. If i would have THIS, we can play end of next month coop insurgency for PR. We could change ai (temperature values) serverside to get mapstrategies working because that's the main Problem of PR ai. There existing Things that are to HOT and that overrides good strategy by simple math calculations. Hi, pm me the script, I'm not not familiar with spawners beyond obj spawner templates, but given an example, I think i could come up with something. I'd rather you not have stopped reading tho;) 35 minutes ago, =VG= Fastjack said: My Question is also, you aware about the BFSP SinglePlayerForum ? Yea, it's home away from home Quote Link to comment Share on other sites More sharing options...
=VG= Fastjack Posted February 29, 2020 at 02:34 PM Report Share Posted February 29, 2020 at 02:34 PM About checked the rest of your post, you know what you talking about and is absolutely correct. The Weights system works like a priority system. Higher numbers = higher priority. It's the same as with the weapons.ai which kind of target got the weapons most attention. Important is also to check if other equipment in the kit could conflict with another one. Your post is about behaviours and how bots perform on a map by choosing the right decisions. Sofar i know is the TakeCover behaviour disabled but you can find it still in the vanilla game (so vanilla ai). I Hex Editor'ed the AIDLL once and i mean i saw a ***rem in front of the TakeCover ai feature. The bot ai behaviour TakeCover seems to not worked well in BF1942. The main reason was that the ai didn't knew what Cover was because not so much statics had an ai.template to tell the ai "Hey it's me COVER !!!" Also the placement of some statics on the map conflicted with the other one because of the cover and looking for cover values and cover positions etc. The main problem in PR is the strategicstrength values and temperature values of the soldiers, vehicles, weapons etc. are to disorganisated to work well with the SAI and strategies. Also ALL map ai's need some more info like ObjectTypeFlags in StrategicAreas to get a better dynamic ai that can be influenced with mapstrategies. 1 Quote Link to comment Share on other sites More sharing options...
=VG= Fastjack Posted February 29, 2020 at 07:34 PM Report Share Posted February 29, 2020 at 07:34 PM On 28.2.2020 at 11:44 PM, X0R said: remember, Bot Aircraft are disallowed to players because they mostly have unlimited ammo Afaik, it's forbidden for the players to use botvehicles because the flightphysics are different than from the player ones and bots aren't able to handle this player flightphysics. For excample, the bots would flip helicopters because they can handle the engine warmup or crash planes on airfields. Bots Auto refilling ammo over time because the can not land on airfields to rearm. Quote Link to comment Share on other sites More sharing options...
=VG= XOR Posted February 29, 2020 at 09:09 PM Author Report Share Posted February 29, 2020 at 09:09 PM 1 hour ago, =VG= Fastjack said: Afaik, it's forbidden for the players to use botvehicles because the flightphysics are different than from the player ones and bots aren't able to handle this player flightphysics. For excample, the bots would flip helicopters because the can handle the engine warmup or crash planes on airfields. Bots Auto refilling ammo over time because the can not land on airfields to rearm. 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. 1 Quote Link to comment Share on other sites More sharing options...
=VG= Fastjack Posted February 29, 2020 at 10:19 PM Report Share Posted February 29, 2020 at 10:19 PM I use for coop insurgency not a own pythoncode. I combined the gpm_coop and gpm_insurgency by adding to coop to load also insurgency at the same time. Quote import coop def init( ): coop.init( ) def deinit( ): coop.deinit( ) import insurgency def init( ): insurgency.init( ) def deinit( ): insurgency.deinit( ) With that, you get the whole insurgency python mechanic working for the ammocaches in coop. Additionally, i placed non-controlpoints StrategicAreas (SA's) around the map in areas where ammocache could spawn and are not to much in the open and also always placed on the navmesh. Also, what no one really knows is that such non controlpoint related SA's can be set as been takeable by both teams. It's a legacy code from BF1942 that still works in Battlefields 2 ai. You have to add the lines manually in the StrategicAreas.ai to each non_controlpoint related SA's. First number stands for the team (team1 and team2) and the second is a bolean that can be set to 0 or 1 (takeable/not takeable for that team) AiStrategicArea.SetTakeable 1 0/1 AiStrategicArea.SetTakeable 2 0/1 If you set the takeable status for both teams to 0, no team is able to capture the SA, theSAI will send bots over and over again to these SA. Also, you can give ownership to a specifiec strategic area to a team at round start by adding the following line to an. AiStartegicArea.SetSide 0 neutral AiStartegicArea.SetSide 1 owned by team 1 AiStartegicArea.SetSide 2 owned by team 2 Those non-cp SA's can be placed in the BF2 SingleplayerEditor. Right click on map, add StrategicArea, give it a name and change the size manually in 10 meter steps. Be carefull, you can accidently flip those StrategicAreas when you change the size in the wrong directions. Those SA's cant be selected anymore in the Editor after you placed it. You have to remove it manually from the StrategicAreas.ai I also modified the ammocache tweak by adding an ai.template to the ammocache (done via tmp.con in the map) and added a high temperature value to it because Tobias Karlson once said : Quote If I want the bots to attack a certain strategic area, I make sure that the flags for that strategic area are unique so that I can add modifiers that guarantee that that strategic area is the one with the highest temperature. The SA temperatures can also be Incredible raised by giving them ammocache a high value. I will also check the concept a old friend gave me years ago by adding a special vehicle category to the ammocache.ai (TTN's) temperaturetreenodes. About the Randonm Asset spawn script: It would be nice if we could adding of such an dynamic random spawnscript for some assets that are designed for bots (AI). So every round on a map would be complete different. Not knowing where the botmortars or where the enemy spg or tow emplacements spawns. The human team have to recon the map to get the positions. I also simulates ambushes made by the bot team. As you said, every round in coop plays out the same. In coop insurgency, every round plays different because of the random Events on the map. Quote Link to comment Share on other sites More sharing options...
=VG= XOR Posted March 1, 2020 at 10:38 AM Author Report Share Posted March 1, 2020 at 10:38 AM 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. 1 Quote Link to comment Share on other sites More sharing options...
=VG= Fastjack Posted March 1, 2020 at 12:12 PM Report Share Posted March 1, 2020 at 12:12 PM The spawnpoints get placed in the gpo, so by the guy who create the layer. The pythonscript should only choose which ones and how much of them spawns randomly. The spawnscript should work like this. Maximum number of active assets of each asset type at the same time. I dont wont that 10 botmortars randomly got choosen one day. Spawns should be randomly selected close to spawned ammocaches or captureable controlpoints. If one of these assets got destroyed it shouldn't respawn but a new spawn got selected in a specifiec distance to the ammocache/captureable controlpoint with a time delay I want the script that can handle more variety because i want to create random bipods, random spg's, random destroyable objects that simulate bombtraps simulated sniperspots etc. The script should choose assets that contain a part of the name like : xxx_randomaiasset_type1_xxx xxx_randomaiasset_type2_xxx xxx_randomaiasset_type3_xxx xxx_randomaiasset_type4_xxx xxx_randomaiasset_type5_xxx xxx_randomaiasset_type6_xxx With this Variety of of randomaiasset's it can happen that you play 49 rounds of coop insurgency against techies, bipods, spg's and 1 round against techies, bipods, spg's AND A TANK . That what i call Easteregg. Alone such an script is a breakthrough for coop at all. Dynamic coop gameplay. The human team have to explore the situation on the map and not this humanscripted gameplay each round as it currently is. We had once a guy here who was able to take control of whole lashkar with the mortars and he played the game in the way it has should to be. Not exploiting the remove/rebuild the mortar for reload exploit. He knew where the bots or where their asset spawned. Hardcore coop players know at roundstart where everything spawned or from where the bots coming. I think 75% of the community here knows where the botmortars spawns. At last Volod knows. Quote Link to comment Share on other sites More sharing options...
=VG= Melon Muncher Posted March 1, 2020 at 08:46 PM Report Share Posted March 1, 2020 at 08:46 PM If you make me an Aibehaviours I'll add it to the server and we can see if there's any noticeable changes. 1 3 Quote Link to comment Share on other sites More sharing options...
=VG= SemlerPDX Posted March 2, 2020 at 01:05 AM Report Share Posted March 2, 2020 at 01:05 AM By changing up the physical spawn points to even another building nearby I could imagine would be a lot of work, but a randomization with a number of choices would make it far more interesting for a lot of people! Quote Link to comment Share on other sites More sharing options...
=VG= STRONTIUM-DOG (Inactive Duty) Posted March 2, 2020 at 02:52 AM Report Share Posted March 2, 2020 at 02:52 AM 16 hours ago, X0R said: Gotcha, I've got a few ideas on how to randomize spawn points on mission start, 1 hour ago, =VG= SemlerPDX said: y changing up the physical spawn points to even another building nearby I could imagine would be a lot of work, but a randomization with a number of choices would make it far more interesting for a lot of people! Yer mannn i think randomising spawn points is a must, some players have spawns mapped out, and beat the adds using preemptive attacks. Its a lot of work adding spawns personally, but if the time can be taken to do so, the conflict can be enhanced much more. Maybe just now and then if map editors have the time. : ) Quote Link to comment Share on other sites More sharing options...
=VG= XOR Posted March 2, 2020 at 07:39 AM Author Report Share Posted March 2, 2020 at 07:39 AM 19 hours ago, =VG= Fastjack said: Maximum number of active assets of each asset type at the same time. I dont wont that 10 botmortars randomly got choosen one day. Spawns should be randomly selected close to spawned ammocaches or captureable controlpoints. If one of these assets got destroyed it shouldn't respawn but a new spawn got selected in a specifiec distance to the ammocache/captureable controlpoint with a time delay I want the script that can handle more variety because i want to create random bipods, random spg's, random destroyable objects that simulate bombtraps simulated sniperspots etc. The script should choose assets that contain a part of the name like : xxx_randomaiasset_type1_xxx xxx_randomaiasset_type2_xxx xxx_randomaiasset_type3_xxx xxx_randomaiasset_type4_xxx xxx_randomaiasset_type5_xxx xxx_randomaiasset_type6_xxx With this Variety of of randomaiasset's it can happen that you play 49 rounds of coop insurgency against techies, bipods, spg's and 1 round against techies, bipods, spg's AND A TANK . That what i call Easteregg. Alone such an script is a breakthrough for coop at all. Dynamic coop gameplay. The human team have to explore the situation on the map and not this humanscripted gameplay each round as it currently is. 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. 10 hours ago, =VG= Melon Muncher said: If you make me an Aibehaviours I'll add it to the server and we can see if there's any noticeable changes. Awesome, I'll send some your way when i get some time. 6 hours ago, =VG= SemlerPDX said: By changing up the physical spawn points to even another building nearby I could imagine would be a lot of work, but a randomization with a number of choices would make it far more interesting for a lot of people! 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'. 4 hours ago, =VG= STRONTIUM-DOG said: Yer mannn i think randomising spawn points is a must, some players have spawns mapped out, and beat the adds using preemptive attacks. Its a lot of work adding spawns personally, but if the time can be taken to do so, the conflict can be enhanced much more. Maybe just now and then if map editors have the time. : ) 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 1 1 Quote Link to comment Share on other sites More sharing options...
=VG= Fastjack Posted March 2, 2020 at 04:57 PM Report Share Posted March 2, 2020 at 04:57 PM Mmmmh, you must be a kind of DEV because me haven't access to your realityevents/realityrally links. But …. Keep your secret for you. Makes all a bit more interresting at all. Quote 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. No Problem, take your time. I'm happy at least that we have someone who can look into this. I started my coop insurgency gamemode project 10 years ago (seriously, that's the main reason why i am a Veterans-Gaming member). The first working coop insurgency round was on 31.07.2015. 2017, we had the first dedicated testserver up. We have time. 1 Quote Link to comment Share on other sites More sharing options...
=VG= Fastjack Posted March 2, 2020 at 07:25 PM Report Share Posted March 2, 2020 at 07:25 PM I tought more on a system where i can place all the xxx_randomaiassets_xxx in the GPO. For excample, i placed all ammocaches manually. Multiple times i set more than 300. For better explaination: The xxx_randomaiasset_type1_xxx doesnt exist yet. The xxx_ stands for a name of the asset and get replaced by the original name of the asset. Like This: The nl_bipod_alt would be cloned and renamed to nl_randomaiasset_type1_alt Now i clone the insrg_bipod and rename it to insrg_randomaiasset_type1 Now i place 99 nl_randomaiasset_type1_alt and only 1 insrg_randomaiasset_type1 When the pythoncode only checks for the middle part of the name, (randomaiasset_type1), i will have mostly of all rounds the nl_bipod_alt on the map spawned but one day ….. the insrg_bipod will spawn. Now, Imaging, if the insrg_bipod would be a tank! I would mostly have nl_bipods_alt spawned and one day a Tank. That's the reason why i want the script only looking for the part of the name. If it would check for the full name (like ammocache) i wouldn't get this variety. Another reason why the script should look like this is IS because the PR python mostly a created in this criterias. The reason why i want to place the randomaiassets manually is because i must be sure, that all asset get randomly spawned on the NAVMESH. Some bipods would also be placed on roof where or balconies where no navmesh is but that can be solved with "DONTALLOWEXIT" tweakline to prevent exiting. Sofar i understand you, if you let spawn assets like you wrote (via rcon invoke), you need a database with coordinates (x-y-z) for a good spawnplacement but what is with rotation? Also, to get the infos for the database, you have to place bipods on every nice Location on the map. So when all bipods already placed why creating a database when everything is already done? The advantage of your database system is you can add all time more bipods without modifying the map, so nobody needs to redownload it. That's cool. Same like ESAI. You can modify strategies on a map without touching the map. Exist there more advantages for your system like better performance or is the main PR python structured like you explained above? 1 Quote Link to comment Share on other sites More sharing options...
=VG= STRONTIUM-DOG (Inactive Duty) Posted March 3, 2020 at 02:37 AM Report Share Posted March 3, 2020 at 02:37 AM 18 hours ago, X0R said: Simplest to do, Volod will soon be running around like everyone else, Hahaha good hes the best spawn rapist, he can dump the camping gear now, boots and ammo only : ) 18 hours ago, X0R said: 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. Nice work : ) will add ambush spawns ASAP : ) Quote Link to comment Share on other sites More sharing options...
=VG= XOR Posted March 3, 2020 at 04:00 AM Author Report Share Posted March 3, 2020 at 04:00 AM 7 hours ago, =VG= Fastjack said: I tought more on a system where i can place all the xxx_randomaiassets_xxx in the GPO. For excample, i placed all ammocaches manually. Multiple times i set more than 300. For better explaination: The xxx_randomaiasset_type1_xxx doesnt exist yet. The xxx_ stands for a name of the asset and get replaced by the original name of the asset. Like This: The nl_bipod_alt would be cloned and renamed to nl_randomaiasset_type1_alt Now i clone the insrg_bipod and rename it to insrg_randomaiasset_type1 Now i place 99 nl_randomaiasset_type1_alt and only 1 insrg_randomaiasset_type1 When the pythoncode only checks for the middle part of the name, (randomaiasset_type1), i will have mostly of all rounds the nl_bipod_alt on the map spawned but one day ….. the insrg_bipod will spawn. Now, Imaging, if the insrg_bipod would be a tank! I would mostly have nl_bipods_alt spawned and one day a Tank. That's the reason why i want the script only looking for the part of the name. If it would check for the full name (like ammocache) i wouldn't get this variety. Another reason why the script should look like this is IS because the PR python mostly a created in this criterias. The reason why i want to place the randomaiassets manually is because i must be sure, that all asset get randomly spawned on the NAVMESH. Some bipods would also be placed on roof where or balconies where no navmesh is but that can be solved with "DONTALLOWEXIT" tweakline to prevent exiting. 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. 7 hours ago, =VG= Fastjack said: Sofar i understand you, if you let spawn assets like you wrote (via rcon invoke), you need a database with coordinates (x-y-z) for a good spawnplacement but what is with rotation? 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. 8 hours ago, =VG= Fastjack said: Also, to get the infos for the database, you have to place bipods on every nice Location on the map. So when all bipods already placed why creating a database when everything is already done? 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. 8 hours ago, =VG= Fastjack said: The advantage of your database system is you can add all time more bipods without modifying the map, so nobody needs to redownload it. That's cool. Same like ESAI. You can modify strategies on a map without touching the map. Exist there more advantages for your system like better performance or is the main PR python structured like you explained above? 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. 1 Quote Link to comment Share on other sites More sharing options...
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.