Jump to content

Recommended Posts

YvbCfee.png

 

Hello, @super-truite and I have made a little piece of script to allows missions maker to make a better use of AIs and vehicles on missions. We are guessing that a similar system already exists but we wanted to have a custom system for some of our projects and thought it would be nice to share it.

This compilation of script allows a mission make to cache units suchs as vehicles and soldiers with their respective properties (waypoints, stance, direction, position, health, ...). This allows for greater performance and (if chosen) persistence.

 

 

Features: 

Grid caching

GCS allows the mission maker to automatically cache into the memory AIs andvehicles. Waypoints assigned to a group or a unit are also cached and are reapplied when the unit or group is set up.

The mission creator, if necessary, can also exclude a unit or a vehicle from the cache so that the system does not take it into account.


Persistence system (optionnal)

In addition to all the caching made, the mission maker can also integrate a data persistence system via MySQL so that, even with a restart of the mission or the machine, the units and vehicles will still be saved.

 

 

How it works: 

GCS will create a virtual grid on the map based on three parameters available in GCS_configServer.sqf :

 

    GCS_VAR_SIZE_SQUARE_GRID                           - Represents the total size of each cell on the grid
    GCS_VAR_SIZE_ACTIVATION_SQUARE_GRID  - Represents the trigger distance where AIs and vehicles will be created in the cell
    GCS_VAR_SIZE_UNSPAWN_SQUARES              - Represents the trigger distance where AIs and vehicles will be cached and removed in the cell

QpyUlN9.png

 

Each cell is defined by these three variables, as described, GCS_VAR_SIZE_UNSPAWN_SQUARES will trigger the caching and removal of units for the given cell, GCS_VAR_SIZE_ACTIVATION_SQUARE_GRID will activate a cell, retrieve it's cached content for the memory or database and will spawn the units. GCS_VAR_SIZE_SQUARE_GRID Defines the cell size.

 

You can disable the caching system on a unit or vehicle by adding the variable "UseGrid" to false on the unit/vehicle init:

this setVariable ["UseGrid", False]

In this way, even if no player is near the unit or vehicle, it will never be cached and removed.

 

The following gif shows a simple example with a single grid cell being cached, unloaded (player leaving the cell) and reloaded with cached data once the player re-enter the cell: https://i.imgur.com/ai7PeLh.mp4 and the picture below demonstrates a more complete case: 

rnrgOyW.png

 

Video example: https://streamable.com/jrh43r (4601 units on Stratis)

 

