Internal addon scripts

[chris330 0]

Dear All,

I am investigating ways of getting addon internal scripts to go faster. I was wondering is it possible to include a .sqf file in a .pbo and have the addon run the function internally? I am working on an idea I had a few weeks ago and I want to make sure that if it is ever used in multiplayer it will be super smooth from a latency standpoint. Thus I would rather avoid doing any maths intensive evaluation in a script, I would prefer it done only in functions.

So my question is, is it possible?

[UNN 0]

You have to use LoadFile instead of PreProcess to load functions from a pbo.

But I don't think commands in functions are processed any faster than commands in script?

They just grantee that all the commands in the function get executed in a single instance.

In some cases putting a lot of cpu intensive commands into a function can cause lag, as a function stops OFP doing anything else until it's finished.

[chris330 0]

But I don't think commands in functions are processed any faster than commands in script?

They just grantee that all the commands in the function get executed in a single instance.

In some cases putting a lot of cpu intensive commands into a function can cause lag, as a function stops OFP doing anything else until it's finished.

Thanks for the reply, I can normally count on you to help me out with these kind of questions

So putting too much into a function is not necessarily a good idea. I presume then a script which causes a function to execute will wait until the function is complete before moving onto the next line?

So the only way to make a script go quickly is to keep the code lines down to a minimum.

Can I ask then what is the main benefit of a function? I always thought it was there to make things go faster?

[UNN 0]

Quote[/b] ]Can I ask then what is the main benefit of a function? I always thought it was there to make things go faster?

I'm not sure exactly what preprocess does apart from the obvious. How OFP stores a pre-processed function compared to a regular script, is a mystery.

But as we are stuck with loadfile with pbo's, assuming loadfile does not do anything special. I see the advantages as:

Sharing common code across multiple scripts. Removing script command duplication. In theory it should lead to smaller scripts.

Strict control over the order\timing, commands are executed and being able to stop a script while a specific value(s) are calculated.

Perhaps I got the wrong end of the stick? It will run a group of commands quicker, but at the expense of OFP as it halts everything else. But I cant help thinking that:

<table border="0" align="center" width="95%" cellpadding="0" cellspacing="0"><tr><td>Code Sample </td></tr><tr><td id="CODE">_XVel=Call {(Sin (GetDir Player))*1000}

Does not run any quicker than?

<table border="0" align="center" width="95%" cellpadding="0" cellspacing="0"><tr><td>Code Sample </td></tr><tr><td id="CODE">_XVel=(Sin (GetDir Player))*1000

[vektorboson 8]

Quote[/b] ]Can I ask then what is the main benefit of a function? I always thought it was there to make things go faster?

I'm not sure exactly what preprocess does apart from the obvious. How OFP stores a pre-processed function compared to a regular script, is a mystery.

Well, it's not really a mystery. Only difference between preprocessfile and loadfile is, that it runs a C-preprocessor on the file, whereas loadfile returns the contents as is.

Both return a string (just a simple string); and 'call' interprets a string as OFP-script-code.

The speed improvoment comes from storing the function in a string variable and calling it when necessary.

Btw. all those values in config and description are nothing else than strings that are interpreted as script code.

Then there are those SQS-scripts. They are line-oriented, and are loaded into OFP as a list of lines. Look into a savegame (which is a simple config.bin). But every line for itself should _basically_ act like a function, with the exception, that special functions/tokens like '~', '#', '&' and '@' are allowed (and of course 'goto'.

Quote[/b] ]

Perhaps I got the wrong end of the stick? It will run a group of commands quicker, but at the expense of OFP as it halts everything else. But I cant help thinking that:

<table border="0" align="center" width="95%" cellpadding="0" cellspacing="0"><tr><td>Code Sample </td></tr><tr><td id="CODE">_XVel=Call {(Sin (GetDir Player))*1000}

Does not run any quicker than?

<table border="0" align="center" width="95%" cellpadding="0" cellspacing="0"><tr><td>Code Sample </td></tr><tr><td id="CODE">_XVel=(Sin (GetDir Player))*1000

Of course the latter should run faster, as the former has to parse the 'call' command, which then executes the string and returns the value.

[chris330 0]

This is really good stuff thank you to you both

Dear UNN,

I really like the idea that I can shorten scripts down by calling a function to do some complex stuff which I don't have to have in the script. This is the part of functions that really appeals to me, and you summed it up perfectly. Also the timing issue is very important too

Dear Vektorboson,

Thanks for your reply So can I conclude in part then that if I can get something (of a realistic - not an execessive - size) into a function then it is best to do so, because of the pre-prepared aspects?

Thanks again to you both for your replies

[General Barron 0]

Can I ask then what is the main benefit of a function? I always thought it was there to make things go faster?

The main benefit of a function is that it can return a value. You cannot execute a script and have it return a value to the script that started it. You can do this with a function.

In many cases this just makes things more convienient, and scripts 'cleaner'. Technically, in many cases you could get around the use of functions by having a lot of "goto" jumps in your code. But this type of code is (a) difficult to read and understand, (b) would require tons of needless repeating of code across scripts (especially by different authors), and © actually runs slower because of the way OFP handles "goto"s (it searches from the top of the script, line by line, until it finds the label).

There is one very useful example of something that can NOT be done without a function. This is the @ command, which waits until a condition is true. Without functions, you can only use what you can fit in parenthesis here. But with a function, you can have some pretty neat conditions.

----------------

But to repeat myself: the best use of functions is to make scripts as understandable as possible. If you keep repeating a set of commands throughout your script, then putting them all into one function might make sense (even if the function is in a LOCAL variable within the script). If you keep repeating a set of commands across a couple different scripts, then it might be a good idea to store those commands as a function in a global variable.

The more organized and readable a script is, the easier it is to develop, debug, and improve. Don't sweat the actual 'performance' of a script too much: unless it is doing something hundreds of times a second, all the time, then it really will have no noticable impact on performance. Unless you are writing a very large script system, such as the ECP, CoC's NS, etc, the impact your scripts have on performance will be negligable compared to other things such as island size, object count, model detail, bullets in the air, etc.

----------------

One thing to keep in mind though: there is a limit to how many global variables OFP can handle at one time without corrupting savegame files. That is, if there are too many global variables in use in a SP mission, you will not be able to save and load a game from that mission. This is the infamous "savegame bug".

The limit of global vars is actually quite large (hundreds?), so this problem has really only been noticed as a result of a couple large scripting projects running at one time (example, the old ECP combined with a heavily scripted mission). But, since it exists, it is always a good idea to try and limit the number of global variables a given set of scripts uses. Arrays of any size only count as 1 var, so they are a good way to combine many global vars into one.

[chris330 0]

Quality stuff. Thanks very much General Barron, that's a load of stuff I really wanted to know about, and well explained too