JamesTheClarke

A member of my community (Freghar) analysed this issue and came to the following conclusion, keep in mind we are no professionals and all of this info is mainly observation based: Someone asked me about ASR AI and spawning units through Zeus, so I thought I'd explain it more generally. Arma has this concept of "locality" where objects can be "local" to a specific client (server also has its internal client with ID 2, called __SERVER__) or to nobody/everybody (ID 0). Connected clients (players) start from ID 3. This specifies where the simulation is run - if an object is local to one client, the client has it "under control" and broadcasts its state to everyone else. This can be clearly seen when driving - Arma automatically makes vehicles (as in cars, tanks, helicopters, etc.) local to the driver. This is why "rubber banding" happens especially when people with bad connection / slow PC are driving - they have to simulate the vehicle and transmit it to the server, which then re-broadcasts it. Generally, a unit remains local on the client that created (spawned) it - through scripting or Zeus. This is not always wanted as virtually all AI will run on GM's client. When a client disconnects, the objects are automatically transferred under server, though disconnecting may be a bit of an inconvenience. As a simple proof of concept, I made a primitive Ares module: http://paste2.org/93tK6Z1V (On pastebin as this forum corrupts code blocks containing square brackets.) Embed it in your mission or use the ingame Ares Util->"Execute Code (Local)" functionality (and click the Modules zeus tab again) - you should now see a Freghar Ares category with a single item - using it on any group (or a singular soldier) will transfer the group under server (client ID 2). I like POCs that can be shown in pictures, so here's me using the #monitor admin command, first screenshot is after spawning units (traffic INbound to server, from my client), second is after running the Ares script (traffic OUTbound from server, to my client). http://i.imgur.com/SkCZHwT.jpg http://i.imgur.com/dHTE4hB.jpg As you can see, the difference is there. So how is this related to ASR AI? I don't know. Theoretically, nothing changes - Zeus spawned units are simply simulated by the client, but as long as both client and server have ASR AI installed andwith identical userconfig, it should work like vanilla (mmm, ... chocolate, ..*homer face*..). Of course, you might not want to run the AI on GM's client, hence the handy script. The transfer causes brief "red chains", but that's only very brief moment (few ms) - the chain icon stays there for multiple seconds, though. edit: WARNING - a fair bit of game logic resets for an object when it changes locality - ie. allowDamage is reset to true (immortal unit is made mortal) by changing locality, etc. - this however happens naturally (GM disconnect), so AI mods should be able to cope with it. In case you want to dig deeper (ie. assigning AI groups to player clients): https://community.bistudio.com/wiki/owner https://community.bistudio.com/wiki/setOwner (don't use) https://community.bistudio.com/wiki/groupOwner https://community.bistudio.com/wiki/setGroupOwner You can find the client IDs by iterating allPlayers and checking name (https://community.bistudio.com/wiki/name ) of each object (to find a specific player by name). Then use the owner command on the matched player object. TLDR: Unless you disable the ASR AI skill parameter via the init.sqf file it will draw the skill settings from the client who spawns the AI instead of the server / mission presets (for example through F3), thus the wide dispersion of experiences for various endusers.

I fully agree Spirit. Mission maker control should always trump GAIA strategies if the mission maker desires it. I'm definitely for a "tag" solution rather than an "always on" solution. Adding more behaviour buttons such as "aggressive", "defensive", "fortify", "vehicle behaviour x" and "likely to retreat" etc. could offer the most amount of freedom for the mission maker while still balancing the want / need for a bit of randomness. It let's the mission maker tag exactly how he expects the unit to behave (more or less of course). Another benefit of the tag approach over a unilateral solution is that if a certain behaviour string ever is borked (due to a bug or unforeseen effects) the end user can avoid said issue by not applying the tag behaviour to units anymore -> compartmentalisation of possible issues. It's definitely a very good approach to introduce GAIA changes in smaller packages. a.) coding a decent macro AI which can adapt logically to a large variety of player inputs is hard, really hard. b.) small changes in macro AI can have larger effects one did not contemplate right away and with smaller gradual updates one has more time to inquire feedback from hundreds of different community testing sessions - potentially catching bugs early on. I for one am very much looking forward to the next GAIA update and my community will gladly provide feedback on the various GAIA deployments (got a few die-hard MCC enthusiasts).

