ZBE_Cache AI & Vehicle caching script/addon

[Zriel 12]

Nice work mate

[zorrobyte 30]

I'll be gone for the next few days but when I come back I'd like to start work on another project, check it out here. I'll continue to bug fix ZBE_Cache but as far as major functionality, I believe it's met my goals for it.

Happy thanksgiving to those who celebrate!

--ZB

Edited November 28, 2014 by zorrobyte

[Zriel 12]

Happy Thanksgiving! Got holidays because of it, though I'm not in USA XD

[kremator 1065]

I believe it's met my goals for it.

Definately. Although perhaps looking at caching everything is the next goal :)

Good to see you looking at WICT. Just loved that in Arma2 and it would go very nicely with ZBE_cache too !

Happy hunting!

[zorrobyte 30]

Definately. Although perhaps looking at caching everything is the next goal :)

Good to see you looking at WICT. Just loved that in Arma2 and it would go very nicely with ZBE_cache too !

Happy hunting!

There is some missions out there that benefit from object caching, I'd like to check them out and in what use cases performance is benefitted. I've only tested using ammoboxes so far and performance didn't drop, I bet other objects that use physx could benefit like vehicles do.

Kremator, could you post in my WICT thread about bases capturing?

[kremator 1065]

Already done mate!

[whiztler 137]

Still wondering if we could drop the nearentities scan size for e.g. Stratis. Perhaps with: BIS_fnc_mapSize

/*
   Author: Karel Moricky

   Description:
   Returns map size.

   Parameter(s):
       0 (Optional): STRING - world name (current world used as default)

   Returns:
   NUMBER
*/
private ["_map","_mapSize"];
_map = [_this,0,worldname,[""]] call bis_fnc_param;
_mapSize = [configfile >> "cfgworlds" >> _map,"mapSize"] call bis_fnc_returnConfigEntry;
if (isnil {_mapSize}) exitwith {-1}; //--- Terminate when the world is empty
_mapSize = _mapSize call bis_fnc_parsenumber;

if (_mapSize == 0) then {["mapSize param not defined for '%1'",_map] call bis_fnc_error; -1};
_mapSize

[zorrobyte 30]

Still wondering if we could drop the nearentities scan size for e.g. Stratis. Perhaps with: BIS_fnc_mapSize

/*
   Author: Karel Moricky

   Description:
   Returns map size.

   Parameter(s):
       0 (Optional): STRING - world name (current world used as default)

   Returns:
   NUMBER
*/
private ["_map","_mapSize"];
_map = [_this,0,worldname,[""]] call bis_fnc_param;
_mapSize = [configfile >> "cfgworlds" >> _map,"mapSize"] call bis_fnc_returnConfigEntry;
if (isnil {_mapSize}) exitwith {-1}; //--- Terminate when the world is empty
_mapSize = _mapSize call bis_fnc_parsenumber;

if (_mapSize == 0) then {["mapSize param not defined for '%1'",_map] call bis_fnc_error; -1};
_mapSize

Added to the tracker, thank you!

https://bitbucket.org/zorrobyte/zbe_cache/issue/5/bis_fnc_mapsize-for-nearentities

[whiztler 137]

Did a test today, Altis, 50+ groups, 300+ EI, 50+ vehicles. Worked like a charm. Great performance, no red chains on (re)actication/un-caching.

I am going to be a real pain in the ass here with these feature requests:

1. The caching takes care of all group units minus the leader. Is it possible to count the group, and if the group is only 1 unit to cache the unit anyway? Or perhaps create a '(group this) setVariable ["zbe_cacheForceEnabled",true]' for a single unit?

2. Can we have zbe_cacheDisabled for a side or faction? That way the mission maker has the option to switch on/off caching per side/faction

I wasn't able to figure out what happens to air units when they are airborne.

Thanks for a great script!

[astrell 3]

I think its even better to leave One behind instead of caching all units. Even if player have the performance to look further then caching distance he can observe and detect enemys exept the exact size.

