It looks pretty good to me.
I can see that a
coroutine_running?(coro_name) method would be useful.
The main tricky part looks like that initial delay in
The way you are resetting things by keeping track of a running coroutine and aborting it if necessary may even be simpler, though an alternate methodology would be to add a
@time_dilation_remaining and have it count down to zero per frame or by some smallish time interval. Then you would know if
_wait_time_dilation_cycle() is running if
@time_dilation_remaining is not
0.0 or if
@actor_time_dilation is not
1.0. If it is running you would just adjust the values and the coroutine would adapt. However, what you are doing is perhaps the simplest thing.
You could use coroutine closures and modify the captured values or query data members in the objects that it is operating on to communicate with it. Specific coroutines, as you have done, are probably easier in this case.
You could also try racing it with an
@abort_dilation?._wait_true though that seems a bit much. I only mention it to get some alternative ideas flowing. [Note that
_wait_true() doesn't wake the instant a
Boolean changes - it waits a particular interval. It would also be a good idea for us to add an invoked coroutine equivalent or some mechanism that would instantaneously wake.]
In a future update we plan to make the omission of superclass constructors in subclass constructors a warning or an error or even call them automatically.