This is not really related to GAIA. You can do that by adding this to any unit's init line: this allowDamage false or if you are not comfortable with init lines etc. use Ares mod, it has a Zeus module extension to make any unit invincible on the fly.

Something that just popped into my head which kinda goes in the same direction as the above: I'd love to see GAIA retreat more - abandon positions, retreat and regroup with additional elements and re-engage the players in a new battle when the odds are once again more in favour of the AI (mainly calculated by number of soldiers left). For example: Zone 2 is overlapping a town plus a sizeable area of the surroundings of the town. Two GAIA fire teams are "fortified", four rifle squads are patrolling "defensively" within the zone. The players take out large 60% of the entire GAIA force in Zone 2 without taking any losses themselves. All remaining GAIA elements should receive WP's to high tail it out of Zone 2 and retreat to Zone 3 (a GAIA controlled zone which hasn't seen any combat yet). Of course this game logic would only trigger if GAIA units still have an unharmed zone to retreat to, if not they'd fight to the death as usual. Ground vehicle / helo patrol WP generation: One thing that often irks me a bit, when using GAIA in conjunction with ground vehicles and helos "defensively" is that if I let GAIA control let's say a technical or medium armour, it will always generate patrol way points for that vehicle. This is totally fine when I want to create a vehicle patrol, however most of the times I'd like to have a vehicle be stationary (harder to spot for players, no sound or movement cues) while still directly connected to the "GAIA network". Ideally it should remain where I placed it, respond to emergencies when called for by other GAIA units, but return back to its point of origin (more or less of course) when done with its tasks. Right now to achieve this effect I have to micro manage via Zeus / Ares which isn't always an ideal solution, especially if multiple vehicles are involved. I'd be grand if we could get a new behaviour button for that purpose: "aggressive", "defensive", "fortify", "vehicle behaviour x". I'm running into this issue especially when trying to attach attack-helos to GAIA. Often placing a helo and a corresponding landing pad carefully in a specific location where I want it to be, then applying either "aggressive" or "defensive" to it, only to see it lift off immediately, receiving a number of new WPs and then landing at an entirely new location where it is very vulnerable to attack, easy to spot and breaking the immersion - people going like "why by Odin's beard is that Hind just chilling in the middle of this wheat field instead of an airport?".

FUCK YEAH! I've been longing for a GAIA update, can't wait to see the results! Kudos for taking the time to update the system. I second what was already mentioned: In addition I've noticed another issue with GAIA: - during longer sessions (2-4h) it can happen that especially in the last hour GAIA controlled units remain in "combat mode" (white map marker in MCC console) and will no longer receive any new waypoints, even if the players completely vacate the area. Similar to the first report above it is quite hard to reproduce, but it's more likely to happen the more players are online, the more AI was spawned via MCC and the longer the session goes. Feature requests: - I'd like to see GAIA use buildings, towns and woodland areas more effectively when planning their routes / engagements (I realise you've already addressed this in a post above, just mentioning it here for completion sake). - Collaboration between GAIA infantry elements is currently more coincidental than deliberate. Meaning they do try to attack together and when forming the "spiral" WP attack pattern two elements will try to attack from two different sides, but beyond that the AI does not seem to cooperate much. Ideally I'd like to see the AI identifying it's assets and using them to suppress and attack in a coordinated fashion: i.e. if the AI has one MMG team and one rifle squad at its disposal, it should order the MMG team to hold position at a good engagement distance and open up on the players, while the rifle squad would be designated as the moving / flanking element trying to close the distance. With the current systems both infantry elements would move and assault in the spiral pattern simultaneously. - GAIA vehicles currently try to get very close to the player which makes it a lot easier to duck in a ditch and blast them with unguided LAT launchers. If possible GAIA should babysit vehicles of medium and heavy classes to stay as far away from enemies as possible and engage at a distance. If an enemy vehicle is surprised in an ambush / close encounter it's first "instinct" / WP generation should be one of retreat (if possible while popping smokes) and not to stand & fight. - General enhancements of logistic use would be very neat. Sometimes I see GAIA utilise a truck from one zone to pick up infantry and bring them somewhere else, but it's quite rare. I've never seen them do that with a transport helicopter. I'd love to see GAIA make full use of small and medium sized transport helicopters, actively picking up rifle squads and flying them at the rear or flanks of a player controlled platoon or even trying an extraction if losses were quite severe -> Zone 1 had seven elements garrison / patrol defensively. Players take out six elements, the seventh is requesting emergency EVAC via helo. I know that GAIA is more of a macro rather than micro management AI system and most of these common AI behaviour issues are kinda hardcoded into Arma 3, so I'm not expecting any miracles. ;) I'll be very happy with any new features / polishing of the existing GAIA, above's only a bit of brainstorming of "nice to haves".