IMHO better then ALiVE, ´cause can still manage AI trough MCC.

[zorrobyte 30]

Did a test today, Altis, 50+ groups, 300+ EI, 50+ vehicles. Worked like a charm. Great performance, no red chains on (re)actication/un-caching.

I am going to be a real pain in the ass here with these feature requests:

1. The caching takes care of all group units minus the leader. Is it possible to count the group, and if the group is only 1 unit to cache the unit anyway? Or perhaps create a '(group this) setVariable ["zbe_cacheForceEnabled",true]' for a single unit?

2. Can we have zbe_cacheDisabled for a side or faction? That way the mission maker has the option to switch on/off caching per side/faction

I wasn't able to figure out what happens to air units when they are airborne.

Thanks for a great script!

1. ZBE_Cache is designed to keep a group mobile when cached. If a single unit group were cached then the group would not be able to move as expected and can break some missions. This is a specific use case that will not be implemented as it runs contrary to the scope of ZBE_Cache as would have poor return on investment. If concerned about performance, check out the FPS limiter. There are other caching systems out there that cache all units like F3 if needed.

2. This can be done by a mission maker in the init.sqf or another script by something like:

while (true) do {if side _x == "West" then {_x setVariable ["zbe_cachedisabled",true]}} foreach allGroups;

Forgive my pseudocode, I'm off in vacation atm without my main desktop or code references.

Edited November 30, 2014 by zorrobyte

[GieNkoV 30]

Wanted to test this script on dedicated and noticed that on dedicated you don't get debug window with debug turned to true. On local it works with no problems. Just reporting this little issue cause I wanted to test how good it works.

[zorrobyte 30]

Wanted to test this script on dedicated and noticed that on dedicated you don't get debug window with debug turned to true. On local it works with no problems. Just reporting this little issue cause I wanted to test how good it works.

Can always use baretail to tail the dedi's RPT.

Baretail

RPT

I could expand debug to use side chat as an easy solution, I'll think about it :)

[mrgwilliam 10]

zorrobyte, how will this script react to the presence of headless clients? Will it need to be modified or should it not be used with them?

[zorrobyte 30]

zorrobyte, how will this script react to the presence of headless clients? Will it need to be modified or should it not be used with them?

Since ZBE_Cache is now server only with global commands, it shouldn't matter where the AI are local to. ZBE_Cache should work perfectly with HC.

[bolbies 13]

Does anyone else have an issue later on in a mission? I typically play DUWS a lot and this script is fantastic at keeping frames up and smooth, but I noticed things like the AI menus, custom menus, VAS, and high command all take FOREVER to load after about 30-40 minutes.

[zorrobyte 30]

Does anyone else have an issue later on in a mission? I typically play DUWS a lot and this script is fantastic at keeping frames up and smooth, but I noticed things like the AI menus, custom menus, VAS, and high command all take FOREVER to load after about 30-40 minutes.

What version are you on? Some of the older versions had an issue with not exiting the FSM properly. I'd recommend downloading the latest version and replacing the userconfig if using addon.

[bolbies 13]

What version are you on? Some of the older versions had an issue with not exiting the FSM properly. I'd recommend downloading the latest version and replacing the userconfig if using addon.

I'm using the script version 4.5b, including the fix with changing "count vehicles" to the "count ...assets + ...assets + etc"

Edit: Another issue I just thought of (although not a big deal) for me is whenever I call in artillery or a CBU strike, since technically the ammo is counted as vehicles, the actual attack is very slow and spread out time-wise. As in, without this caching system, the CBU would last like 4 seconds, but with it it's about 15. It's still just as effective though so like I said it's not that bad.

Edited December 2, 2014 by bolbies

[astrell 3]

A tiny improved suggestion:

Simple ZEUS modules for "enable caching" with group/faction dialog, same with "disable caching" and "Set caching distance". For easy adjustment in running missions and longer events.

