What is the difference between these instructions..

[fuerst_von_butz 1]

call compile preprocessFile "somescript.sqf";
execVM "somescript.sqf";

And while we're at it, what does spawn do?

Cheers!

[kylania 567]

That was explained in one of the links I gave you in your other thread. If you're going to run a functions file just once go ahead and use execVM. That will read through and execute the script each time it's called.

If you're going to use the file more than once you'll want to precompile it to make it faster.

From this page:

// we compile and preprocess this script because we wish to call or spawn it repeatedly
  T_someScript = compile preProcessFileLineNumbers "someScript.sqf"; 
  execVM "myLoop.sqf"; // we can use execVM because this script is only ran once, and not repeatedly.

spawn will execute code in a separate thread along side whatever called it. It also allows you to sleep within the spawn unlike call.

[fuerst_von_butz 1]

Hey,

first of all thanks for the quick reply and sorry that I asked even though you already linked me a decent article. I admit that I only scrolled through the pages and just read interesting parts. I missed the precompiling part in Sickboy's "view on (Multiplayer) Scripting".

So let me try to summarize:

- basically all three of these commands (execVM, spawn, call) are used to start sqf scripts

- execVM will read a sqf file from the filesystem and compile it each time and thus is the most costly instruction

- spawn and call work only with a preprocessed and precompiled script and thus are less costly

- spawn is an asynchronous instruction, the caller will not wait for a result or the spawned script to finish, thus sleep is allowed

- call is a synchronous instruction, the caller will wait for a result/the called script to finish, thus sleep is not allowed

Is this more or less correct?

Thanks again, kylania.

[kylania 567]

Spawn can run raw code too not just scripts, just wrap it in curly braces. On my phone or I'd put an example. Heh. Otherwise sounds right.

[galzohar 31]

Sleep can actually be used in a called function, but only if the calling script is allowed to use sleep.

Places where sleep cannot be used will also run the code until finished and never interrupt it in the middle to run other scripts (which can also result in FPS stuttering if it take a really long time to run), and there should be some more restrictions like maximum iteration count on loops as far as I'm aware.

WaitUntil has the same restrictions as sleep.

Calls can return a value that can be assigned to a variable (aka _blah = [parameters] call fnc_blahFunction), while execVM returns only a handle to the script, which can then can be used pretty much only to terminate the script or check if the script is done (and if you need either of those, you're probably better off accomplishing the same result in other ways that are less likely to make you create bugs).

[fuerst_von_butz 1]

Thanks guys, I'm getting there, slowly :)

Are these two instructions equivalent then?

spawn compile preprocessFileLineNumbers "somescript.sqf";
execVM "somescript.sqf";

Bonus question:

When the creator of the BTC revive script wants you to add this line into the init.sqf

call compile preprocessFile "=BTC=_revive\=BTC=_revive_init.sqf";

his purpose is that everything else stops until the script is fully initialized, correct? This line was the main reason I started this thread :)

Edited July 31, 2013 by fuerst_von_butz

[galzohar 31]

1. Yes.

2. Yes. Well, not everything, but the calling script (in your case init.sqf) will wait until BTC revive is initialized.

Keep in mind that since init.sqf can use sleep/waituntil, then so can =BTC=_revive_init.sqf, even though it is called. When calling your own functions you should make sure you aren't creating a deadlock (1 function waiting for 2nd function to finish while the 2nd function actually needs the result from the 1st function so both are stuck). Then again, when you're spawning scripts, you have to make sure they don't fail randomly due to the order in which they run (for example, script 1 uses a variable defined in script 2, but script 1 might run before script 2 and thus give and error and/or not work correctly).

[fuerst_von_butz 1]

Thank you, it all makes some sense now :)