Time delay function

[flarn2006]

Is there any function I can use to insert a time delay in the middle of my code? I mean something like this:

• Do something
• Wait 250 ms <-- THIS LINE
• Do something else

Not like an interval, where it will repeat the code every x ms. I just want something I can insert in the middle of my code that will wait before continuing execution. I can't count how many times I've wanted this but not found it.

[Wizard of Ass]

Have been requested several times before... always denied.

Use a timer instread.

[Zantier]

if(DoSomething)
{
    #do something
    DoSomething = 0
    timer("do something else",250)
}
elseif(clk("do something else"))
{
    #do something else
}

I'm pretty sure a "wait" type function will never be implemented, because it would involve rewriting so much of the wire system.

[Whodunnit]

just have a variable at the start of the expression "isdelaying"

and then just subtract from that each tick or millisecond.

if(isdelaying)
{
isdelaying = isdelaying - timeforonetick
}
else
{
executecode...
}

[Zantier]

if(isdelaying)
{
isdelaying = isdelaying - timeforonetick
}
else
{
executecode...
}

you should probably use if(Isdelaying>0), just in case it goes negative. It seems kinda wasteful compared to just using a timer though.

[moggie100]

So this doesn't appear to be one of those 'No! Go away!' threads without a reason for the decision, I'll attempt to explain.

E2 does not operate with any 'game time' between its instructions, as would be the case with the CPU (game ticks can occur between the start and end of ZASM). Instead, it builds your code into a tree structure, then on each @trigger event it applies the current state of the system (inputs, persists) to the tree, pumping out an answer in the same tick as it started in.

Thus, any functions which allow 'game time' to continue would need to be able to store the entire state of the E2 tree (like a process scheduler in an OS) with it partially evaluated, allow for x amount of time, then restore and resume the evaluation at some other time. Meanwhile, some other events may have come along and caused the E2 to evaluate -again- and so forth.

The result of this becomes a horribly tangled mess of stored states, some of which have relevant outcomes (nothing else has affected a variable, for example, so it would be the same no matter what else has happened) and some of which are pointless (the value of an output has been changed from what it would have been set when the E2 was first half-run).

Hence the timer/interval system currently in place, as this simply allows for delayed events to be pushed, causing the E2 to evaluate at some later time, but still within the "all in one tick" method described above.

(PS. @Syranide: If I've gotten anything wrong, please correct me!)

See also Why does ~ $ only work on variables? on another time-based problem with E2

[ktccd]

I knew a wait command must be horribly complicated, though I still think it's possible. only, someone would need to put a lot of work into it. And unfortunately, I know nothing of lua...

[Bull]

Such a delay would be very unpractical.

It stops your entire code, so when you have a applyforced plate, you can't use it because it will make it drop out of the air.

Timers are much more flexible. You can define which code you want to run and when.

[Syranide]

So this doesn't appear to be one of those 'No! Go away!' threads without a reason for the decision, I'll attempt to explain.

E2 does not operate with any 'game time' between its instructions, as would be the case with the CPU (game ticks can occur between the start and end of ZASM). Instead, it builds your code into a tree structure, then on each @trigger event it applies the current state of the system (inputs, persists) to the tree, pumping out an answer in the same tick as it started in.

Thus, any functions which allow 'game time' to continue would need to be able to store the entire state of the E2 tree (like a process scheduler in an OS) with it partially evaluated, allow for x amount of time, then restore and resume the evaluation at some other time. Meanwhile, some other events may have come along and caused the E2 to evaluate -again- and so forth.

The result of this becomes a horribly tangled mess of stored states, some of which have relevant outcomes (nothing else has affected a variable, for example, so it would be the same no matter what else has happened) and some of which are pointless (the value of an output has been changed from what it would have been set when the E2 was first half-run).

Hence the timer/interval system currently in place, as this simply allows for delayed events to be pushed, causing the E2 to evaluate at some later time, but still within the "all in one tick" method described above.

(PS. @Syranide: If I've gotten anything wrong, please correct me!)

See also Why does ~ $ only work on variables? on another time-based problem with E2

That seems like a valid and understandable explanation to me
And to those who perhaps don't fully understand that explanation, just trust us, as much as it sounds simple and easy, the side-effects are complex and ambigious. It simply isn't suitable for a language designed like E2.

It would perhaps be possible to improve upon this with user-defined functions though... aka, you could push a function to be delay-executed instead of a just causing a "generic" execution.