Mission Template Stand Alone GAIA - Make missions FAST by using MCC GAIA engine

[strider42 64]

Nice bit of work.  I really like the groups automatically deciding which marker they should use, especially if you have the option to revert to the old system.

I have created my own interface to GAIA which still needs an update to work with the latest version, currently it is hacked to get it running.  Its main objective was to simplify the commands you needed to add groups to GAIA and I changed the commands to FORTIFY, DEFEND and PATROL.

I have stopped using the caching system.  I may be blessed by just creating small missions but I have not noticed any performance issues.  Additionally though I have not noticed it myslef I have a friend who says the chaching system can cause problems. (Mission has less than 40 AI and less then 10 players).

Keep the good work up  S

[doc. caliban 34]

Thanks! 

 

I like the renaming of the commands but have been too lazy to bother yet.  Do you have a screenshot of your UI?  I'd love to see it.

 

As for versions of Gaia, it doesn't look like there is anything newer than late 2017... is that the case?   BTW, I am still having the issue with the new version where "nofollow" groups leave their zones once they lose line of sight of me.  I'm going to do some proper testing and post a new reply with my results.

 

I haven't had any issues with the cache system that I'm aware of.  I was using ZBE Cache for a while but stopped because the Gaia one seemed fine.  We usually only play with 2-4 players, but the missions often have well over 100 AI units... sometimes almost double that.  It allows me to lay out a long, multi-session mission that way, and the cache keeps it from having undue impact on performance.  (One of my guys has a lower-spec machine, so I try to conserve everywhere that I can.)  That's why I adjust the mission view distance to something appropriate for the map and mission, and why I have the cache distance automatically fine-tune itself to that.

 

The zone automation that I have is 100% compatible with using the normal method.  If a group does not have the "gaiaCommand" variable set, the automation completely ignores it.  Thus, you can have a mix of both if need be.

 

Here's my current method and code for zone automation.

1. Place a zone (or all of them) and name them however you want.  Nest them as much as you want to.  (I name mine gz_x because my marker alpha automation looks for "gz".)
2. Place groups in the desired zones (it keys off of the Group Leader position) with one of the following lines in each Group Leader's Init field (use your custom command names):
   1. (group this) setVariable ["gaiaCommand", "NOFOLLOW", false];
   2. (group this) setVariable ["gaiaCommand", "MOVE", false];
   3. (group this) setVariable ["gaiaCommand", "FORTIFY", false];
3. Do not run gaia\gaia_init.sqf from your init.sqf.
4. Use execVM "gaia\gaia.sqf" instead, and create that file with the following content:

if (isServer ) then 
{
	// FUNCTION TO DETERMINE THE SIZE OF AN AREA-TYPE MARKER.
	MarkerArea = {
		switch (markerShape _this) do {
			case "RECTANGLE": {getMarkerSize _this params ["_msw", "_msh"]; _msw * _msh};
			case "ELLIPSE":   {getMarkerSize _this params ["_msw", "_msh"]; _msw * _msh * 0.25 * pi};
			default {0}
		}
	};

	// CREATE A LIST OF ALL AREA-TYPE MARKERS ARRANGED FROM SMALLEST TO LARGEST.
	allMarkersByArea = [allMapMarkers,[],{_x call MarkerArea},"ASCEND"] call BIS_fnc_sortBy;
	 
	// FUNCTION TO DETERMINE THE SMALLEST AREA MARKER THAT AN OBJECT IS WITHIN.
	getGaiaZone = {
		{if (_this inArea _x) exitWith {_x}; ""} forEach allMarkersByArea};
	
	// ASSIGN ZONE AND ROLE TO EACH GROUP THAT HAS THE "gaiaCommand" VARIABLE.
	{
		if (!isNil {_x getVariable "gaiaCommand"}) then {
			private _unit = leader _x;
			private _zone = _unit call getGaiaZone;
			private _command = _x getVariable "gaiaCommand";
			_x setVariable ["GAIA_ZONE_INTEND",[_zone, _command], false];
			_x setVariable ["gaiaCommand", nil];
		}
	} forEach allGroups;

	// Initialize Gaia
	call compile preprocessfile "gaia\gaia_init.sqf";
};

