Server FPS drops caused by masterIdTracker about acre2

[tbeswick96]

A comment on https://community.bistudio.com/wiki/allMissionObjects

Be VERY careful with the use of this command. It is very demanding as it must iterate through all mission created objects. Particular care should be taken exercising this often on dedicated servers.

[Sniperhid]

We are aware of this design. Note this is the most reliable method to reliably ensure all containers are checked at once and thus all radios are discovered and checked by ACRE.

Whilst the FPS 'drop' still exists compared to last stable release some significant improvements were made
#39 - Should reduce the load by 50% on average (maybe more/less in your case).
And yes compared to last stable the checks happen less frequently (every 10 seconds versus 1 second).

This pattern has existed in ACRE2 for a longtime and I have played many large coop missions without issue, even if server FPS periodically takes a hit. From my own experience 300 AI without caching/headless client can cause quite a server load without ACRE2.

If someone wants to propose a better implementation by all means, this is largely an old system that could possibly benefit with a re-design.

[kami-]

How about have 2 configurable options:

1. Leave the current system running by default.
2. Have an option to disable current tracking loop to discover radios. Instead, use dedicated ACRE API functions to add radios to units/vehicles. This would let power users to manage the radios manually and improve performance. Would untracked radios break ACRE?

[jonpas]

@kami- No, as soon as we add something like that we will definitely get reports of issues which that scan is required by to work properly.

For now we (ACRE2Team) don't have plans on improving it, I tagged the issue as possible optimization. Maybe once we announce this GitHub publicly someone will take up the task, however it's no easy task.

[tbeswick96]

Wrapping doFullSearch in a spawn completely removes the FPS drops

if(GVAR(doFullSearch)) then {
    [] spawn {
        ...
    };
};

[Sniperhid]

And radios can move locations between frames thus it checks at a given instant (single frame). If someone was in the process of dropping/picking up a radio it would be possible for the fullsearch to simply not find the item and assume it had been deleted resulting in its data being garbage collected. So using a spawn removes the reliability of the check.

[tbeswick96]

I reverted my changes back to how it was since the latest commit for masterIdTracker, and we ran the same mission on Saturday.
There were no desync issues relting to this, so I think the optimisation you guys did already has solved the issue.
The spikes every 10 seconds still persisted, however it did not cause any issues at all. This was with the mission with roughly 400 ai placed, with roughly 150 maximum active and simulated at any one time thanks to caching.

All in all, I don't think you need worry about this issue :)

[Soldia1138]

Thank you for the feedback

[NouberNou]

Close?

[PabstMirror]

Not perfect accuracy, but a good visual of the change from 904 to current master:

904 - http://i.imgur.com/asS5roQ.jpg

• Max is about 25ms over normal every second

Current - http://i.imgur.com/hRiL43f.jpg

• Max is about 17ms over normal every 10 second

So a roughly 15x speedup.

You could possibly split the scan over multiple frames, and only garbage collect the ID if it's been missing for multiple scans. But doing it atomically is the safest and simplest way to get it done.

[jonpas]

Yeah multiple frame is a problem as things can change during those frames, what you proposed is something @snippers was thinking as well. It's quiet a good improvement he did already, I'd say close this issue and further improvements can be done at any later time.

[rebelvg]

As a mission maker you can remove items from ai units and if you have a lot of items in your boxes, make them have "infinite" number of items, constantly re-adding items that were taken by players. Or you can make the system that re-adds items and virtually counting how many were taken, so that box doesn't really have infinite items.
Here's an example.
https://github.com/rebelvg/framework.VR/blob/cca33337799cc5e43fca7b167b98b176835bf4fb/framework/functions/fn_frameworkInit.sqf#L188-L239
This makes items count to 2 items and re-adds as soon as item was taken. Basically it makes stuff like bandages infinite which is not a really big problem, mags are not touched by this.

[Sniperhid]

Further optimisation and speedups to the master ID tracker were implemented in #179

On a side note #180 offers some flexibility to radios that would traditionally be garbage collected.