CPU load

[THobson]

I imagine the answer is going to be a combination between how much code is above the label, and how complex the condition being checked is. With that in mind, it seems likely that an @might be faster than a ~0.5 delay, if it is down under a bit of code.

Good stuff to keep in mind, instead of just blindly making loops everywhere, in fear of using an @condition.

I fully agree.  Each case needs to be checked, my 5,000 @s vs 5,000 loops give a very clear result the @ won by a mile - and the loop was at the top of the script (the first line after the comments and the _this select lines)

In addition to running a script with a goto to a lable that doesn't exist, try running one with mutliple duplicate lables.

My experience - but I have not tested exhaustively - is that the scriipt will continue at the upper most occurance of the lable.

My flag changing script had a loop with a delay of 11.11 seconds, even replacing that with an @ seemed to improve things.  I only had 33 instances running so it could have been psychological.  I need to try it with a few thousand.  The problem is I think my company will stop paying me if I don't spend some time with them.  I'll put it on the list of things to do.

[Mikero]

>gotos cause scripts to start at top.

A *minor* tweak here that is more consistent with GenBarron's statement about falling thru (no label=no errors)

The engine is likely to scan downwards and then start at top if not satisfied.

This would make

#very_slow;
....
goto very_fast;
goto very_slow;
.....
#very_fast

Indeed I have seen apparently convoluted code do similar to this (and think there was an example in an earlier post or two on this thread)

@Hobson

the scriipt will continue at the upper most occurance of the lable.

in which case it would blow my theory out the door, UNLESS all of these labels were after the goto. (you're not specific about 'uppermost')

>re-reads file

I don't think that's true, i 'think' it uses it's in memory copy because I've never been succesfull in altering a *running* script. (one that doesn't exit) Can easily be wrong here and a ten second loop displaying a hint would prove one way or other.
----
I think what needs to be established here is

1) is the file re-read.

2) is there a difference between forward goto's and reverse ones.

3) depending on 2) is the file re-read.

The answers may make incredible differences in performance.

[THobson]

Okay:  I have not investigated this in detail, but my experience is (if I am remebering correctly) that a lable above the goto will be selected in preference to a lable below the goto.  I do need to check but my recollection is:


#lable

goto"lable"

#lable
never get here

I am at work and cannot check I am remebering correctly.

[Fragorl]

Gee, what an excellent discussion!

So, as a result of the fact that script searches the entire length of the sqs from top to bottom, you are saying that I would be better off replacing my 0.01 loop with this:

#LoopYouAreBad
cmd
cmd2
cmd3
~0.01
cmd
cmd2
cmd3
~0.01
cmd
cmd2
cmd3
~0.01
cmd
cmd2
cmd3
~0.01
cmd
cmd2
cmd3
~0.01
goto "LoopYouAreBad"

or something similar? Perhaps even more commands between the goto and the # ? And I would benefit from putting all of this as close to the top of my sqs as possible?

Whoever said 'scripting is like black magic' - you were dead right.

I will experiment with these two concepts next time I get the chance, possibly tomorrow.

Assuming we haven't already, isn't it time to get confirmation from the people who wrote the code themselves- i.e. Bohemia Interactive - by starting a topic on the official forums? Or has such confirmation already been attained?

[THobson]

Fragorl:

In general I would never suggest a structure like that in preference to a straightforward loop.  It is untidy, error prone and ugly.  BUT:  In some circumstances, where a script will be run many times simultaneously and where speed is critical it might just be excusable.

A lot of this discusion has been about @ vs a goto loop.  Not mentioned so far is a goto loop vs a forEach loop or a while - do loop
I am developing a strong preference for these, especially the forEach loop, but have not tested their impact on performance.  My guess is that forEach will beat a goto loop because the program pointer doesn't have to go anywhere.

[Dubieman]

Yeesh, just read all four pages. Way to start an interesting topic Thobson.

I only want to comment on one thing. About dead bodies, it was said they are turned into objects a little while after they die, I don't think that's true. I've grouped people to me and then set their health to 0 via the slider and previewed the mission. Come to find out, my dead buddy was part of the team, still listed on my group list and on the screen as number 6. I could order him to do stuff yet being dead, he'd just respond negative after a while. He even reported enemies when I placed some east troops around him. So I wonder if that could increase CPU? Or is what I said a special circumstance, any other unit would just die and cease its AI routines?

