Ending A Looped Script

[Manifest]

I had this great idea about getting a CH-47D Chinook to pick up a tank (M60). I wrote a little sqs file with the following script:

#loop
tank setpos [(getpos chinook select 0), (getpos chinook select 1), (getpos chinook select 2)-10];
goto "loop";
<end of file>

I gave the chinook a few waypoints.. one of them being the tank.. there the chinook waits 20 seconds.. then it executes the sqs file.. and starts looping the script which places the tank 10 meters under the chinook...  so the pick up runs pretty smooth...  (it really looks great)

but now I want to make the chinook drop the tank off at some point....

does anybody know how to stop the script from looping? or stop the script entirely?

[Triggerhappy]

whenever you want it to stop, (say at a waypoint) you just need a global variable (call it dropoff)

so on the activation of the waypoint, put dropoff = true

then anywhere inside your loop put:
?dropoff:exit
ex:

Code: [Select]

#loop
tank setpos [(getpos chinook select 0), (getpos chinook select 1), (getpos chinook select 2)-10]
?dropoff:exit
goto "loop"
then when dropoff is true it will end the script and the tank will fall to the ground

[Manifest]

Wow thanks.. that really did the trick, but now I have another ploblem.

I want to make ammo drop from a plane with a parachute. I do this again with the setpos command, again in a loop. It keeps getting the position of the falling parachute... but when the chute hits the ground.. it dissapears and the ammo box with it..   Is it possible to check the box's hight to the ground (or gamelogic), and make the loop end when it is let's say a meter high?

[General Barron]

When the parachute touches the ground, it gets erased, so it will be a null object. Null objects are never equal to anything, including themselves (from the comm ref). So, when the parachute stops being equal to itself, you end the loop:

Code: [Select]

#loop
.....loop body
? _parachute == _parachute : goto "loop"

....parachute is now gone
blah blah
BTW, just as a little suggestion: I've found that ammo drops work well when you put a game logic in the parachute. That way, it doesn't fall straight down, it wiggles like someone is in it. Then just setpos the ammo crate to the game logic, and it will sway with the chute. Looks pretty nice, IMO.

[Unnamed]

Make sure you dont setpos the crate after the parachute has been removed:

So perhaps something like:

Code: [Select]

#Loop

@(True)

If !(IsNull _Parachute) Then {_Crate SetPos (GetPos _Parachute) : goto "Loop"}
A deleted object variable always returns a null position of x,y,z=[0,0,0], your crate was being spirited off to the far reaches of the map.

Oh, and the @(True) dealy, instead of the usual ~ command. Might give you a smoother animation when setpos'ing things on screen, if you get heavy lag? Try it and see.

[dmakatra]

Now to something completley different. ;D

What I've noticed in all of the suggested scripts in this thread are delays. Even scripting vets, shame on you!

A loop without delays will cause massive lag, just so you know.

:beat: *Gets Shot* :beat:

[Triggerhappy]

hey, i only took his script and added the line he asked for, as did everyone else  

[Unnamed]

What I've noticed in all of the suggested scripts in this thread are delays. Even scripting vets, shame on you!

A loop without delays will cause massive lag, just so you know.

The @(True) line gives you the smallest delay possible for the current framerate, at least thats how it appears.

[General Barron]

I read somewhere that the @  is the same delay as ~0.0001, I think. I'd never heard anything about it depending on the system.

[macguba]

I think that's about right.   There is a check in the game coding so that if loop is very fast it only goes through the loop a certain number of times (assuming nothing is actually happening) before moving on, doing something else and then coming back to the loop.    

I had a tricky setPos loop for an Outro and it turned out that


~0.001

was the critical time.  Any slower and it didn't work properly:  any faster and there was no improvement, not that improvement was necessary.     In other words I suspect that

@condition

is faster than or equal to

~0.001

and there is no point in ever having a delay shorter than

~0.001

That's only my experience (and as you know I am not
 an expert scripter) so that may not be the whole story.

It's only one order of mag different from GB's suggestion which makes me think the truth is there or thereabouts.    GB and I do cordially disagree occasionally, but when we do it usually turns out we're both wrong.    ;D

Don't ask me for references but my belief is that the above is generally supported by comments from Marek and/or Suma.

The fundamentally point, that a loop without delays is a VERY BAD THING is agreed on by everybody in my experience.

But we're getting off topic from the original secondary question, if you can have such a thing.   What's vital is, Manifest does your script work now?

[Unnamed]

@condition

is faster than or equal to

~0.001

and there is no point in ever having a delay shorter than

~0.001

That's only my experience (and as you know I am not
an expert scripter) so that may not be the whole story.

Thats pretty much it. When it comes to OFP, give me experience over expertise anytime

If you want to see OFP's timing in action try some of these:

Run this from an M1A1's init, and make a note of how many times _Count is incremented. It basicly counts how many times the @ command is called over 10 seconds.

Code: [Select]

_Count=0
_MyTime=_Time
@(Call {_Count=_Count+1 ; (_Time>=_MyTime+10)})
Player SideChat Format ["Time %1",_Count]
The more units you add on screen the smaller the number gets.

Or this to see how long it takes to execute the @ command 100 times

Code: [Select]

_Count=0
_MyTime=_Time
@(Call {_Count=_Count+1 ; (_Count==100)})
Player SideChat Format ["Time %1",(_Time-_MyTime)/100]
It certainly looks like the two are related, although it's still running from a script so I cant say for sure.

BTW you can test Triggers and waypoint conditions with the following as conditions:

Code: [Select]

Call {Player SideChat Format ["Time %1",Time]; False}
Not had chance to test config user actions, yet.

The @ command wins out for speed, but not by much. It's easy enough to setup ~ versions for comparison. There are other differences between @ and ~ that appear to be similar to the way functions differ from scripts. In that the @ will ensure the commands are executed for each frame, where as with scripts using ~ you cant say for sure. I have better results with some tasks running at OFP's 4 x speed, using @ rather than ~ delays. But I've only just started messing with this side of OFP, and there are lots of combinations.

This looks nice and neat, but as for being better, I dont know. You have to try them both and see.

Code: [Select]

@(Call {_Crate SetPos (GetPos _Parachute) ; !(IsNull _Parachute)})

[Manifest]

Wow, never thought my problems would have such an impact in the editing communty .. the problem is indeed solved by the way.. thanks a lot... the delay script was also a good idea

[Unnamed]

Wow, never thought my problems would have such an impact in the editing communty

Lol, don't worry The great loop debate comes around.... almost periodically

As long as you have a solution that works. When it comes to going around in circles, you're spoilt for choice with OFP.