SQF functions over SQF scripts?

[ColonelSandersLite 0]

Seriously, the biki is getting me really pissed off.

twice now I've lost pages of material when editing. I guess I am going to have to go one step further and use notepad ahead of time.

Can't be as bad as the ofpec you've already submitted this post bug.

[mr.peanut 1]

LOL. I commented on all this way back in September and predicted this chaos. Check the discussion on the Biki Talk:Function page. I also suggested that the best solution would be the adoption of a new file extension for SQF syntax scripts: SQP or SQFP to indicate they run in parallel. Unfortunately, nobody was listening.

[crashdome 1]

LOL. I commented on all this way back in September and predicted this chaos. Check the discussion on the Biki Talk:Function page. I also suggested that the best solution would be the adoption of a new file extension for SQF syntax scripts: SQP or SQFP to indicate they run in parallel. Unfortunately, nobody was listening.

hehe.. yes I read that. Which is what prompted me to step in a bit. I have what I believe is a much more effective explanation for not only newcomers, but also for veterans.

Of course it wouldn't be complete without a few diagrams

[whisper 0]

keep up CD

the internet will "never" work without notepad

Correction : The Internet will never work without vi.

[crashdome 1]

I've redone some pages:

SQF

and

SQS

Please note also re-did the function page. I was going to merge it with SQF and realized it really does deserve it's own page.

[EDIT] Having done all this research and seen Suma's comments in various areas of the biki, I can see how it has become over-complicated by the community. We really don't need SQFP or SQP or any other new file extension. Truth is [*]SQS = line-by-line

[*]SQF = C-style

The only thing that makes a function is the call command. As a result of using the call command, you can only use SQf syntax. We as a community, however, have somehow seperated SQF scripts from SQF functions from SQS scripts, etc.. etc.. more than we needed to.

[UNN 0]

Quote[/b] ]The only thing that makes a function is the call command.

At this point, the only thing I would say is set in stone, when it comes to functions is:

They can return a variable of type Any.

But, isn't how the call command interacts with the clock cycle still up for debate? Obviously the sleep command, narrows the gap. But I've yet to see anything that says commands executed with call, behave in exactly the same way as if they were executed with Spawn?

Or, did you find otherwise?

Edit:

If your thinking along the lines of simplicity, then yes. But even then, the ability to return a variable, before some significant event / decision. Is still quite important?

[crashdome 1]

I guess that is where I have learned something new myself... it all rests on *literally* the call command. The code appears to be the same and appears to execute the same regardless of function or script (execVM or spawn). The reason there is a variable returned is because the functionality of the call command. Call is expected to return a result and it takes the last expression of the SQF code without a ; as that result. Which is why we can end with a ; and there is no result. If we take a function file (SQF file without a final ; ) and spawn it, it will produce the same results only parallel in execution. It *may* error on the last expression... perhaps someone with ArmA can verify... but the only reason it would error out IMO is because compile/spawn or execVM are trained to look for that final ';'.

By nature, the file or syntax does not return a result. Only the call command expects this additional behavior and therefore we call it a "function" instead of a "script" even though commands and base behavior is the same.

[UNN 0]

Quote[/b] ]The code appears to be the same and appears to execute the same regardless of function or script (execVM or spawn).

I know I haven't done this myself, which was why I asked in the first place. But what size functions were you calling?

[crashdome 1]

From what I recall (Igor did the tests at my request), they were short functions/scripts which produced 9000+ loops which incremented an integer by 1.

At the time, our biggest concern was timing them to determine if the engine was halted versus mission time resumed as normal.

None of them produced any error despite which way they were executed.

Now, in regards to your problem with Trigger fields and Init lines, I think the problem is merely how these code blocks are executed. I don't know if they use call for these internally or if they are run parallel via spawn or such? Are they compiled first? etc.. etc.. best to ask Suma how code-fields of objects are treated (e.g. Init Line, Activation Field, etc..). If he comes back and says they use something different internally than any command we have seen thus far, then atleast we know generally why those act differently - even if we don't know the specifics.

[EDIT] Keep in mind most of my results were from gathering experiences from Igor, you, Suma's posts on the wiki, etc...

I've made some assumptions, but until someone says otherwise I don't think they will harm anyone.[/EDIT]

[UNN 0]

Quote[/b] ]We as a community, however, have somehow seperated SQF scripts from SQF functions from SQS scripts, etc.. etc.. more than we needed to.

