Fix issues with PerFrameHandlers

[commy2]

ref: #229, #230

• makes CBA_fnc_addPerFrameHandler and CBA_fnc_removePerFrameHandler safe to be used in scheduled environment.
• moves stuff around in FUNC(onFrame) to reduce overhead
• adds debug log when more than 1kk PFHs were added per mission.
• adds PFH save game compatibility

I'm currently on 1.55 dev and there seems to be no array size limit, so I can't really test #229.

[jokoho48]

@commy2 why you remove the clean up of the perFrameHandlerArray again? that remove every performance improvement i did?

[commy2]

Can you explain what you mean? There are no checks added in this PR, only stuff removed or moved around.

[jokoho48]

you remove https://github.com/CBATeam/CBA_A3/pull/236/files#diff-173548a824c3a52bc2c10f270fd8dc72L44 this completly and that cleanup the perFrameHandlerArray to improve performance and remove nil from this perFrameHandlerArray array so that dont run throw the Basic Frame handler

[commy2]

There are no nil entries in GVAR(perFrameHandlerArray), so this isNil is redundant.

Try this:

count cba_common_perFrameHandlerArray
-> 3

0 call CBA_fnc_removePerFrameHandler

count cba_common_perFrameHandlerArray
-> 2

[jokoho48]

ok now i see what you did 👍

[commy2]

Yeah. You might have been thinking of GVAR(PFHhandles).

cba_common_PFHhandles
-> [0,1,2]

1 call CBA_fnc_removePerFrameHandler

cba_common_PFHhandles
-> [0,any,1]

[PabstMirror]

This forEach loop needs to be above line 32 or it will fail on 2nd call to :

x_A = [{      diag_log text format ["---%1 - A Running %2", diag_tickTime, (_this select 1)];  }, 5, []] call CBA_fnc_addPerFrameHandler;
x_B = [{      diag_log text format ["---%1 - B Running %2", diag_tickTime, (_this select 1)];  }, 5, []] call CBA_fnc_addPerFrameHandler;
[x_A] call CBA_fnc_removePerFrameHandler;
[x_B] call CBA_fnc_removePerFrameHandler;  

[PabstMirror]

All we really need is to find index of the top level _handle in the perFrameHandlerArray array, so, we could add an exit to the loop and skip the set I think.

[commy2]

Using a find would be slow when GVAR(PFHhandles) get's big. With this method you only have to iterate through the PFHs that are still active. No idea which one is better. This is what already was there.

[commy2]

Derp. The problem is that the public handle is pushed to GVAR(PFHhandles) (which is for the internal handles, those who can change).
Thats why removing the PFH twice "works". The loop auto corrects the internal handle...

[jokoho48]

i knew something look wrong hmm

[commy2]

Should be fixed, @PabstMirror

[commy2]

I think we should use the debug in this PR to figure out what PFH is added more than a million times in missions running longer than 4 hours. Maybe we can fix that (if it's a PFH in ACE) and we don't need to change the handles at all.

[Killswitch00]

I agree - the debug printout should be useful in identifying the PFH overruns