thanks so much!!! also my friend figured out a workaround using Some Kind of Wizardry but it had to do with how I was implementing jankytunes? I want to both have looping bg animations And on-click animations. I think the workaround? was to use millies play across cards thing but to fix a few bugs I had in my implementation.
that makes sense about sleep!!
ty for ur support, I hope to share this game at the end of the month for the decker jam!
Hi, just want to check what the issue with jankytunes was here - was it just that it paused when the script was in "sleep" mode or was it something else?
There are some tricks you can do, like writing a little loop in the code where, instead of sleeping for 60 frames, it calls the animation bits and then sleeps for 1 frame, 60 times. I think in lil you'd use like an "each x in range 60" thing to do this? But you'll probably want to read the lil doco for more details.
It sounds like you got it sorted out though?
To de-mystify a little, when Dialogizer is displaying a dd.say[] modal, it's doing something similar to the following:
while !pointer.down blink_cursor[] deck.card.event["animate"] sleep[1] end
The "animate" event which is being sent to the current card provides the opportunity to make other things happen while the dialog box is idling and waiting for user input. Puppeteer uses this hook to animate puppets, and it can be used to give other modules and contraptions a chance to do their thing as well.
Any "blocking" scripts you write yourself can use a similar approach; a synchronous animation script becomes responsible for explicitly routing the events to everything that needs to do work on every frame, whereas an asynchronous script allows Decker to handle some of that plumbing automatically.