I agree, but perhaps not for the same reason? The C style syntax being used for everything now, is great. Used with the Compile command, it must reduce the overheads when calling code. I think the problem is, people now think the code executes in a different way than it did with OFP.

Quote[/b] ]I guess that is where I have learned something new myself... it all rests on *literally* the call command. The code appears to be the same and appears to execute the same regardless of function or script (execVM or spawn).

There are a couple of things I can think of that support your viewpoint:

From now on, most loops are going to be using waitUntil, for and while e.t.c All of there conditions behave like the call command did in OFP. I think waitUntil is the Arma equivalent to OFP's @ command.

Even in OFP, scripts were quite aggressive. If you looped a single script using exec, without a pause, you were likely to lock up the entire game. So it's not like there is anything inherent within exec, that shares resources. You had to pause the script yourself. So we can assume the same applies to execVM and Spawn.

Add to that, you can now pause code executed with call.

They all help narrow the gap between the call and execVM commands. But IMHO there are still enough distinctions left, to stick with specific terminology.

Ok, slightly revised. But this is what I think warrants the term function:

Code that returns a value.

Code that automatically halts the parent script until completed.

Code that executes at specific points (during startup and event handlers).

The last line hasn't been mentioned yet regarding Arma, plus I haven't tested this with Arma myself. But in OFP the call command allowed you to execute code in a specific order. For example if you used call in the init event of an addons config. The code would be executed before any groups were created and also before any other exec commands. There was a similar condition for MP startup to. This is quite handy if you need to prepare variables e.t.c for the addon, before anyone starts running scripts with it.

Quote[/b] ]If he comes back and says they use something different internally than any command we have seen thus far, then atleast we know generally why those act differently - even if we don't know the specifics.

Yep, I will take things on face value in the absence of any other information. I think execVM is just a modified version exec, to support C++ syntax and return a script handle. Spawn is a modified version of execVM, to execute pre-compiled code. call has been modified to handle pre-compiled code to.

Quote[/b] ]Now, in regards to your problem with Trigger fields and Init lines, I think the problem is merely how these code blocks are executed.

I don't think it's a big problem. For me it's no different to, not being able to use local variables in init fields. You just get used to doing without.  But I'm sure it will crop up at some point.

[crashdome 1]

You've pretty much said what my conclusions were.

The only thing I don't know is how functions interact with other scripts. I know they pause the parent script, but do others continue to operate during the "sleep" period. I am assuming so.

I don't agree that execVM is modified exec. Rather, I do think they are completely different. I think compile and spawn are new and developed to mimic exec but use the sqf parsing engine. I think execVM was created merely to make it even easier to call an SQF script (execVM is like calling compile and spawn in same line). By naming it similar to exec, it's easier to transition to as a coder.

I think call has not changed at all - except for the sleep and waitUntil commands which are huge for us vets but nothing to scream home about for those that never wrote a function in OFP.

Quote[/b] ]They all help narrow the gap between the call and execVM commands. But IMHO there are still enough distinctions left, to stick with specific terminology

Which is why I did not merge Function page in wiki into the SQF page. We also don't really need a "script" page just because we have "Function" page either. IMO scripts are everything... there is nothing distinct about them from everything else. However, functions are a distinct topic within scripts that merely describe the effects of using call

So other than that, I think we've beaten this topic to death

I really hope this enlightens those that are confused about functions vs scripts and I REALLY HOPE it persuades those still using SQS to migrate. It really only takes a few hours to learn to code in SQF style if you've done SQS. They are more flexible and have far more capabilities. So there isn't any excuse to stay with SQS anymore.

[EDIT] I see Hardrock has edited my pages and completely rearranged them. I don't advise the way he's organized it. (See previous paragraph to explain why). I also don't like the wording of it. Sections are all over the place. There are more categories than there is information. However, it still works I guess......

[EDIT 2] OK, it's looking better now.

[crashdome 1]

OK, within 48 hours all of my writing and efforts on the wiki have been deleted or replaced. None of it a result of discussion and completely without warning.

I take serious offense to that and just wish to say I will not be doing anymore direct contribution.

[deanosbeano 0]

hmm ,maybe this a good time to ask, would someone kindly consider , making a none official wiki for scripting ?

i dont do html etc etc. but the biki is a complete and utter shambles( all hardwork respected).

