On 25 May 2010 03:43, James Paige <[email protected]> wrote: > 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
I'm not totally convinced though; introducing two types of timers introduces its own complexity. I already wrote unusedtimer, so I'll leave it in, uncommented, in case. _______________________________________________ Ohrrpgce mailing list [email protected] http://lists.motherhamster.org/listinfo.cgi/ohrrpgce-motherhamster.org
