Talk:goto

Ok......lets get this clear.

I have always thought that a loop, in most cases, MUST have a delay of some sort, otherwise the loop loops so fast that you cannot interrupt it and end up having to reboot or quit the game.

Lets have the nitty gritty here.

Also, are Label names case sensitive or not, give reasons , evidence.........etc.

Planck

---

raedor: From what I know they're not case sensitive, I've been using them for years without problems. About the delay: it is correct that you should have delays in your loops, especially "infinite" loops (eg with alive x as condition), as slower computers will CTD without that delay. Also you should think about the length of the delay if you're addon-scripting, because you have to face the fact that your scripts might run 20 times at once. I think it's an interesting fact here, that @ and triggers check with .5 delays.

Delay in a loop

While it is not required to include delay in a loop, loop without a delay can cause the script to slow down the game a lot, as the loop will be executed many times before game engine interruprts the script.

Unless you really want the loop to execute multiple times during a frame, you should include a small delay.

--Suma 12:19, 23 May 2006 (CEST)

---

Thanks for that Suma, I was always under the impression that at least a small delay was advisable, even if only 0.001.

Planck 17:11, 23 May 2006 (CEST)

---

Well, .001 is still a bit short as it means 1000 checks per second and this again is 20 checks per frame (if you have 50 FPS... I play on about 20 FPS usually). Everything > 1 check per frame is useless, as you'll see the effect on the next frame at the earliest. You can say a maximum of 70 checks per second (I doubt that anyone plays with 70 FPS... anyway) is okay, so that a minimum of .014 as delay should be clear.

Raedor 17:25, 23 May 2006 (CEST)

---

First time here - I hope this is going in the correct place. The point I am making is that loops that look like:

#loop
lots
of
useful
stuff
if (condition) then {goto"loop"}

do not need to have a delay, it is just like a long list of repeated instructions.

I could understand that a loop that looks like:

#wait
if (condition) then {goto"wait"}

Could well cause problems without a small delay. But then unless they really know what they are doing they should use an @ instruction which by my testing runs much smoother. But to say that all loops need a delay is to seriously confuse the punters.

If people are okay with it I will edit the entry tomorrow when I get chance and then let's see if we are in agreement - I can shift all that stuff I put in about forEach as well that is really irrelevant here.

Does that make sense? Have I understood the disconnect?

Evidence

Not knowing about this place until Planck tipped me off I was not aware that the question about evidence for case sensitivity of labels had been asked. Is the script I posted sufficient evidence that labels are not case sensistive?

Would it be better if I moved that script here rather than leave it where it is. I am happy either way.

The previous two messages

Are from me THobosn. I had thought that this would have been automatically recorded.

Just found the signature button. --THobson 00:13, 24 May 2006 (CEST)

---

Ok thanks for everyones input.

I think we have established that labels are indeed NOT case sensitive.

As for the delay thing I think it must be stressed that when I said, 'in most cases', I should have said 'in many cases'.

There must be, as TH has pointed out, many instances where a delay is not needed.

As for the 0.001, that should have read 0.01, what can I say, I washed my keyboard recently and I can't do a thing with it.......NO honestly.  ;)

Planck 00:27, 24 May 2006 (CEST)

From what I know OFP interprets 100 lines of a script (if not interrupted by @, ~ or exit) before switching to the next job... even if there's lots of useful stuff in the loop, OFP will run through it over and over again, I don't see for what you could need that. Well you better just don't use labels and goTos anyway, forEach and while do a way better job  ;) But okay, we can write it as you said, Planck.

Raedor 00:33, 24 May 2006 (CEST)

For the record:

Evidence that labels are not case sesitive:

goto "SKIP"
hint "Labels are case sensitive"
exit
#skip
hint "Labels are not case sensitive"
exit

Retrieved from "http://community.bistudio.com/wiki/goto" --THobson 08:42, 24 May 2006 (CEST)

My recent Edit

Does this do it for everyone? I have experimented with 5,000 wait loops vs 5,000 @ instructions and for the condition I was using a 0.5 second delay cause the wait loop to perform very poorly compared with the @ instruction. But of course for a more complicated conditon than the one I was using it could be the other way around.

Two comment of the text as it now stands:

1. I cannot veryfy the statement that a wait loop will cause the ofp engine to be delayed - I am taking you guys on trust on this

1. I have made a link to @. But there is no @ in the comref to link to. I am really up against it the moment so I can't write it, does anyone else have the energy to have a go at it?

--THobson 08:55, 24 May 2006 (CEST)

---

I once did some testing to find out whether and when it is better to use @ instead of goto-loops and vice versa. I will just quote my post from OFPEC here:

For that I used a simple boolean as condition, and two different scripts to check. One checked the condition using @COND, the other one with a loop with 0.5 seconds delay and an if statemtent (?!COND : goto ...).

Each test run first started the tested script 5000 times in a while loop (to have them all start at once), waited a random number and changed the condition. I measured the time it took to recognise the condition for each single script and took the average of it. And to make even more sure, I did this 3 times and took the average of the 3 average values.

Here are my test results:

using loops with a delay of 0.5 seconds

• fps
Normal (Desert Island): 54
Script startup: > 16
Scripts running: ~42

• activation time
The average time for the 0.5 sec. loop to recognise the changed condition was 0.212, i.e. approximately the half.

using loops with a delay of 0.25 seconds

• fps
Normal (Desert Island): 54
Script startup: > 16
Scripts running: ~27

• activation time
The average time for the 0.25 sec. loop to recognise the changed condition was 0.091

using loops with a delay of 0.1 seconds

• fps
Normal (Desert Island): 54
Script startup: > 16
Scripts running: ~6

• activation time
The average time for the 0.1 sec. loop to recognise the changed condition was 0

using @

• fps
Normal (Desert Island): 54
Script startup: > 16
Scripts running: ~7

• activation time
The average time for the @ command to recognise the changed condition was exactly 0.

Conclusion:

'@' is equal to a loop with a delay of 0.1 seconds. They both eat a lot of performance, but are the absolutely fastest to get activated. So if something needs to be very precise, the best way is to use @. Avoid it in scripts running parallelly though.

Everything else is better put into loops of delays of 0.25 seconds or bigger (every tenth second more means increase of performance), even if it's the simplest condition, if you run the script over a long time or multiple of the same script parallelly. In the latter case it would even be good to randomise the delay first, keeping a certain minimum.

e.g.:
;;; ~ 0.6
_r = 0.5 + (random 0.2)
~_r

Avoid writing ~(random 0.6), as this may have the effect, that random 0.6 is calculated every frame. I am not sure about this though.

--hardrock 13:56, 24 May 2006 (CEST)