By default, the persistence system is disabled, you will need to install a MySQL database, have the InterceptDB mod installed aswell with CBA. A full tutorial is available on the readme on Github (https://github.com/Super-truite/arma3_GCS.vr/blob/master/README.md)

 

Download:

 

Get the latest release here: https://github.com/Super-truite/arma3_GCS.vr 

  • Like 12
  • Thanks 2

Share this post


Link to post
Share on other sites

This looks extremely interesting, on paper it seems to hold similar functionality to Alive but using areas instead of proximity to players etc?

 

Thanks for your work

  • Like 1

Share this post


Link to post
Share on other sites

This is exactly how battlefield's frostbite engine manages to achieve such high fps and have impressive graphics in tandem with 50 vs 50 player battles.

 

Well done!

  • Like 2

Share this post


Link to post
Share on other sites

@[BL] Hannibal yes this might overlap with some of alive functionnalities. As @anthariel stated, we guess there are other caching system in already existing mods/missions, but we wanted our own that fits our needs.
The goal is to be able to place a lot of AI units in the editor and let the system cache them if there are far from the players with an option to get a persistent state of the units if needed. Most caching systems I came across (one was called EOS I think) were spawning units via scripts in markers area, which did not fit our need for custom (tedious 😅 ) AI placement. 

Share this post


Link to post
Share on other sites

Very interesting.

1. Has is been tested with headless clients? 
2. Does it option to exclude players/pilots in aircraft/helo/vehicles?

Share this post


Link to post
Share on other sites

1. just began to look into it. Since we do no need it a priori for what we develop, I do not know if we will have the time to do it though.
2. Players are already excluded, any units that spawn via script is by default excluded from the grid caching (you need to do a _unit setVariable ["UseGrid", True] for it to be registered).
By default, all the units on the map at start, except players,  are registered for caching. You can use

 this setVariable ["UseGrid", False]; 

in the init field of some units to exclude it.

  • Like 1

Share this post


Link to post
Share on other sites

Out of curiosity, will this cache units spawned after start-up? For example, many mission frameworks such as Drongo's Map Population spawn units post-mission start.

Share this post


Link to post
Share on other sites
7 minutes ago, sgtfuzzle17 said:

Out of curiosity, will this cache units spawned after start-up? For example, many mission frameworks such as Drongo's Map Population spawn units post-mission start.

 

On 6/1/2020 at 10:01 AM, super-truite said:

...any units that spawn via script is by default excluded from the grid caching (you need to do a _unit setVariable ["UseGrid", True] for it to be registered).

 

  • Like 1

Share this post


Link to post
Share on other sites
2 minutes ago, Harzach said:

 

 

Alright, so provided I run _unit setVariable ["UseGrid", True] on any units that get spawned in (even if its after start-up) they'll still get registered for caching?

Share this post


Link to post
Share on other sites

@sgtfuzzle17Absolutely, there are two big ways in which the system will check whether the units should be cached or not.

 

1: Without persistence
The verification of the units to be cached is only executed when all players have triggered a despawn cell (GCS_VAR_SIZE_UNSPAWN_SQUARES). The verification will be done in the content of the respective cell (GCS_VAR_SIZE_SQUARE_GRID).

 

2: With persistence
Same as 1. but the verification is done every n seconds (1s by default with the parameter GCS_VAR_MONITORING_FREQUENCY_SECS). Every n seconds therefore, a check between before and now is made.

This frequency change is due to the fact that with persistence on, we need to be ready for a system shutdown or mission shutdown and we therefore cannot wait for all players to leave the cells for caching.

 

In all cases, if a unit is added by a script after the initialization of the mission, it will by default be ignored, it is possible to do it more explicitly with the variable "UseGrid" to false if necessary but it is not required.
On the other hand, if the unit or vehicle is added with the variable "UseGrid" set to true, then the unit will be taken up in the systematic verification of the system and will be cached.

 

After some tests, I had some trouble with the following code:

_newUnit = "O_Soldier_A_F" createUnit [position player, (createGroup east)];
_newUnit setVariable ["UseGrid", True];

 

In my case, the setVariable seems to be triggered before the actual unit was intialized (or something else that I didn't understand) and ArmA did not add the variable to the unit. To fix this, you should use the following code:

_newUnit = "O_Soldier_A_F" createUnit [position player, (createGroup east), "this setVariable ['UseGrid', True]"];

as described here: https://community.bistudio.com/wiki/createUnit in the alternative syntax paragraph.

 

 

Demo: https://streamable.com/x5rbyq You can see that the first unit was added without the variable and was not cached, the second one was added with the variable set to true and, was cached once I leaved the cell.

 

 

  • Like 1

Share this post


Link to post
Share on other sites

Some questions on the caching:

 

Do the units retain their damage states?  i.e. vanilla or ACE wounds, vehicle component damage (broken glass, popped tires), etc.

Do the units retain their stance?  prone, kneeling, whatever.

Do the units retain their orders?  Patrolling, condition red, etc.

Do the units freeze when cached or to they virtually still move, like ALIVE does?

Do the units retain a custom disableAI / enableAI scripting commands?  For instance, if I make a unit and do a disableAI "PATH", will that persist between being cached and uncached?

 

Can cached units still receive commands via script?  Say a I have the variable for the group of a cached unit, and I script a command for them to move to another location.  Is this possible?

 

 

  • Like 1

Share this post


Link to post
Share on other sites
On 6/13/2020 at 8:17 AM, accuracythruvolume said:

Some questions on the caching:

 

Do the units retain their damage states?  i.e. vanilla or ACE wounds, vehicle component damage (broken glass, popped tires), etc.

Only getDammage _unit  is saved so far

Do the units retain their stance?  prone, kneeling, whatever.

yes

Do the units retain their orders?  Patrolling, condition red, etc.

yes for waypoints, they do not keep the knowsabout info though

Do the units freeze when cached or to they virtually still move, like ALIVE does?

they freeze

Do the units retain a custom disableAI / enableAI scripting commands?  For instance, if I make a unit and do a disableAI "PATH", will that persist between being cached and uncached?

not saved

Can cached units still receive commands via script?  Say a I have the variable for the group of a cached unit, and I script a command for them to move to another location.  Is this possible?

no

 

 

Again, this is a fairly 'quick and dirty' caching system that fit a really specific need (it is a by product of something we develop), but we thought it would be nice to release it because it could provide a simple starting point for other use cases. We made some effort to document and organize it as intuitively as possible  (for once 😅)

Share this post


Link to post
Share on other sites

Once the mission is built, run and processed/cached -- is it straight-forward to add more units in the editor?  ie. Does the SQL database update if the units are moved/new units added between missions.
I am just trying to predict how I would plot a campaign out using GCS.

I cannot tell if you plan in detail whole series of missions with ambient enemy units. STOP (ie. don't add more stuff). Play that through. Start again.

Share this post


Link to post
Share on other sites

It depends on how the units are added.

 

If the units are added via the editor of ArmA 3, that is to say when the mission is not loaded, then the data will not be saved in the database because, if the persistence system is defined as active, the system ignores any new entry, it simply goes to the database and retrieves all the information from there. In that case you are going to need to use the PersistenceResetOnStart parameter from the description.ext.

 

In your case, if you want to add new units while the mission is running, it is possible yes, but only for already loaded sectors.

If you add a unit with this in his initialization conditions: this setVariable ['UseGrid', True], it will be added to the database once the sector where that unit is, is cached (no player nearby). You can see my message above in relation to the UseGrid variable for more details. I even posted a video demonstrating it :-) https://streamable.com/x5rbyq

 

Does that anwser your question?

 

Share this post


Link to post
Share on other sites

Yes - many thanks.

I find GCS tends to spilt squads into individual units (but need  to test this more, as it may be a MOD clash).

  • Like 1

Share this post


Link to post
Share on other sites

Hi, thanks for Grid Caching System, it's really good.

The only problem i'm having with it is this...when i make a mission and put some units to patrol walking to some waypoints, they do that...but when i use GCS they will all start running, i have tried force walking and other things, nothing works...can you fix that?

 

edit: everything is working fine, it was one of the mods that was interfering with units.

Cheers!

Share this post


Link to post
Share on other sites

Probably a silly question. 

 

Units that are spawned with zeus mid mission are they cached? 

[Edit]
Im really confused with the 3 radius options. 
I have the map marker debug on but im still quite stuck on what exactly im changing in regards to the grid size and all the rest lol 

Is the value in metres? 

I would love it if you could do a short short video explaining the setup 🙂
works wonders though. just got stuck on the initial tweaking of the sizes 

[edit 2]
Just played with this some more using some garrison tricks 
I put this disableai 'PATH'; inside their init box and when they are cached and spawned back in it removes it and they will move when engaged. 

to reproduce this issue do the following 

place some blufor units inside a building and type 

Quote

this disableAI 'PATH';


Inside their init boxes 
preview 
go into zeus and give them a move order 
they shouldnt move as their path is disabled. 

now if you teleport outside of the despawn radius box 
so they are cached then teleport yourself back to reactivate them. Give them another move order and they will move. 

is there a way you can save their states or init box stuff? 
another example is a lot of people use 3den enhanced and they have a disableAI features boxes you can tick to disable stuff. 
 

Share this post


Link to post
Share on other sites

Hm, for the performance-saving side of things, doesn't Dynamic Simulation achieve the same thing?

Share this post


Link to post
Share on other sites

Please sign in to comment

You will be able to leave a comment after signing in



Sign In Now

×