[nubbin77 0]

Forgive my ignorance of the internet... but anyone can just delete or edit entries on Wiki's? WTF how does anything important stay unmolested on ANY wiki? I would think that ass clowns would just put crap in for the sake of being ass clowns.

[Planck 1]

Quote[/b] ]

OK, within 48 hours all of my writing and efforts on the wiki have been deleted or replaced. None of it a result of discussion and completely without warning.

I think you are mistaken, if you had bothered to search you would have found the SQS and the SQF pages without too much bother.

Nothing whatsoever has been deleted.......think before you say things like that, and at the very least check further.

Planck

[crashdome 1]

In their defense, they have mods alot like forum mods to check on changes. The idea of a wiki is a good idea. Someone discovers something new or something changes then any old bloke can make that change in the wiki. The general consensus is that hopefully more good than bad happens. There is also the idea that sometimes talks and discussion are important before any major changes.

For example, my changes for the most part were additions and the pages I made were to correct two dead-in-the-water pages that were no longer necessary. I even warned of impending changes and commented on many. I left most product in tact and barely adjusted any sections to respect the idea that my opinion of how it should look might not be the majority consensus.

The reason I am upset, is for the sole fact that a major change has taken place in which one person had sole discretion and there was no discussion about the changes being made. I believe these changes would have been brought about over time by the community anyways. However, that does not warrant behavior like I saw IMO.

I respect the intentions and the hardwork of the individual, but feel there has been no respect for my hardwork.

Quote[/b] ]I think you are mistaken, if you had bothered to search you would have found the SQS and the SQF pages without too much bother.

Nothing whatsoever has been deleted.......think before you say things like that, and at the very least check further.

Planck

Yes, there have been deletions and if you check history you'll see that.

[EDIT] OK, by technicality you can say "move" or "replace" interchangably for some of them. However, my point does not change.

[EDIT 2] I apologize to everyone if this has derailed the thread. I think I've learned my lesson and will stay away from the wiki. Whether it's fate or coincidence, everytime I go near that thing it blows up in my face.

On the other hand, is it true that compile will be required in front of preprocessfile before you can successfully call it? e.g....

<table border="0" align="center" width="95%" cellpadding="0" cellspacing="0"><tr><td>Code Sample </td></tr><tr><td id="CODE">myFunction = preprocessfile "test.sqf";

myResult = call compile myFunction;

and can you alternatively do this:

<table border="0" align="center" width="95%" cellpadding="0" cellspacing="0"><tr><td>Code Sample </td></tr><tr><td id="CODE">myFunction = compile preprocessfile "test.sqf";

myResult = call myFunction;

anyone have concrete proof of this?

[zyklone 1]

On the other hand, is it true that compile will be required in front of preprocessfile before you can successfully call it? e.g....

<table border="0" align="center" width="95%" cellpadding="0" cellspacing="0"><tr><td>Code Sample </td></tr><tr><td id="CODE">myFunction = preprocessfile "test.sqf";

myResult = call compile myFunction;

and can you alternatively do this:

<table border="0" align="center" width="95%" cellpadding="0" cellspacing="0"><tr><td>Code Sample </td></tr><tr><td id="CODE">myFunction = compile preprocessfile "test.sqf";

myResult = call myFunction;

anyone have concrete proof of this?

Yes, you have to run compile first.

The second version of those two is the only one that should be used as otherwise you have to run 'compile' each time you want to run the function.

It's best to do

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

myFun = compile preprocessFile 'myfun.sqf';

Once in init.sqf, after that myFun will contain Code. And can be 'call'ed without extra processing. If you do 'call compile myFunction' all the time you loose much of the added performance since you are just storing a string instead of Code.

Or even worse if you preprocess the file all the time then you'll be doing much unneeded disk IO.

[crashdome 1]

Great. I understand perfectly now.

I will have to watch what say as we all know in OFP it was not necessary.

[sbsmac 0]

Actually there is another pattern you can use:

File "my library.sqf"

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

library_func1={ hint "lib1";};

library_func2={ hint "lib2";};

then:-

<table border="0" align="center" width="95%" cellpadding="0" cellspacing="0"><tr><td>Code Sample </td></tr><tr><td id="CODE">call compile preprocessFile "my_library.sqf"

call library_func1

call library_func2

Useful for packaging related functions.