Now when you start the mission, that file will find all of the groups with "gaiaCommand", determine their intended zones, and issue the actual Gaia variable with zone and order assignments.   Any groups that are manually assigned, or not assigned at all, will be left as is.  Then Gaia launches and off you go.

 

Here's the code I put in initServer.sqf to automatically hide the Gaia zones.  I got tired of changing the alpha on them all the time for editing and hiding them in missions.  Now I just put them in a layer and toggle the viability when needed for editing, and this makes sure they never show up on the map in a mission.  If you place this in init.sqf, the zones will be visible on the MP pre-mission briefing map, thus why I use initSever.

// HIDE GAIA ZONE AREA MARKERS
{
	if (_x find "gz" == 0) then {
		format ["%1",_x] setMarkerAlpha 0;
	};
} forEach allMapMarkers;

 

[doc. caliban 34]

Is Gaia partially broken due to an Arma update?

 

This is the behavior I see now, and I believe that it is new. 

 

Test mission with no mods loaded.

• Zone 1
  • Group 1 "MOVE"
  • Group 2 "NOFOLLOW"

I engage the groups until both are aware of my location.

Result: Both groups fire on me.

 

I move out of view of both groups.

Result: Both groups send everyone except for the Group Leader out of the zone to look for me.

 

Expected behavior:

• All members of the NOFOLLOW group should stay in Zone 1.
• All members of the MOVE group should be sent after me.

 

Basically, everything works as expected until contact is made.  Then the zone assignments don't seem to be handled properly anymore.

[killick 21]

Quote

I have a friend who says the chaching system can cause problems

 

I am following this thread keenly, and impressed by the changes you have made doc.caliban. Being the 'friend' referred to by Strider I'll add my observations on what I believe to be the issue with the caching system, and what I think it is doing wrong. All this could be a misunderstanding on my part and if I have this wrong it will be very helpful to know....

 

Stage 1 caching - everyone by the Team Leader becomes un-simulated and is sunk underground to get them off the map

Stage 2 caching - everything is deleted

Stage2 uncaching - the Team Leader is recreated and become active again

Stage 1 uncaching - the other units are created and spawned at their relative formation position to the TL (because GAIA has no idea where they should be since the TL could have moved since they were stage 1 cached)

 

So if the unit was garrisoning a building only the TL goes back where he was, the rest elsewhere. On the Takistan map I have had cached units respawned under buildings, and I think this is the cause of it.

 

I'dd add that I have not looked at this for a good while as I have started to look at tweaking Gaia to use Dynamic Simulation instead of Gaia caching, and I don't know what version of Gaia I have (I dug the code out of an update of the MCC mod)

[doc. caliban 34]

I can see how that would get messed up.  I hadn't thought about garrisoned units being spawned back into incorrect positions.

 

On the topic of "FORTIFY", I've stopped using it because I feel that the garrisoning functionality is pretty bad.  I think that a rewrite of the building / position detection is badly needed.  I'd say the biggest issues for me are that they miss a ton of buildings, and that they end up underneath elevated structures, as though AGL is not taken into account for the position they are supposed to move to.

 

I may look at the code from other mods that do a better job with that and try to adapt it to Gaia.  I really miss being able to have AI troops deal with that on their own.  Part of the reason my zone automation leaves undefined groups alone is that I also disallow Gaia from using groups that aren't hers, and I use undefined groups as manually garrisoned groups.  I don't like having to do that as it removes the dynamic and somewhat random positioning of the units, but I gave up on the built in function.

[killick 21]

The Gaia Fortify code is just lifted from a CBA function - Fortify is CBA_fnc_taskDefend. There is a scripter who posts here called Zenophon who has an excellent occupy houses script  that I use in missions sometimes, but I haven't tried to replace the Gaia / CBA code with his work. But Gaia caching would still break the unit positions, so I wanted to get past that one first.

 

