Skip to main content

Indie game storeFree gamesFun gamesHorror games
Game developmentAssetsComics
SalesBundles
Jobs
TagsGame Engines
(2 edits) (+2)

I took on the (admittedly simple) challenge of emitting an event when the .beat internet time changes. I only discovered Decker today, so suggestions are welcome if I've misunderstood concepts or am using things wrong (i'm pretty sure preserving state between `view` events is not supposed to be done via an off-canvas textbox, but i wanted to avoid emitting an event more than once for the same timestamp), but here's an event-emitting .beat time box:


I've updated it to include a template for the beat_tick event, and  optimised things a little  by not doing any string formatting at all if the time hasn't changed  (reducing how much stuff happens at 60Hz), eliminating the parse call for sys.now (thanks for answering my modulo question over on cohost!)  and inlining the calculation in the format call. This results in a 0.06% reduction on the profiler.

%%WGT0{"w":[{"name":".beat1","type":"contraption","size":[88,28],"pos":[5,20],"def":".beat","widgets":{"t":{"value":"@632.49"},"utc_ts":{"value":"1695305447"},"beat_ts":{"value":"632.49"}}}],"d":{".beat":{"name":".beat","size":[88,28],"margin":[0,0,0,0],"description":"display the .beat time, also known as Swatch Internet Time.","script":"on get_ts do\n beat_ts.text\nend","template":"on beat_tick time do\n\nend","image":"%%IMG2AFgAHAACAVQAAwECIFIBAgABAQIgAQFSIAEBAyABAVQgAQECIAEBVCABAQIgAQFUIAEBAiABAVQgAQECIAEBBSACAU0gAQECIAEBBSACAU0gAQECIAEBBSACAU0gAQECIAEBBSACARQgAgE3IAEBAiABAQUgAgEUIAIBNyABAQIgAQEFIAUBAyAEAQMgAwEBIAEBASAEATYgAQECIAEBBSAGAQEgBgEBIAYBASAEATYgAQECIAEBBSACAQIgAgEBIAIBAiACAQEgAgECIAIBAiACATcgAQECIAEBBSACAQIgAgEBIAIBAiACAQEgAgECIAIBAiACATcgAQECIAEBBSACAQIgAgEBIAYBASACAQIgAgECIAIBNyABAQIgAQEFIAIBAiACAQEgAgEFIAIBAiACAQIgAgE3IAEBAiABAQUgBgEBIAYBASAGAQIgAgE3IAEBAiABAQMgAQEBIAUBAyAEAQMgAwEBIAEBAyACATYgAQECIAEBVCABAQIgAQFUIAEBAiABAVQgAQECIAEBVCABAQIgAQFUIAEBAyABAVIgAQECAAEBAiBSAQIAAwFUAAI=","attributes":{"name":[],"label":[],"type":[]},"widgets":{"t":{"type":"field","size":[54,15],"pos":[32,8],"locked":1,"animated":1,"script":"on view do\n if !(utc_ts.text~sys.now)\n  utc_ts.text:sys.now\n  d:\"%04.02f\" format ((1/86.4)*(86400%(sys.now+3600)))\n  card.event[\"beat_tick\" d]\n  beat_ts.text:d\n  me.text:\"@%s\" format beat_ts.text\n end\nend","font":"mono","show":"invert","border":0,"style":"plain","align":"right","value":"@632.44"},"utc_ts":{"type":"field","size":[47,14],"pos":[109,14],"show":"none","border":0,"value":"1695305443"},"beat_ts":{"type":"field","size":[47,13],"pos":[109,1],"show":"none","border":0,"value":"632.44"}}}}}
(+1)

Nicely done!

It may seem a bit odd, but using hidden widgets is in fact the normal way to preserve state across events. Storing state in widgets means that it can always be viewed and inspected, and saving/reloading decks has straightforward, unsurprising semantics. It may be a good idea to mark such "internal" widgets in a contraption (or a deck itself) as "Show None".

Another refinement you could make is supplying a Template Script (under Prototype -> Properties...) with an empty "on beat_tick ... end" event handler; this helps make contraptions more self-documenting by indicating the events that are available and saving users typing, just like the templates Decker supplies automatically for the primitive widgets.

(+1)

Thanks for the hints - I’ve added the template script and such, and updated my post. I found that the time calculation itself could be optimised, since the call to parse "%e" sys.now and the math that followed was taking a timestamp, turning it into an object, then turning it back into a timestamp again (but where the start of the epoch is midnight of the current day, BMT), and it could be shortened to just (1/86.4) * (86400 % (sys.now + 3600)). Matters very, very little when the speed of the Lil interpreter is limited within Decker, but it feels better to me.