A long searched feature is a "move ai to HC" module with dialog single/group/faction and to which HC if more then one present IN COMBINATION with the option to activate und disable Caching on choose HC or main dedicated. Complicated? Yes. But perfect server performance management. Please think about it.

Still love your Addon version <3

[Zriel 12]

I'm using the script version 4.5b, including the fix with changing "count vehicles" to the "count ...assets + ...assets + etc"

Edit: Another issue I just thought of (although not a big deal) for me is whenever I call in artillery or a CBU strike, since technically the ammo is counted as vehicles, the actual attack is very slow and spread out time-wise. As in, without this caching system, the CBU would last like 4 seconds, but with it it's about 15. It's still just as effective though so like I said it's not that bad.

Called it using Zeus I suppose?

[bolbies 13]

Called it using Zeus I suppose?

Nope, a support call script.

[Zriel 12]

Confirmed, scripts seem to execute much slower. It takes 160 secs to execute a mission from start to "init" state, (I'm spawming IA using scripts) and 560 secs with ZBE cache.

No clue so far why, FPS tend to be better and CPS worse when using ZBE, but not such a huge diference, (3/4 FPS and CPS).

[zorrobyte 30]

Issues added to tracker: https://bitbucket.org/zorrobyte/zbe_cache/issues

I can test to be sure FSMs are exiting properly by doing a variable that + 1 for each FSM init and - 1 for each FSM exit and compare to vehicle and group counts to see if FSMs are being run more than once for groups. I ran a DAC mission for 24 hours with 200 respawns with no drop in CPS. Issue could be units deleted and respawned? We shall see.

Edited December 3, 2014 by zorrobyte

[Zriel 12]

@Zorrobyte, why the use of FSM? I kept with the thought that they where better in performance than SQF, but now I'm searching for that fact and I do not really find anything that probes that (and have found that in reality it does not provide better performance)

All info I get is that FSM was developed in Arma for use in AI behaviour.

I may try to get your script in SQF only and compare.

I'm trying to get why all other scripts seem to get delayed when using your cache system. Have you tried in your tests to execute something (adding groups into an array and selecting a random one, or something like that?)

[zorrobyte 30]

@Zorrobyte, why the use of FSM? I kept with the thought that they where better in performance than SQF, but now I'm searching for that fact and I do not really find anything that probes that (and have found that in reality it does not provide better performance)

All info I get is that FSM was developed in Arma for use in AI behaviour.

I may try to get your script in SQF only and compare.

I'm trying to get why all other scripts seem to get delayed when using your cache system. Have you tried in your tests to execute something (adding groups into an array and selecting a random one, or something like that?)

Not so much that it is better in performance but that I prefer the structure. For ZBE_Cache it makes sense as the cache/uncache only needs to be in one state at the same time. As they work the same, I doubt your testing of migrating ZBE_Cache to SQF would have any difference but are always welcome to try.

On my machine, Intel i5 2500K @ 4.8GHZ, DUWS performance is perfect with 15 zones, 403 AI at 38FPS/38CPS.

As before, if ZBE_Cache's loop cannot finish in under the sleep time set in the FSM then performance will begin to degrade. I need to keep in mind not all have such a beastly machine such as mine and I'm tweaking sleep times now.

---------- Post added at 06:18 PM ---------- Previous post was at 06:12 PM ----------

4.5c

Changelog

• Edited count vehicles to count "real vehicles" (discarding odd objects in the map) - Thanks to Zriel
  
• Introduced zbe_mapSide for counting nearentities in vehicles, boats and air...better performance in small maps (even in Altis, Original 0.095594MS vs NEW 0.0928986MS with 585 cars) - Thanks to Zriel
  
• Synced changes between Addon and Script version so they are now identical
  
• Tweaked sleep time between FSM state checking to combat suspected CPS drop
  
• FSM now immediately exits for NULL groups
  

Download

Edited December 3, 2014 by zorrobyte