Zenophon's code actually places units by the windows in buildings so they don't just fortify it, they can see and shoot out of it, and they pop up/down in combat using a script from JBOY.

 

[doc. caliban 34]

Stay tuned for a sizable update to the FORTIFY and caching code.

 

FORTIFY Changes

• Completely rebuilt around Zen Occupy Houses which includes the options for:
  • Place units on the roof
  • Fill buildings evenly or fully fill the closest first
  • Assign positions from the top down
  • I updated the JBOY UpDown code to the newest version.
• Feature added (retained) from the latest version of CBA_fnc_taskDefend:
  • Use static weapons
• Feature added from Achilles instantBuildingGarrison by Kex:
  • Only use positions inside buildings

Cache Changes:

• Garrisoned units now retain their positions, direction, and behavior when un-cached... it's like they never left!   (This feature is finished, pending some testing.)   @killick, Should I look at switching it over to the vanilla Dynamic Simulation system instead?
• Found a way to, I think, vastly improve Gaia's cache system as it relates to reducing CPU use. Stage 1 caching (the bulk of the caching) uses disableAI to shut off features of the AI.  I learned that this provides no CPU load reduction for units that do not have nearby enemy... so basically all of your Stage 1 cached units.  I modified it to use enableSimulationGlobal to fully shut the units down and free up all the CPU cycles they are otherwise using.  It may be more efficient to apply that to the Stage 2 caching as well instead of going through the dozens of steps of cataloging, deleting, recreating and reconfiguring the groups unit by unit.

 

I still have a few bugs to work out with the FORTIFY mashup, and I need to make sure I check for permission from the people who's code I've borrowed and adapted for use by Gaia.  I'm hoping it will all be finished by the end of this coming weekend.  From the testing I've done so far it makes the FORTIFY option much more useful and flexible.

 

I will probably also add a Gaia Group Settings section to the Group properties tab where you can use check-boxes to select features such as my automatic zone detection, which order to give, caching, and all of the various garrison options. 

 

I guess I'd also do a Gaia Settings module where you can set all of the other user options like my new caching distance options, my random mortar timeout range, and whatever else seems like it would be good to have in there.

 

Let me know if you have any suggestions!   Maybe once all the updates are working, some Eden UI options and modules are added, and I've cleaned up some of the old code elsewhere in the mod, we can arrange to have a formal update posted to this thread?

 

Thanks again to Spirit for the great mod!  I could never make something like this from the ground up, but I've been having a great time rummaging around in its guts and finding cool things to make changes to, and I hope others will get some use out of what I'm doing.

[doc. caliban 34]

Still working on smoothing everything out, but I have the Gaia Settings module created and working.  All of these settings are now in an 3den module, though you can still set them in a config file if you wish:

• Enable Gaia
• Enable Dynamic Simulation for Gaia Groups
• Maximum cache range
• Distance from which foot troops will attack
• Distance from which ground vehicles will be sent
• Distance from which aircraft will be sent
• Can Gaia attack with non-Gaia troops
• Can Gaia units use smoke and flares at night
• Smoke and flare frequency
• Transport reset time
• Garrison - Fill buildings evenly
• Garrison - Indoors only
• Garrison - Fill positions from the top down
• Garrison - Place units on the roof
• Garrison - Use static weapons

There is also now a Gaia section in the Group Attributes UI:

• Drop-down list with the three orders: Attack, Defend, Fortify
• Edit box to manually specify the group's zone (leave blank for automatic zone detection)
• Checkbox to cache the group if Dynamic Sim is enabled in the settings module

Not a big deal, but kind of cool to not have to edit config files or copy and paste code into init fields anymore.

[doc. caliban 34]

I'm considering retiring the built-in Gaia caching system and would appreciate your feedback on that.

 

It's a great system, especially for the fact that it was created at least 5 years ago.  The 2-stage cache is interesting in that it lets the team leader continue moving around at a greater distance than the rest of the team once they are cached. 

 

How it works in a nutshell:

 

Stage 1 - Everyone but the team leader is disabled and hidden.  I improved on how that was happening by changing the way that the AI was being disabled.

 

Stage 2 - The entire group, its vehicles, variables, units, etc, are cataloged and deleted.  IIR, their ammo counts are not kept, so when they respawn they have a full kit again.

 

When back in range, the entire group is recreated from scratch and then has all of the above attributes applied... this involves many steps.

 

In my mind, it seems like less overhead to simply use the current Dynamic Simulation system.  The upshot is that it's a lot less activity happening compared to the stage 2 Gaia system, and the downside is that you lose the 2-stage system, though I admit that if you don't know where the group is on its patrol, you don't know.  Having the leader keep the patrol going so that it's at a different location that you still don't know about doesn't seem to make much practical difference IMO, but that's subjective.  I thought of a way to still have 2-stage with Dynamic Simulation, but it would increase the amount of work the engine is doing which defeats the purpose.

 

This is how I have it set up now:

• The Gaia Settings Module has Dynamic Simulation enabled by default, but you can disable it.
  • The Gaia initialization code manages all of the DS settings on its own (no need to set them in the mission attributes or description.ext):
    • Enable/Disable the Dynamic Simulation system for the mission.
    • Sets the distances based on the mission view distance.
      • This is adjusted on-the-fly when a player looks through a scope to ensure they don't see any transitions in the AI.
      • The user can set a maximum distance at which groups will remain uncached if the view distance goes past that point.
    • Automatically enables Use Dynamic Simulation for all Gaia controlled groups.
      • This can be overridden on a per-group basis by unchecking the cache option in the new Gaia section of the Group attributes window.

 

In short, in this modified version of Gaia that I'm crafting, what are your thoughts on moving it over to using Dynamic Simulation the way killick had suggested trying?  

 

EDIT: I can also keep the original system but do the stage 2 in a much more efficient way.  Simply apply the same method to the group leader instead of going through all the work of removing and recreating the entire group.

[Vigil Vindex 64]

I've been thinking about the caching system and how it freezes cached units at the last location. The only solution I can think of to this would be to calculate the average movement speed, direction, etc and compare the time from when cached to the time of de-caching and modify the location according to that projected location.

[doc. caliban 34]

1 minute ago, Vigil Vindex said:

I've been thinking about the caching system and how it freezes cached units at the last location. The only solution I can think of to this would be to calculate the average movement speed, direction, etc and compare the time from when cached to the time of de-caching and modify the location according to that projected location.

 

I suppose that's inherent in any cache system.  The problem with calculating a later position would be that most groups / vehicles are making relatively random movements in their patrol areas.    You could uncache them  at a different, randomly selected position, but I figure if you don't know where they were when they were cached, then it makes no difference.   Again, just my opinion.

[Vigil Vindex 64]

17 minutes ago, doc. caliban said:

... random movements in their patrol areas...

That is due to the chosen code to generate the waypoints for that patrol. If the patrol is limited to a random patrol of a single location area I suppose it is reasonable to ignore precise random last location of a random patrol. But if the patrol waypoints are less random and more curated, such as a patrol between larger distances, location to location, then you should be able to project into the future an estimated location they would have travelled to in the interval between caching.

EDIT:

Maybe something along the lines of:
* Get the locations of all the waypoints for a group.
* Calculate cumulative distance between those waypoints in sequence.
* Estimate average speed of unit. Do the usual distance equals velocity over time to get location to de-cache.

[killick 21]

doc. caliban - you asked a question of me a few posts back and I have been AFK for a week so have missed all the developments in this thread, and unable to reply. I have a bit of catching up reading to do today then I will reply to the question properly.

[doc. caliban 34]

23 hours ago, Vigil Vindex said:

 But if the patrol waypoints are less random and more curated, such as a patrol between larger distances, location to location, then you should be able to project into the future an estimated location they would have travelled to in the interval between caching.

 

