Preventing a script executing too fast.

[Prospero 1]

Hi all,

This is for you chaps who get excited about the issue of timing in OFP. I know I do, since it's so fundamental to the sort of stuff I like doing (upcoming ProSphere script included).

From my experiments, I suspect that if sufficient load is not being placed on your processor by OFP - and yes, this can happen, especially if you're just tinkering around with your scripts on the Desert Island - it can play hell with your timing / physics. Why?

Well, put this case: You have a script that uses a fast loop - and I'm talking about a fast loop, because, let's face it, invariably we'll be trying to do things as fast as possible. So, let's say that we therefore specify a very small delay like ~0.001 or even no delay whatsoever.

Now, if OFP hasn't got a lot to do at the time, it can be that OFP will run your loop several times registering no increase in the value returned by the Time function within that loop. This is a bit of a nightmare if you're performing a physics calculation based on a calculated time interval (which we'll call "dt") because, in such cases, your dt will be 0 (zero). This means that your dx/dt, dy/dt, dz/dt etc all suffer from divide by zero errors.

Now even it it were possible, I wouldn't want to stuff conditions in to prevent errors (very slow), and besides it's bloody ugly.

Ideas, chaps?

Prospero

[dinger 1]

dunno what exactly you're looking for prospero.

My understanding is that all those things that you can do in scripts, but not in functions, break up the code block executed by the parser.

~.0001 will work

@time > 0 is good

Goto "nextline"

#nextline

Or do you mean something like:

_hack = _time + .005

@_time > _hack

?

[Bart.Jan 0]

Can this be usefull ?

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

#start

~0.001

?_change==time:goto "start"

;your calculations

_change=time

goto "start"<span id='postcolor'>

or

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

#start

?_change==time:goto "aftercalc"

;calculation

#aftercalc

;something

_change=time

~0.0001

goto "start"<span id='postcolor'>

[Prospero 1]

</span><table border="0" align="center" width="95%" cellpadding="3" cellspacing="1"><tr><td>Quote (Bart.Jan @ Oct. 18 2002,17:13)</td></tr><tr><td id="QUOTE"></span><table border="0" align="center" width="95%" cellpadding="3" cellspacing="1"><tr><td>Code Sample </td></tr><tr><td id="CODE">

#start

~0.001

?_change==time:goto "start"

;your calculations

_change=time

goto "start"<span id='postcolor'><span id='postcolor'>

Bart's first example is what I currently use. I rationalize this by saying that although I am adding a condition, I am also removing one (by specifying no delay like ~0.001 - which is itself a condition). That's the way I rationalize it, anyway.

Dinger - I'm really not sure. But I do know for certain that simply inserting a Goto between two successive Time function calls isn't by itself sufficient to ensure that they will not produce identical times, and hence you cannot ensure that dt will not be zero.

Edit: Well, Bart's example isn't exactly what I use. I believe this is possibly slightly better (after extensive testing):

_ot = Time

#lp

_nt = Time

_dt = _nt - _ot

?(_dt == 0): goto "lp"

; Calculation here based on the timestep _dt.

_ot = _nt

goto "lp"

Further edit:

Heheh this has got a bug in it too, but at least it's not in the loop. The bug is that the first time _dt is calculated, it could be 0. But it's outside the loop, and won't ever be used as a divisor.

Prospero

[suma 8]

</span><table border="0" align="center" width="95%" cellpadding="3" cellspacing="1"><tr><td>Quote (Prospero @ Oct. 18 2002,18:27)</td></tr><tr><td id="QUOTE">_ot = Time

#lp

_nt = Time

_dt = _nt - _ot

?(_dt == 0): goto "lp"

; Calculation here based on the timestep _dt.

_ot = _nt

goto "lp"<span id='postcolor'>

Performance of such script would be terrible (zero-latency waiting loop). Adding single ~ command helps a lot:

_ot = Time

#lp

~0.0001

_nt = Time

_dt = _nt - _ot

?(_dt == 0): goto "lp"

; Calculation here based on the timestep _dt.

_ot = _nt

goto "lp"

[Prospero 1]

Many thanks Suma. That's what I will use from now:) It's so hard to know from an outsider's POV what one should do in this sort of case. Thanks for the response.

Prospero