Preloading scripts?

[joltan 0]

Ok, one question remains after skiming trough the OFPEC function tutorial and the library:

The fact that a function effectively halts the script it is executed from until completion (else it couldn't possibly return a value) may not always be a good thing. The executed script may require some pauses without stopping the main script, but have no need to return a value to the main script.

Is it possible to preload (with loadFile) a normal script, so the computer doesn't have to access the harddisk repeatedly (reducing lag if the script is executed with a high frequency), but still having it run as a seperate, independent script (thus allowing for pauses, halts, loops, etc.)? Something like

<table border="0" align="center" width="95%" cellpadding="0" cellspacing="0"><tr><td>Code Sample </td></tr><tr><td id="CODE">MyScript=LoadFile "myscript.sqs"

...

[] exec MyScript

No, from my testing the example doesn't work, but it would be nice if something similar would be possible.

[denoir 0]

Exec works only with files. It takes a string as an argument that contains the path to the script.

Call on the other hand takes a code string as input.

<table border="0" align="center" width="95%" cellpadding="0" cellspacing="0"><tr><td>Code Sample </td></tr><tr><td id="CODE">

MyFunction = loadFile "MyFunction.sqf"

[] call MyFunction

If you want to use macros and C++ style comments then preprocessFile function should be used instead of loadFile. You have to remember though that preprocessFile does not work when the scripts are integrated in an addon.

[Spinor 0]

Quote[/b] ]Is it possible to preload (with loadFile) a normal script, so the computer doesn't have to access the harddisk repeatedly (reducing lag if the script is executed with a high frequency), but still having it run as a seperate, independent script (thus allowing for pauses, halts, loops, etc.)?

I'm not 100% sure but I think when putting a script into an addon, it is preloaded when launching OFP. You don't necessarily have to create a genuine addon for this. Simply put your script(s) into a folder, pbo'it and put into the addons folder. The path is then given by "\ADDONNAME\SCRIPTNAME.sqs". Calling a script with exec should not cause HD access in this case.

[joltan 0]

Exec works only with files. It takes a string as an argument that contains the path to the script.

Yes, but if I use 'call' to start a preloaded script (i.e. no preprocessed function), won't the main script (from which I call it) wait for the script to finish before continuing, or will this get executed independently (like a script called with the exec instruction)?

My idea is to avoid the repeated fileaccess (by preloading it once) and just call it from memory, not the hd, while still having all the advantages of a normal script (i.e. I can have waits and halts). I don't need it to return a value and I want to avoid having the main script waiting for the preloaded script to finish. If this isn't possible, then it should definitely go into OFP2.

@Spinor: I'm making missions, and I'm just trying to optimize performance as much as possible, so making it an addon wouldn't really help me.

[Spinor 0]

Quote[/b] ]Yes, but if I use 'call' to start a preloaded script (i.e. no preprocessed function), won't the main script (from which I call it) wait for the script to finish before continuing, or will this get executed independently (like a script called with the exec instruction)?

'call' can not be used to start scripts, only functions (i.e. code which is executed immediately).

Quote[/b] ]@Spinor: I'm making missions, and I'm just trying to optimize performance as much as possible, so making it an addon wouldn't really help me.

It is not really an addon (you don't need a model or even a config.cpp), but rather a different method to store your scripts.

I wouldn't worry to much about accessing the HD anyway. I think Suma once mentioned that frequently accessed scripts (or in fact any files) are automatically cached to memory by Windows.

[joltan 0]

In a mp environement having to distribute script pbos just to play a few missions isn't really worth the trouble (usually). Doing something like that for a complex SP campaign (or a mod) on the other hand might be sensible.

Well, if the cache covers the performance hit caused by the script, then I guess I was trying to fix something that's out of my hand anyways... not to mention, that if scripts can't be preloaded at all, then I don't even have the means to do anything about it! ;)