That's a good point and also a good example of the value of the existing Gaia stage 2 cache where the group leader keeps patrolling.  Here are my thoughts on a solution:

 

Make both cache options available in the Gaia settings.  (Original and Dynamic Simulation.)   

 

Update the Gaia cache system as follows:

• Change the way that the UI are disabled by using enableSimulation instead of disableAI since the latter is not actually reducing CPU usage.  That fact was not documented at the time the original system was created; the note in the wiki was added in early 2017.   I've already made this change in the functions for Stage 1, and also for Stage 2 in the  event that the group is garrisoned since the Team Leader isn't moving around anyway.
• Replace the process of logging, deleting, recreating, and re-configuring the entire group in the Stage 2 cache function with simply teleporting the group into patrol formation with the Group Leader when they are uncached.

 

 

42 minutes ago, killick said:

doc. caliban - you asked a question of me a few posts back and I have been AFK for a week so have missed all the developments in this thread, and unable to reply. I have a bit of catching up reading to do today then I will reply to the question properly. 

 

No worries!  I have a bunch of stuff going on as well and have been afk more than expected recently.  Looking forward to your feedback.

[killick 21]

The changes that you are proposing look very good, and the change over to the Zen Occupy Houses will be a massive improvement.

 

The benefit that Gaia caching has over dynamic simulation is that at Stage 2 it actively deletes the group. That used to make a big difference to the maximum group count in a mission, less so after the maximum group limit was upped some time back. With a really massive mission the need to do real 'delete - respawn' caching might remain, so the GAIA code version or a modified version of it could still have a role.

 

I find the stage 1 / stage 2 caching is noticeable with vehicles patrols more so that foot patrols. At stage 2 the vehicle will keep moving, so vehicle patrols and attacks keep going over longer ranges. Like Vigil Vindex I have looked at trying to add future predictions of position but never felt it added anything as, as you say, it is no better than a random position.

 

The main reason I had gone off Gaia caching was the way it messed up "fortify" units. If you have fixed that then I think caching might still have a place, especially in big missions (which I sometimes make). So I'm looking forward to trying out the changes you have made.

[doc. caliban 34]

48 minutes ago, killick said:

The changes that you are proposing look very good, and the change over to the Zen Occupy Houses will be a massive improvement.

 

The benefit that Gaia caching has over dynamic simulation is that at Stage 2 it actively deletes the group. That used to make a big difference to the maximum group count in a mission, less so after the maximum group limit was upped some time back. With a really massive mission the need to do real 'delete - respawn' caching might remain, so the GAIA code version or a modified version of it could still have a role.

 

I find the stage 1 / stage 2 caching is noticeable with vehicles patrols more so that foot patrols. At stage 2 the vehicle will keep moving, so vehicle patrols and attacks keep going over longer ranges. Like Vigil Vindex I have looked at trying to add future predictions of position but never felt it added anything as, as you say, it is no better than a random position.

 

The main reason I had gone off Gaia caching was the way it messed up "fortify" units. If you have fixed that then I think caching might still have a place, especially in big missions (which I sometimes make). So I'm looking forward to trying out the changes you have made.

 

Thanks for the feedback!  The new "Fortify" code is indeed working awesomely... it's put that feature back on the map in a big way.  I also have very much appreciated being able to set all the options in 3den instead of copying config files around and editing them.  I do have an override file in the mission root that allows mission makers to still go that route instead of using the 3den module.

BTW, I've also converted the entire thing into a mod instead of folders full of files that have to be in the mission folder.  All you have to do is enable the mod and everything works on its own from there.  No fuss, no muss.

 

I agree on all of your points.    I've just been called away again, probably for the day, but here are some quick thoughts that may not be directly related to each other:

 

• How does delete/despawn caching compare to Dynamic Simulation, which BIS sells as "all you need" for huge missions?  Is DS close enough in performance to be "good enough"?
• You guys have made excellent arguments for retaining the 2-stage cache system.
• Regardless of whether we stay with delete/respawn or switch to DS, I can retain a 2-stage system.
• If delete/respawn is worth using over DS, I can still improve upon the second stage by adding a few more things like retaining unit's kits (ammo counts) and perhaps streamline the existing code a bit.
• I have a few half-baked ideas for a hybrid DS / delete/respawn system.

 

