Jump to content


  • Content Count

  • Joined

  • Last visited

  • Medals

  • Medals

Community Reputation

40 Excellent


About JamesTheClarke

  • Rank

Contact Methods

  • Website URL
  • Google+
  • Youtube
  • Steam url id

Profile Information

  • Gender
  • Location

Recent Profile Visitors

1009 profile views
  1. JamesTheClarke

    ASR AI 3

    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.
  2. 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).
  3. 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.
  4. 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?".
  5. 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".
  6. JamesTheClarke

    Community Upgrade Project - CUP

    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!
  7. 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.
  8. 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.
  9. 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.
  10. Woop woop! Thanks for the update, can't wait to give it a spin.
  11. JamesTheClarke

    [MELB] Mission Enhanced Little Bird

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

    RHS Escalation (AFRF and USAF)

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

    FoxFort Camo Pack

    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?
  14. JamesTheClarke

    TRYK's Multi-Play Uniforms

    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.