Order of coroutine

Hi mad scientists
very very nice script here, loving it
i have a question regarding the coroutine execution order

say i have a coroutine called _speed_limit where i constantly clamp the object’s velocity to its max speed
and another coroutine called _accelerate, where i increase the object’s velocity,

how do i ensure that _speed_limit runs after accelerate runs?

1 Like

Thanks for the praise and welcome to our forum!

Do the _speed_limit and _accelerate coroutines both have the same update rate? For example do they both update once per frame?

I assume that as they are written that these coroutines essentially run forever - i.e. they keep on looping internally?

Option 1: ordered methods (recommended)

It seems to me that both _speed_limit() and _accelerate() could have their actions performed in methods speed_limit() and accelerate() rather than coroutines.

If this is the case, you can make an _update_speed() coroutine that orders the methods:

// _update_speed()
    // Wait one frame.
    // If you don't need to update this every frame it could be a
    // different interval such as every tenth of a second _wait(.1)

This is safe and gives you complete control over the order.

Option 2: initial call order

If the two routines must stay as coroutines and you cannot change their form to methods then you can rely on their update order. Coroutines are added to their update list (their Mind object) in the order that they are encountered in the code. So provided that it is guaranteed that the coroutines update at the same frequency (such as once a frame) then they should always update in the same sequence.

// Branch off each coroutine to run independently
branch _accelerate
branch _speed_limit

Or alternatively:

// Branch off the two coroutines running concurrently - essentially same as above

This should work though we have not guaranteed this order of how coroutines update. We certainly could guarantee it moving forward.

Option 3: order annotations (new tech)

Another mechanism (which does not currently exist though we could add it) would be to give an annotation to either the coroutines or the Mind class so that you could specify a desired order.

For example:

// _accelerate()

Then calls like this where the two coroutines are being updated by the same Mind would be guaranteed to occur in a particular order.

// Branch off each coroutine to run independently
branch _accelerate
branch _speed_limit

Or you could update these two methods in different Mind objects that you have given an annotation with a specific update order.

// In ClampMind/!Class.sk-meta
annotations: &after(UpdateMind)
branch change UpdateMind.instance _accelerate
branch change ClampMind.instance _speed_limit

If this seems more like what you need let us know and we can see about implementing it.

If you have any additional questions, just let us know.


This sounds like an excellent solution.

The idea of order annotations sounds like an interesting feature to me. Although i am shiny new to skookum, its concurrency is exactly what i have been looking for . . . so anything to make that more versatile.

Would either Option 1 or 2 work for you now?

Glad you appreciate SkookumScript’s concurrency features. We have a lot more cool stuff planned especially with visualizing complex concurrency with debugging.

Sure. I’m still getting to grips with it as its a bit of a logic shift from how i had been doing things. Option 1 and 2 are just as good and probably better coding practice, but i’m sure there will be use cases for option 3 if it is a future possibility.

I’m interested in using this for synchronous resolution in a multiplayer turn-based game, and this seems like the perfect match. So i’ll probably be in here asking lots of confused questions, but i really like the idea of this language.

1 Like

Option 1 solves this problem, but is not flexible to how you write code, I think one of the main strength of skookumscript is coroutine, Option 1 limits how you would write code,

Option 2 is great, such mechanism already exists, but I just didn’t know it was there

Option 3 is nice, but not “needed”, unless something that we cannot achieve with Option 2