[strider42 64]

  Just to show you can't please all the people all the time.  I like the script nature of GAIA.  I prefer tuning text conficuration files rather than using modules in the Eden editor but I am prepared to give anthing a go and it is nice seing that GAIA is getting some love.

   I guess is it is hard to decide 'how big a mission'/'how many units' is likely to require any form of caching.  I currently run a multi-player mission with about 100 enemy units (18 groups) and no caching on a  player server (i7-7770K) and I don't get the feeling that it is loading the PC I run it on (+50fps).

As the mission does not run with caching I can't be breaking the Fortify system a pointed out by @killick, however the units do seem to leave their posts, especially when number of units left in the group gets small.  That said I feel it works quite well in the mission.

   I too have been playing around with the Zen Occupy Houses script to make sure units stay in place.  Placement is nice but there is some irritations.  Units stand by a  window and will engage.  Then they like to take knee, at which point their weapon does not have an line-of-sight on you but you can snipe thier heads ^^

   @doc. calibanYou asked if there were any features people would like added: I'd like to have the option to specify  a patrol loop for a squad to use, rather than the random movement the current patrol system uses.

   As reguards 2-stage cache (2SC) vs. DS  it is hard to know without really understanding the performance advantage.  I'd guess:  2SC > DS > 1SC, with both DS and 1SC adding to the group limit.

I'd also like to see caching retaining units kit and ammo count.  It is certinly irritating when you equip units with particular weapons to have the caching system change them.

Keep the good work up  S

[doc. caliban 34]

6 hours ago, strider42 said:

  Just to show you can't please all the people all the time.  I like the script nature of GAIA.  I prefer tuning text conficuration files rather than using modules in the Eden editor but I am prepared to give anthing a go and it is nice seing that GAIA is getting some love.

   I guess is it is hard to decide 'how big a mission'/'how many units' is likely to require any form of caching.  I currently run a multi-player mission with about 100 enemy units (18 groups) and no caching on a  player server (i7-7770K) and I don't get the feeling that it is loading the PC I run it on (+50fps).

As the mission does not run with caching I can't be breaking the Fortify system a pointed out by @killick, however the units do seem to leave their posts, especially when number of units left in the group gets small.  That said I feel it works quite well in the mission.

   I too have been playing around with the Zen Occupy Houses script to make sure units stay in place.  Placement is nice but there is some irritations.  Units stand by a  window and will engage.  Then they like to take knee, at which point their weapon does not have an line-of-sight on you but you can snipe thier heads ^^

   @doc. calibanYou asked if there were any features people would like added: I'd like to have the option to specify  a patrol loop for a squad to use, rather than the random movement the current patrol system uses.

   As reguards 2-stage cache (2SC) vs. DS  it is hard to know without really understanding the performance advantage.  I'd guess:  2SC > DS > 1SC, with both DS and 1SC adding to the group limit.

I'd also like to see caching retaining units kit and ammo count.  It is certinly irritating when you equip units with particular weapons to have the caching system change them.

Keep the good work up  S

Hi there.  Thanks for chiming in!

 

It would be easy to release a mod version and script version side by side.  I will do that.

 

I'll keep the built in 2SC and make some performance and feature improvements, and also make DS an option.  Best of both worlds.  (And the fortify-breaking issue is 100% resolved.)

 

I occasionally had the same issue with garrison units leaving their positions but I'm pretty sure that I chased down the cause and resolved it. IIR, it was related to the next topic.

 

The changing of posture, (taking a knee, lying down, standing up again) is due to the JBoy Up-Down script included in  Zen Occupy Houses.  Since ZOH was last updated, JBOY made an update to his script which I have incorporated into ZOH.  I could easily make that entire subroutine an option as well.  Units would still change position based on whatever FSM file is in use, but it would not be as elaborate as JBOY's code.  Should I split that out as another optional feature?  I think it was this code that I had to add to to prevent units from leaving their garrison positions.

 

I'm pretty sure that I can create a per-group option for manually specifying patrol waypoints.  Is that what you mean?  Or do you want the script to automatically create a loop-like route inside the perimeter of the zone?  I can fairly easily create a radius based loop, but would have to do a little more  braining to get it to do the same for a rectangular or elliptic route.

 

At this point I think I need to create some "beta" releases or it will be a while before I release anything at all.  How does something like this sound?  (Please suggest modifications as this is off the top of my head):

• Beta 1
  • Script and mod versions
  • Zen Occupy Houses based FORTIFY code (Maybe a feature or 2 not enabled yet.)
  • Multiple additional garrison options
  • Some unfinished features to be completed for B2
  • Automatic zone detection
  • Partially updated cache system
    • Stage 1 cache performance improved
    • Stage 2 cache mostly untouched but with added kit detail retention
    • Dynamic Simulation as an option
    • Cache range calculated based on mission view distance
      • Adjusted on the fly when looking through optics
      • Definable maximum distance past which caching will happen regardless of view distance
  • Mortar and artillery timeouts are randomized

 

 

• Beta 2
  • Stage 2 cache updated
  • Adjustable random timeout range for mortar / artillery missions
  • Adjustable random timeout range for foot patrol waypoints
  • Completed FORTIFY features
  • Per group patrol options:
    • Random
    • Perimeter of zone
    • Manual waypoint placement
  • Make JBoy Up-Down feature optional?
  • Bug fixes from B2 testing
  • Possible completion of feature requests from B2 testing

 

 

• Beta 3
  • Feature completion
  • Bug fixes from B2 testing

 

• Release

 

For the sake of organization and version control, I think I'll want to keep beta testers to a specific group instead of simply posting everything openly in the forum.  I also still need to do my due diligence in getting permission from Spirit and Zen to make the final results public.

 

PM me if you're willing to do some testing and I'll send a download link once Beta 1 is ready to go.

 

Thanks!

 

-Doc

[killick 21]

@doc. caliban I've just done quick a quick tally of a mission I made a little while back and that had the potential for 170+ groups under Gaia control placed on the map in the editor (a Malden-wide mission) so delete-spawn caching would have been important before the bump of the limit from 144 to 288 groups per mission. That ran fine. In another mission I developed since then I was more sanguine about group numbers, given the bump, and cached fewer units (as I wanted the opfor to drive a long way across the Angola map before being handed over to Gaia). In that the server slowed and then crawled and then juddered and the mission had to be abandoned. Lesson learned.

 

I'm going to stay silent on caching loadouts as I agree with @Strider that it's useful and I also know from my own coding that it's a bit of a chore to implement with the getUnitLoadout and setUnitLoadout arrays. I have got round it simply by not letting Gaia cache units and vehicles where I have built a special loadout, but have still had to do some loadout caching to allow some of those vehicles / units to be respawned when destroyed. 

 

I too also use Gaia as scripts, as it is plugged into a larger set of scripts that I used as a framework for making these big missions that I like. The core bits of that  are the  @Zenophon framework, Gaia, the Hermes Airlift Services Script by  @Gunter Severloh. But an Eden editor module for setting options sounds good. 

[strider42 64]

16 hours ago, doc. caliban said:

I'm pretty sure that I can create a per-group option for manually specifying patrol waypoints.  Is that what you mean?

@doc. caliban Yes, that is what I meant.  I'd like it to work either from an Eden genearated or a script generated route but I don't want GAIA to create the route.  I sort of imagined that GAIA would check if the group had been assigned a patrol route which I imagine would work the way I want.  Not that I worked out how to detect if a group has been assigned a patrol route.

 

The proposed release schedule looks good to me.  S

[doc. caliban 34]

Sorry, guys; I haven't forgotten about this!

 

I'm both back to work, and moving to a different home.   I'm maybe 1 evening's work away from being able to give you B1... maybe tomorrow if I can make the time.  Otherwise, probably next weekend.

 

