zorrobyte

I sent you a PM with my Skype info, I switched to the Beta branch as we should of been doing :P Plus side, due to the miscommunication I squeezed 4CPS more out of the vehicle caching FSM

Thank you! The emptyVehicle caching can be improved. I checked the last release and it apparently didn't have the FSM sleep tweaks I wanted in there. I need to work on reducing load for the vehicle caching. Sidenote, the map center and range tweaks you did doesn't work on the VR island as BIS didn't define it. Not a huge issue but still one I'll need to find the solution for. I wasn't seeing the CPS drop as I test on VR and vehicles were not being cached. Zriel, I made a "unoptimized" branch with no FSM sleeps on GIT to assess true code performance, just so you know what it is.

It's when there is no valid formationPosition _x for the specific unit it is attempting to setPos to. This can be due to spawning/deleting units during the mission. I've tried some conditions such as isNull and others with formationPosition however such attempts return in nothing, no true or false if undefined. Still working on a fix.. What CPU model do you have and at what frequency? I need to simulate a slow CPU to properly test the CPS as there is no drop with my 2500K @ 4.8GHZ my CPS is always at FPS. Maybe I can try underclocking. Zriel, could you try commenting out the vehicle caching and the ai caching separately and running the test again for ZBE_Cache? I'd like to see what CPS is like on your machine with just AI and just Vehicle vs both so I know which is dropping. Also, is this from a dedicated server or the built in A3 server/editor?

I believe it's due to the vehicle was deleted using deleteVehicle from the mission. Regardless, I'll work on using simulationEnabled to generate the cached unit and vehicle counts for greater accuracy for the next version. Negative debug numbers shouldn't hurt anything.

13:06:45 "585 ZBE_Cache (zorro) --- Groups: 128 # All/Cached Units: 403/253 # All/Cached Vehicles: 27/5 # FPS: 40 # ObjectDrawDistance: 0"

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

First WIP video showing group mounting empty vehicle and continuing to waypoint. Group mounting mannedvehicle and continuing to waypoint. In both tests, I setFuel 0 to show that AI will dismount if vehicle can no longer move and continue to next WP. http://youtu.be/ovsG90xwJJs FSM so far:

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.

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.

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.

Wouldn't be difficult to do, would you find it beneficial if the group all dismounted other than driver/commander/gunner to take found armed vehicle into the S&D area? Possibly this can be a parameter for the module. How does this look as a condition for an empty vehicle? PreCondition: _emptyVehicle = []; { if ((((_x emptyPositions "Commander")+(_x emptyPositions "Driver")+(_x emptyPositions "Gunner")+(_x emptyPositions "Cargo")) >= (count units _group)) && {((count crew _x) == 0)} && {(canMove _emptyVehicle)}) then { _emptyVehicle = _emptyVehicle + [_x]; if (_debug) then {diag_log emptyVehicle}; } } foreach ((position _zbeGroup) nearEntities ["Car", 300]); Condition: !(_emptyVehicle isEqualTo []) Action: _emptyVehicle = _emptyVehicle select 0;

Could write a separate module for this, ZBE_Unstuck. Would simply run a FSM on each manned ground vehicle and check POS every 5 seconds. If the vehicle doesn't move X meters within a certain timeframe, the vehicle is setPOS to findEmptyPosition nearest to original position. In fact, I'll work on this now as easy to do.

Expanded a bit on the empty vehicle behavior plan after some testing: The real pain is how to handle waypoints as they are never deleted when units complete a WP. Bla bla bla I just found the currentWaypoint command which will make it much easier to choose which WP to check for a long distance.

Wrote my first bit of code to break ground: if ((((_x emptyPositions "Commander")+(_x emptyPositions "Driver")+(_x emptyPositions "Gunner")+(_x emptyPositions "Cargo")) >= (count units (group player))) && {((count crew _x) == 0)}) then { wee = wee + [_x]; player moveInAny _x; } } foreach ((position player) nearEntities ["Car", 500]); Really loving the new moveInAny command and I believe a FSM is going to be perfect to handle group behavior.

Basic behavior plan: Need to think about what if the vehicle is armed or tank, even if the whole group can't fit may be worth picking up vehicle anyway for additional firepower. Need to put in checks for if the vehicle/aircraft is exploded before boarding so unit continues to WP, looking for other transport methods. Need to confirm that FSMs auto end for dead groups as documented in OFP days, may need to add isalive checks.

Would greatly depend upon which revive system was used as there is no universal solution. Awesome idea though, I'll put it on my project wishlist ;)

All one needs to do is use enablesimulation false to objects past X as I do in my caching module. Speaking of, I need to work on object caching. ---------- Post added at 03:52 AM ---------- Previous post was at 03:47 AM ---------- FSM driven AI are very difficult to program for. The best long term solution would be to switch over to behavior trees but such would be very expensive and require major changes in the core engine.

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 :)

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.

Added to the tracker, thank you! https://bitbucket.org/zorrobyte/zbe_cache/issue/5/bis_fnc_mapsize-for-nearentities

I worked previously with Atlasssian products in past employment, also a bit uncomfortable still with the sexism at Github. I'm willing to use Github if it means more developers will join in on the project. As for if the client or server needs to run, not too sure what you mean. As of now, WICT is script only and I've yet to document which functions run where. If you mean if/when it goes addon, I'd prefer if the addon only needs ran on the server. My Skype is ross.fisher91

I admit and agree, it was clumsy of me and not well thought out! My excitement gets ahead of me sometimes with projects. In the old DAC thread, I linked my DAC A3 "port" repo with the intent of giving Silola a head start and offered help in any way. I think such great creators such as Silola may not need my help and may take it as an insult as my tweaks were rather minor now upon thinking about it. Apologizes if anyone was offended or if I was "jumping the gun". My first Dev work and programming was due to ArmA, there are learning pains along the way ;) I'm excited about DAC, certain functionalities such as autoscaling AI based on player count is amazing! I have had players greatly enjoy using my caching module in place of DAC reduce groups so units maintain loadouts, ammocount etc. Permission is not required as ZBE_Cache is open source but Silola, feel free to use anything from ZBE_Cache to help make DAC better.

Interesting, I just read up on the Supports Module in the A3 DLC. As for "capturable" areas, AI spawning and the like, there are some similarities to WICT in a way. Would be interesting to see what can be learned. As the base capture module seems to be integrated into COIN in WICT, I would believe WICT would be useful in PvP missions with AI spawning off as players could "capture" areas to earn income to purchase vehicles, equipment. Combined with R3F, players could build up bases and AI could spawn to reinforce the area. I'm imagining a hybrid COOP-PvP mission type powered by WICT, would be interesting! Most pressing though before I get off topic, base capturing needs fixed and the MSO improvements to WICT still running when all players dead can be ported back over (along with others).

WICT has always been a script only release so no worries there. It may be nice at some point to compile an addon version but isn't high priority. As for F2/F3, it seems ArmAIIholic was trying to make it as easy as possible to users to use his work for MP. I'd like to keep WICT standalone and modularized as in not combine F3 into the WICT download so I'm not updating F3 in the WICT GIT. If someone wants to do this still, I have no problem making a branch with F3. The most pressing issue is to solve base capturing as currently it doesn't work. I converted RE to BIS_fnc_MP with not much luck, maybe the issue is in sandbox_exe.sqf? This is the author's documentation on MP implementation. @Kremator, has base capturing ever worked in A2/OA? @Wolfenswan - do you have a Bitbucket account? I'll give you repo access for GIT. If you don't have a GIT client, I personally love Smartgit.

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?