Description: Official subforum for LunaLua - an extension framework for SMBX Engine Version 1.3 (which a core of SMBX 2.0). Share your creations that require the use of LunaLUA. You may also share info/tutorials on how to use LunaLUA.Moderators:Moderators, Semi-moderatos

Timers are counting down when the player is growing or shrinking. This causes problems with event scheduling, particularly with moving layers, because all layer movement stops while this is happening, and then the layers change speeds at the wrong time. There needs to be something like what happens with SMBX events. When layers stop moving because the player is changing size, the event timers freeze as well.

You may want to look into the "pauseTimer" and "resumeTimer" functions of eventu. I've done exactly this a few times before. The simple way to do it is store the eventu timer in a variable, then each tick, check the player's current state. There's a single memory offset that is used for animation states such as powering up, going through doors, etc., so I check if that is one of the states in which layers can move, and call "resumeTimer" then (resuming a running timer will do nothing, so that's okay), and otherwise call "pauseTimer", which stops the timer from counting down until it is resumed (similarly, pausing an already paused timer won't do anything either, so that's also fine to do).

Hmm. So, the waitFrames and waitSeconds functions are basically useless, then? That's what I'm using.What there needs to be is a built-in function, running every loop, that checks that state, then pauses all timers if layer movement is disabled, and resumes them once it is enabled again. Of course, that might break any functions that DON'T move layers.

Is there a way to do this with the waitSeconds and waitFrames functions? Doing what you suggested would require all my coroutines to be broken into smaller pieces, one for each delayed trigger. That, and I would have to create several timers as well.

Added after 7 minutes 44 seconds:Another problem that I noticed is that the "signal" function will throw an error if it sends a signal that a coroutine isn't currently waiting for. This can be fixed using a variable for if something is waiting for the signal, but it would make much more sense to just integrate a fix into the API, since it is always needed when using the signal function anyway.

Added after 12 days 21 hours:Ok, Hoeloe, I hope you don't mind. I'm going to attempt to make a small modification to this API to stop countdowns while the player is growing or shrinking. I think I know how. This modified version will only be for my personal use, and I won't distribute it or anything (except with my episode, on the newer releases, with your name still on it, of course). If this will be a problem, let me know, but it shouldn't hurt anything.