[spirit6 51]

Hi all! Was supprised to see this topic updated hahaha. Do what ever you want/please on GAIA, it was made for the community so enjoy it any way you like! I have not played arma in years myself now.... ....... Have fun! 🙂

[avibird 1 155]

Where can I  get the download with all these updates that you guys have been working on. Is the original link updated with the changes you guys been working on. 

[doc. caliban 34]

On 8/6/2020 at 7:35 AM, spirit6 said:

Hi all! Was supprised to see this topic updated hahaha. Do what ever you want/please on GAIA, it was made for the community so enjoy it any way you like! I have not played arma in years myself now.... ....... Have fun! 🙂

 

Oh, wow!  So good to see you here!   I think I sent you a PM asking if it's ok to be doing all of this, so thank you for letting us run with it!  I could never create something like this from scratch, but I love to tinker... Gaia has been a blast to work with.  Thanks again!

 

I hope you don't mind, but I came up with a slightly different idea for what the acronym stands for.  I know it was originally Greater Artificial Intelligence.  To make it clear that it functions at the group level, I came up with Group AI Augmentation.  What do you think?

 

I also threw together a logo for the mod version that uses the Greek alphabet in keeping with the Gaia namesake:

 

 

The ancient Greek for Gaia.  Gamma Alpha Iota Alpha.

 

On 8/7/2020 at 7:18 AM, avibird 1 said:

Where can I  get the download with all these updates that you guys have been working on. Is the original link updated with the changes you guys been working on. 

 

Hi there.  I am working on getting Beta 1 out shortly ... hopefully today.  It will be fully functional but it will have some things for me to improve for Beta 2, and I will also try to fix any bugs that you guys find in B1.   I'll post a Dropbox link when it's ready.

 

UPDATE: I'm trying to pin down one last bug but I need to stop for the night.  I'll get back on it first thing in the morning.

 

[spirit6 51]

16 hours ago, doc. caliban said:

 

Oh, wow!  So good to see you here!   I think I sent you a PM asking if it's ok to be doing all of this, so thank you for letting us run with it!  I could never create something like this from scratch, but I love to tinker... Gaia has been a blast to work with.  Thanks again!

 

I hope you don't mind, but I came up with a slightly different idea for what the acronym stands for.  I know it was originally Greater Artificial Intelligence.  To make it clear that it functions at the group level, I came up with Group AI Augmentation.  What do you think?

 

I also threw together a logo for the mod version that uses the Greek alphabet in keeping with the Gaia namesake:

 

 

The ancient Greek for Gaia.  Gamma Alpha Iota Alpha.

 

 

Hi there.  I am working on getting Beta 1 out shortly ... hopefully today.  It will be fully functional but it will have some things for me to improve for Beta 2, and I will also try to fix any bugs that you guys find in B1.   I'll post a Dropbox link when it's ready.

 

UPDATE: I'm trying to pin down one last bug but I need to stop for the night.  I'll get back on it first thing in the morning.

 

 

 

You can take it to any level you like as long as all contributers stay in the hall of fame : ) hahahahaha. Thing is, I could never maintain things like Shay does or possible you will. I am more like a spin my head from ground up and burst something in reality 🙂

 

GAIA like you know it was not finished when delivered. It was just a first stage. The idea was to give all "zones" their own brain, taks and goals. One could be support, one could be occupy, one could be resupply, scout .... within that zones, priorities would be used to make sure the P1 zone will not be drained by a P2 zone.

 

Apart from their own goal or "purpose" the idea was that on top of GAIA would be the GAIA Master 🙂  Treating all zones like an army, dictating their GOAL/TASK. But also moving them based on what is happening. It is easy to produce, just make zones armies in the eye of the hihger level GAIA and deliver points. This higher level could then decide that a zone should be relocated/retreated. Or could, as a whole zone, move to a warzone to occupy. Resulting ins massive troopmovement from ai.

 

Just idea's! Have fun!