On Tue, May 25, 2010 at 01:24:30AM +1200, Ralph Versteegen wrote: > On 24 May 2010 23:59, Ralph Versteegen <[email protected]> wrote: > > On 10 April 2010 09:53, James Paige <[email protected]> wrote: > >> There is a PlotTimer.pause member, but I would consider a paused timer > >> to still be in use. > >> > >> ... but looking at the source, PlotTimer.speed = 0 seems to indicate an > >> unused timer, so I could just use that. > > > > Working on timers now. There is a slight problem. When a timer runs > > out, its speed is negated (marking it inactive, but also preserving > > the speed incase it is reactivated) and preserves all its other > > settings (aside from the length). > > > > For example, currently to restart a timer with all the old settings > > intact, "set timer (10, 100)" will suffice. I suppose you're in > > trouble if you use both "unused timer" and hardcoded timer ids anyway. > > Will just add some big warning notes, unless anyone has a better idea. > > You know, actually this sounds exactly like the task for a "new timer" > command, and garbage collecting run-out "new" timers (existing in a > separate pool) which are not > referenced. I could leave out the "unused timer" command for now, > as "allocate timers" is good enough?
I think I like the idea of a "new timer" command with garbage collection of timers that run out. For backcompat, the first 16 timer could never be garbage collected, so existing games that use hard coded timer numbers can "restart" them. Although really, I am cool with whatever you do here :) --- James _______________________________________________ Ohrrpgce mailing list [email protected] http://lists.motherhamster.org/listinfo.cgi/ohrrpgce-motherhamster.org