Awesome stuff CUP team. I think this upcoming release will be the one which will make us switch from RHS to CUP for good. Yay!

Mind. Blown.

This is just an assumption on my part but it could be caused by the ACE3 event handlers which measure after every shot how much the weapon overheats and the likelihood of a weapon jam. I'm imagining that especially when firing faster rate of fire LMG's over a longer period of time (200 round boxes) that the calculations for ACE3 can get rather hectic.

Alternatively you can delete the marker.pbo (it's one of the few .pbos you can safely delete without causing issues within ACE3, similar to goggles.pbo and gforce.pbo) from your ace folder and replace it with a system of your choice. Our community uses SWT map marker for example.

Are you guys planning on more GAIA improvements for r19 or r20? WP generation, reaction to contact, communication between AI elements, reinforcement requests from other zones etc. These features all work quite well atm but it would be awesome to see them a bit more refined and / or expanded in future versions as GAIA has remained rather unchanged for some versions.

Woop woop! Thanks for the update, can't wait to give it a spin.

Done. Thanks for creating the report and letting us know about it.

Woop woop, new RHS content! Thanks for the latest release! :292:

Are you planning on doing some re-textures of the other faction's Indie uniforms such as FIA or BluFor gear? Because that would be awesome! Other question: What kind of defense values did you apply to your vest and helmets? Did you copy the vanilla values or set up your own?

Same here, our community will most likely temporarily remove the mod from our repo in order to eliminate the chance that mission makers use its vests by accident. Most likely candidate for replacement will be Killoch's Multinational Pack as it also features a lot of interesting clothing choices. I hope TRYK will return to active development as it is really one of the best collection of gear items.

Thank you for the comprehensive answer. ^_^

A ZSU BMP? Hell yeah! Can't wait to use that thing in an adversarial mission. :coop:

Yeah, already done that a couple of times for smaller projects. My question was more a curiosity thing regarding the HLC stance on donations, due to the SAW already being within RHS and CUP recently acquiring a lot of 3rd party mods - wasn't really looking for a "how to" guide. Still, thanks for sharing the link. ;)

After going through a lot of the CUP pages I was getting curious about a certain aspect: mod donations. Question: will some or all of the HLC weapons be donated to CUP, similar to how the SAW was donated to RHS, or will the HLC arsenal remain largely independent? Would be amazing to see the CUP Bundeswehr troops running about with the latest HLC G36. :wub:

Ah cool, and here I already anticipated a merger between DAC and MCC similar to AGM and CSE. ^_^ I'm not sure this is directly linked to the 1.54 update as the BIS changelog doesn't really suggest an impact on that MCC function (though I might be very wrong about that). Our community still uses r13 due to some issues introduced by later MCC updates and for us the clipboard function works like a charm.

I think what most people refer to with that statement is summarised quite well by Dslyecxi's reddit replies: a.) and b.) With the old system the character would more gradually slow down, even while jogging, depending on the carry weight and the distance crossed. With the new system that gradual change is almost removed, but now we have to deal with excessive weapon sway - which due to the enormous negative response will most likely be nerfed soon. The comparison to Fallouts "overburden" effect is rather fitting.

Same here, death to bumblebees from outer space!

Thanks a lot for the clarification. Our community prefers using vanilla or close to vanilla values in order to ensure broad compatibility across multiple mod platforms and vanilla assets, especially for PvP. Currently we are prepping a restructure of our mod repo, might be replacing some older gear mods with yours. ^_^ Keep up the great work!

MELB received two updates since the 1.54 patch and we've been using it in several operations so far post-nexus. We didn't run into any issues at all, the mod performs great and is a blast.

Oh my, the Mi-6T and the new BMPs look glorious. Can't wait use those in the editor. If this ain't an awesome Xmas present then I don't know what is... :bounce2: :bounce2: :bounce2: :bounce2: