Fix execNextFrame out of order in preInit

[PabstMirror]

Exec next frame uses the logic diag_frameno != GVAR(nextFrameNo),
but between preInit and postInit there can be more than 1 frame.

Items can be called out of order and items added can be called in the same frame (see C/D):

Before:

[13657] - Adding A (@preInit)
[13659] - Adding C (@PostInit)
[13660] - Running C, adding D
[13660] - Running D
[13661] - Running A, adding B
[13662] - Running B

After:

[2455] - Adding A (@preInit)
[2457] - Adding C (@PostInit)
[2458] - Running A, adding B
[2458] - Running C, adding D
[2459] - Running B
[2459] - Running D

This fix addes an extra conditional, pushing everything into the first buffer until it has been run.

[commy2]

Is there any reason why we skip the frames between pre and postInit in the first place?
Because OEF eh works for that just fine.

[PabstMirror]

I'm not seeing any difference between stacked onEachFrame and missionEvent EachFrame.
Both can be installed in preInit and aren't called until 2 frames later.

Install @ 21677
onEachFrame @ 21679
EachFrame @ 21679

Interestingly, we moved from preInit to postInit in #312 because of some problem with 3den in 1.58, which seems to have been fixed. But this wouldn't really have any effect except making the first frame run the same as postInit's frame.

[commy2]

postInit isn't frame 2. It's the frame after all objects are initialized. It only happens to be frame 2 on dedicated servers, because BIS_fnc_initFunctions isn't waiting for !isNull player to continue with postInit.

[commy2]

I think it's weird that we will be doing a
if (GVAR(nextFramePreInit) check every frame, despite this being true every time after mission start.

Somehow I don't feel like this is worth it just to guarantee the order in which these things are executed.

[PabstMirror]

Our code did something like

3den attribute: execNextFrame: {setVar on group} 
postInit: execNextFrame : {something that uses group var};

and the order was all wrong and things broke

It does add overhead to the adder, not each frame; but still not ideal.

I suppose we can just find a different workaround.

[commy2]

It does add overhead to the adder, not each frame; but still not ideal.

I see. Can you explain why it messes up the order? I still don't understand why that would be just by leaving out a few frames.

[PabstMirror]

Opps, looks like the problem was simpler than I thought.

Fixed by just changing the initial GVAR(nextFrameNo)

[commy2]

And now I understand what the problem was too. Merge?