How do you set a timer's current time?

I'm attempting to implement basic save/load capabilities. I've got pretty much everything working, but my game includes a stopwatch-style (counts up) timer. I can serialize the currentTime on the timer to disk easily, but that property is read only. I can't identify any way to set a timer to a non-zero value in order to restore its state when loading the game. There's playdate.timer:reset() but there seems to be no way to simply set() the time on the clock. Am I'm missing something obvious?

I looked at the source for the timer implementation in the SDK CoreLibs directory, and I don't see a way to do this (and the implementation and comments imply that '.currentTime' wasn't originally read-only, but now very much explicitly is - I'm assuming for <reasons> - maybe someone from Panic will fill us in :slight_smile: ).

Thanks for looking into this. In the meantime I've managed to work around it by independently serializing the timer's currentTime and a separate timeOffset that I use to reflect the total time on the clock when loading the game. It's a little clunky, but it works.

1 Like

I didn't write the original implementation, but I'm guessing Dan had currentTime and timeLeft marked read-only because there's a lot of work properly validating the input value there--if you give it a value out of bounds, what should it do? But here's a quick and dirty patch. Instead of

      elseif key == "timeLeft" or key == "currentTime" then
              print("ERROR: playdate.timer."..key.." is read-only.")

I think

      elseif key == "currentTime" then
              table._currentTime = value
      elseif key == "timeLeft" then
              table._currentTime = table.duration - value

would do what you want (just don't go out of bounds). As I just mentioned on another thread, the nice thing about CoreLibs is you can tweak it as you need.

1 Like

Thanks, Dave, that’s very helpful. It’s obvious why timers are focused on countdown behaviors, although I’m curious about the absence of a basic upward counting timer in the API, especially given the presence of both Standard Timers and Delay Timers, which seem to take the same arguments and provide the same behavior. I would have expected the standard variety to function like a stopwatch. Setting the duration to a maximal value works, of course, so it’s not a big deal; just an observation.

Hey @dan, Eben's got a question about timers! :playdate_wink:

(I think that should send him a notification..)

1 Like

Hey sorry for the delay! I honestly can't remember why currentTime is read-only, other than it was probably easier to do it that way at the time.

As far as countdown vs upward counting timers, I never really considered the difference - default timers do indeed count upwards (but not to infinity, as a stopwatch would - is that the difference?). If you're just looking for a stopwatch a playdate.timer might be overkill compared to just recording a start time and computing elapsedTime = startTime - playdate.getCurrentTimeMilliseconds()? Or maybe it would make sense for us to add a simple playdate.stopwatch to CoreLibs? Just thinking out loud here :slight_smile: