Efficiency of waitUntil, parallel or serial?

[CarlGustaffa 4]

Hi

I'm wondering what is considered best practice wrt waitUntil efficiency when waiting for several scriptDone statements.

waitUntil {scriptDone _scripthandle1 && scriptDone _scripthandle2 && scriptDone _scripthandle3};

//or something like this

waitUntil {scriptDone _scripthandle1}; //more likely to finish first.
waitUntil {scriptDone _scripthandle2}; //more likely to finish second.
waitUntil {scriptDone _scripthandle3}; //more likely to finish third.

//or the reverse order

waitUntil {scriptDone _scripthandle3}; //more likely to finish third.
waitUntil {scriptDone _scripthandle2}; //more likely to finish second.
waitUntil {scriptDone _scripthandle1}; //more likely to finish first.

Should I also combine waitUntil with sleeps? What is best advice?

[Muzzleflash 111]

If you can afford to sleep:

_handles = [_scriptHandle1, _scriptHandle2, _scriptHandle3];
waitUntil {sleep 0.5; {not (scriptDone _x)} count _handles == 0};

Of if you think that it would be better checking in serial you could do this:

//Assumes that 1 was started before 2 and all takes about equal time
_handles = [_scriptHandle1, _scriptHandle2, _scriptHandle3];
{
  waitUntil {sleep 0.1; scriptDone _x};
} forEach _handles;

//All scripts done now...

Don't really think there is much to say on efficiency on the matter. Time is probably better spent optimizing the actual spawned scripts - or if possible make it just one larger script instead.

Edited August 3, 2012 by Muzzleflash

[CarlGustaffa 4]

Thanks. Good suggestions.

[cuel 25]

If applicable you could use

 call compile preProcessFileLineNumbers "script1.sqf";
 call compile preProcessFileLineNumbers "script2.sqf";
 call compile preProcessFileLineNumbers "script3.sqf";

since that would halt the current script until the other scripts has finished running

"execVM" is basically short for

[] spawn { call compile preprocessFileLineNumbers "script1.sqf"; };

from my understanding.

Edited August 3, 2012 by cuel

[neokika 62]

Hi,

Well my suggestion will be a bit different, what about not using any of the waituntils? Are they needed?

Imho, this type of procedure should be avoided.

So, my suggestion would be, remove that extra scripting thread with the waitUntils and modify your scripts to do this by themselves.

Example (Not tested):

TAG_fnc_scriptDone = compile preprocessFileLineNumbers "fn_scriptDone.sqf";

//fn_scriptDone.sqf

//Function to flag increments

_wanted = 3; //How many scripts to wait for?

if (isnil "TAG_doneScripts") then
{
TAG_doneScripts = 1;
}
else
{
TAG_doneScripts = TAG_doneScripts + 1;
};

if (TAG_doneScripts == _wanted) then
{
//All wanted scripts are done
//Do something when that happens
};

//Each of your scripts

//Random script

//...code...

//End of script, lets flag this event
[] call TAG_fnc_scriptDone;

Note this is just a very simple/odd example showing one (of many) way to not having to create another parallel thread.

[Deadfast 43]

What scripts are we talking about here?

If it's initialization and there are no interrupts within you should just use call compile preprocessFile instead of execVM. That way the scripts will be initialized in a guaranteed order - one by one as they were called.

[CarlGustaffa 4]

It's just a "looping" weather script, spawning 3 different processes:

1) Serial - controlling overcast and fog in serial since they can't be run in parallel. Freq = moderate.

2) Rain - adjusts, varies, and keep rain level overriding whatever the engine wants to do. Freq = very high.

3) Wind - basically brings winds up to next level in small steps to avoid the wind sound bug. Freq = low.

When these three are complete, the cycle starts over with a call from the controlling script with next set of parameters to adjust towards. Even if it deals also with temperatures, latitudes, snow etc, I don't want it to become too intense wrt cycles, as there are other things going on as well. Rain will produce steady rain or showers depending on circumstances, using some kind of clipped curves, and the idea is to have these sync up in MP resetting the curve offsets at given intervals with smooth transitions in between.