Modify behavior of runtime to improve usability of 'wait' timers

[bitflung]

Through trial and error I've discovered that 'wait' timer behavior depends upon how you structure your code.

For lots of details, see:

How many wait timers can we use?

I recently whipped up an example for someone, showing how to make stars animate in the sky. it was a quick and dirty hack on my part, and initially i liked the idea that i would spin off a dozen or so wait timers... the idea was pretty straight forward: spawn "passive stars" for every tile of the night sky; they are just a single black frame once every few seconds emit an "animateStars" event that "passive stars" handle use random to setup a stochastic process to transition something like 1% …

In short: if we write handler which sets up a duration variable (lets call it 'dur') then starts a 'wait' timer with that variable, it works just fine... so long as the handler is only called once per game.loop iteration. If the handler is called multiple times then apparently all 'wait' timers are created, but all of their duration will be set to whatever value was held by 'dur' at the end of the game.loop iteration.

I'd like to see the runtime updated to copy the duration variable into the 'wait' timer when we start a time, therefore enabling us to spawn multiple 'wait' timers in the same game.loop iteration regardless of the named variable we use to calculate/hold the duration for each timer.

1. Describe your reason for requesting this feature. What problems are you running into?
   I'd like to write a single handler for setting up and calling on 'wait' timers; for this handler to be mimic'd by a plurality of tiles and executed by any number of those tiles while handling a single initiating event (e.g. game.loop).

2. How would this request improve your experience with using Pulp?
   I would be able to write cleaner and more functional code while modeling constrained-randomized behavior of various tiles. e.g. I could have a night sky with random stars twinkling for random periods of time. (see the link provided at top for example)

3. Include any other details you have relating to this request.
   This issue is due in large part to the lack of variable scope. I suspect it would be more difficult to implement scope than it would be to adjust the behavior of timers though.

[shaun (Shaun Inman)]

Good find. Creating the wait timer is deferred until the end of the frame. Parsing its duration argument, assumed to be a number literal, was also deferred. Duration is now parsed when wait is called, not when its timer is created at the end of the frame. Fix will be in the next release.