question for pros: wait / wait randomly

[Carl Sumner]

It's sort of "counter-intuitive". Adding Waits to loops makes the game appear to be faster. Using random Waits causes the game to run smoother.

Yes, Really.

Also note that some terms like Wait and Interrupt have a different meaning in the scripts that they do in other things, like the Windows or UNIX API. An Interrupt statement in a script has little to do with a hardware interrupt in Windows.

Think of the classic layer cake model. The Windows kernal handles hardware interrupts from the boards and schedules system tasks and applications. The X3 script scheduler and all of the scripts are probably only one Windows task. The script scheduler then, out of it's own windows timeslice, controls which script line will run now and which will be next.

The script scheduler cycles much slower than the Windows kernal and the script lines run much slower than compiled (XC) code.

The scripts also do not have a time limit to their "slices" of time, so a script that loops without a Wait will block other scripts from running when they need to.

When you see your game "jerk" and then continue, someone's script did not have a Wait in a loop.

Always put a (random) Wait in all script loops, unless you are totally certain that they can never run more than 2 or 3 iterations.

[Bunny]

I've had "@ wait 60000 ms" return early when it was used in a script that interrupts another one. That was a nasty surprise .

[euclid]

I've had "@ wait 60000 ms" return early when it was used in a script that interrupts another one. That was a nasty surprise .

Hm, that is strange. Is it possible that the 'other one' was called by some other script? This would lead to an early return of the first.

Cheers Euclid


Edit: I had to add this statement.E.

[Cycrow]

usually it returns after rather than before

so if you set 60000ms then it will will ignore checkes for 60 seconds then resume sometime after that

however, sometimes thery can resume before the wait finishes, and then it will return the time left.

so it could resume after 30000ms and it will return 30000 as the return value

[Gazz]

Just a little something I put in loops if I want to execute waits... but not with every pass.

Code: Select all

100 skip if not $Index == ( $Index / 15 ) * 15
101 @ = wait 1 ms

Through the virtues of integer math this executes 1 wait for every 15 passes.

[Logain Abler]

Cycrow, a quick question..

Tasks are stacked, so a example could be:
Task A has a 17 minute wait in while loop
Task B has a 3 minute wait in a while loop

If Task A is called and goes into wait, then Task B is called and goes into its wait.

As the tasks are stacked would Task A then be forced out of its wait prematurely?

I have some task that look to behave like this, I'm going to test based on your post and see what the wait is returning.

Hoping this will fix the issue:

Code: Select all

$wait = $pTime * 1000
$ret = wait $wait ms
  while $ret > 0
    $ret = wait $ret ms
  end
write to player logbook $ret

LA

Edit: The above capture worked a treat, now the wait will not end prematurely

[Gazz]

A wait instruction (*) can be interrupted and the script will immediately continue with the next instruction after that, prematurely ending something like a 60000ms wait.
Signals can do that as well as any other interrupt script or certain "events".

The minimum for any wait (*) is also the frame rate of X3.

Accurate timing in X3 is pure luck. Don't try.
Get used to a flexible view on time! Live Mañana!
If 120% of the desired time has passed, simply do 120% of the work!

And how many waits you need in a loop really depends on what you're doing. If the loop contains 3-4 simple instructions, it can run 100 iterations in "no time".
The number of waits of all currently active script also adds to the overhead of the game and the "ready" script queue gets longer.

As a rule of thumb, every scripter is told to "use more waits". It's generally the lesser evil.
They can always start to optimise things once they get a few scripts under their belt and no longer have to think about creating loops and juggling script tasks on an object. =)



(*) or any instruction with a timeout, such as attack run or movement (**)

(**) an interrupt that breaks a script out of the movement instruction does not necessarily stop the ship from continueing to execute the movement instruction (***)

(***) to really really stop a ship without bluntly resorting to set speed:
Interrupt task 0 (Prio 3456345) with: [THIS] -> follow [THIS], range 20000 m