I've also tested some of the dead body lag effects in one of my non released missions, simulating a DDay invasion. You guessed it, tons of troops, boats, MGs, mortars, and tons of enemy troops negoitiaging the hillside while firing down on us. Noticeable lag I can tell you that. Now I used a delete body script which really seemed to help out near the middle and end of the mission. I only deleted certain people that the player would not want to look for weapons from so I could keep the look of carnage on the beach while getting rid of any lag causers who were out of view. But I may be wrong on bodies, since I don't really know.

@your enviromental sounds: I forget if you're able to put the sound object in. You know its hidden in those drop down menus under empty and there are objects that I thought just repeat the sound over and over again, no trigger needed. May be wrong on that too.


EDIT: Now that I'm thinking about it, if I'm on to something on the dead AI still being a part of the team and what it means to other dead then maybe when the unit dies, he is just ungrouped so he can't talk to them anymore. A single unit can't really communicate with anyone else, especially when they are dead. I think I could support this by saying what happens when you setdammage 0 to a dead unit?

Hmm, after testing my idea doesn't quite work out all the way. Someone prove me wrong.

[THobson]

I know people delete bodies to cut down on lag.  I don't want to do any of that.  What we were talking about though was the lag generated by having mutiple armour units nearby.  That lag seems to diminish after they have been dead for a while.

I started off using Sound Objects.  Several problems - you can't create a sound object, nor can you move it, also they do make the sound over and over, for a while, but not for hours.  Eventually they seem to run out.  I want the sounds only under certain circumstances so I need to be able to move or create them and I want the sound to be heard hours after the start of the mission.  I have used triggers only as a last resort.

The Wolf Packs are different.  I use my own script to create those.  I might do something similar with the other sounds.

[General Barron]

@ Dead bodies

I'm sure that they turn into static objects after a while. The fact that you can't 'bring them back to life' after a certain amount of time supports this theory. So does their output if you print them via the 'format' command (it says "STATIC" and looks like any other static object).

The reason the lag difference is so noticable when deleting them may be because they can and do hold weapons on them, unlike a regular static object such as a wall or bush. I would assume that having those weapons around requires more work for OFP to handle, since it has to pop the actions into your menu whenever you get close to them, etc.

@ Foreach / do-while loops

I would assume that these both run much faster than a 'goto' loop. I would assume that the program thread reading the script stays entirely within the codestring used by both commands. Problem with these commands is that you cannot have any delays in them. Other than that they are great to use, except for the fact that you can't put stuff on multiple lines in a script! I hope they change that in the next game...

[Fragorl]

@ functions, interpreting and comments

Similarly to scripts and goto calls, it would make sense that a function's length is also very important in its speed of execution. And of course one of the biggest contributers to function length is in fact the comment. Going on what we have learnt here, whilst languages like C++ are precompiled, where comments themselves are totally left out of the resultant machine code and so have no effect on the speed at which the code is executed whatsoever (), the same is obviously not true of functions.

Some experimentation shows that neither preprocessFile nor loadfile remove the comments from the stringified function - surely, then, the parser spends valuable time searching, character by character, for the end of any comments it comes across, during the function call. Sounds as though comments are out then...

Btw, what did people think about starting a topic on the official forums to get these kind of questions answered in detail by the creators?

[Mikero]

>neither preprocessFile nor loadfile remove the comments from the stringified function

WOW!

>starting a topic on the official forums

would they really know?

There was a thread on bis about functions where Raptor (I think) made the comment that 'unfortunately' they don't have or use an internal compiler. From that point on, everthing about interpreting functions and scripts then made sense to me.

[General Barron]

neither preprocessFile nor loadfile remove the comments from the stringified function

I wonder what the difference between preprocessing and loading a file is then?

[Killswitch]

I wonder what the difference between preprocessing and loading a file is then?

Assuming we have this:

Code: [Select]

// func.sqf
comment { Some comment };
// Another comment
player globalChat "Hello world";and do a

Code: [Select]

func = preprocessFile "func.sqf"
hint format["%1",func]
...you will see that the comment {...} block is still there, but the "//-comments" are gone. Go figure... yet another "feature" of our beloved OFP ;D

[Fragorl]

Hm... don't know why, but whenever i've tried to use // comments, the dubugger spits out an error and tells me i've made a mistake...

[Mikero]

@fragorl

a common mistake is

a=1 // a comment

(needs a semicolon)