GMS 2.3+ Objects not running in order of depth?

Kyrieru

Member
I am completely baffled at the moment.

I have two objects (camera, player), both running the following in the step event when I press a key. Each is on it's own instance layer with a fixed depth (0 or 100)
GML:
show_message(string(name))
show_message(string(depth))
Regardless of what order I put the layers of the room in (which changes depth), the camera always displays it's message first, even when it displays that it's depth is higher.
 

SoapSud39

Member
Step code doesn't run in order of depth. Depth only affects how images are drawn to the screen. If I'm not mistaken step code order is affected by instance creation order. (it might be something else too though, like object order on the asset tree)
 

Kyrieru

Member
Step code doesn't run in order of depth. Depth only affects how images are drawn to the screen. If I'm not mistaken step code order is affected by instance creation order. (it might be something else too though, like object order on the asset tree)
??? is this new in 2.3?
 

CMAllen

Member
Step event execution order among objects has always been a mixed bag, so you should never assume a specific order will be followed. You can 'mediate' some of this using the with() function, allowing one object to tell other objects what to do, but those other objects will still execute their own step events (before or after).
 

MaxLos

Member
There's an 'instance creation' order tab for rooms in both versions1.x and studio 2.3 and im pretty sure that affects what order step events are run in relation to other instances
 

Kyrieru

Member
There's an 'instance creation' order tab for rooms in both versions1.x and studio 2.3 and im pretty sure that affects what order step events are run in relation to other instances
Doesn't seem to.

It's fine, now that I know I need to treat step events differently. Maybe now I'll actually use step event and not just end step all the time.
 

Joe Ellis

Member
They always run in the order they were created, backwards, so the most recently created instance will be run first, the oldest last. It's been like this since 1.4 at least. Yeah and the room editor let's you choose the order, although it's backwards, so the first in the list will be executed last (each event it runs) It's pretty solid though, you can use it in quite a lot of useful ways, like having a main controller object that's created at the start of the game that's persistent, so you can be sure that it's end step event will be run after everything else, to do updating tasks and things
 

Kyrieru

Member
They always run in the order they were created, backwards, so the most recently created instance will be run first, the oldest last. It's been like this since 1.4 at least. Yeah and the room editor let's you choose the order, although it's backwards, so the first in the list will be executed last (each event it runs) It's pretty solid though, you can use it in quite a lot of useful ways, like having a main controller object that's created at the start of the game that's persistent, so you can be sure that it's end step event will be run after everything else, to do updating tasks and things
To clarify, the creation order in the room editor does not effect the step event. One object always ran first, regardless of order. I assume that it would only effect the create event.
 

Joe Ellis

Member
Hmm, the create events will be ran in the order they're created, but then all the other events run in the opposite order.
I haven't heard of the creation order in the room editor being wrong, maybe it's a bug in gms2.3.
I know that if you create instances during gameplay they still follow this rule cus I've been relying on this in my project and it works as expected, so it might be something that's changed with the creation order in the room editor. It's hard for me to say cus I've got my own level editor, I only have one room in my whole project with one instance (obj_engine) but that always runs last and instances created in code follow the order of newest first
 
Last edited:

TheouAegis

Member
Okay I will break it down. No idea how this runs in 2.3 because 2.3 is a total mess. But prior to 2.3, and I think I tested this in 2.2 before my license expired, step events are run by object index first, and then within each object index they are run by instance ID (I can't remember if it was fifo or lifo). That seemed to suggest to me that internally the program was keeping track of a list of instances under each object. So in GMS 1.4 and 2.2, objects towards the top of the resource tree would be processed first every step. And gm8, I'm pretty sure objects which were created first in the resource tree are handled first. And I would guess in 2.3 objects at the top of the yyp are handled first, but that's just a guess.

If you want to fiddle with it and try to work within that framework, you do you. But as of 2.3, I wouldn't trust any of GM's internal workings.
 

Joe Ellis

Member
Okay I will break it down. No idea how this runs in 2.3 because 2.3 is a total mess. But prior to 2.3, and I think I tested this in 2.2 before my license expired, step events are run by object index first, and then within each object index they are run by instance ID (I can't remember if it was fifo or lifo). That seemed to suggest to me that internally the program was keeping track of a list of instances under each object. So in GMS 1.4 and 2.2, objects towards the top of the resource tree would be processed first every step. And gm8, I'm pretty sure objects which were created first in the resource tree are handled first. And I would guess in 2.3 objects at the top of the yyp are handled first, but that's just a guess.
Really? That's completely different to what I've experienced the whole time. I'm not being rude but are you sure? (I guess you probably are)
I was certain that they all run in the order they were created. I've got several parts of my engine that rely on this and certain things I've coded specifically to do with what order their events are ran in.
 

TheouAegis

Member
Really? That's completely different to what I've experienced the whole time. I'm not being rude but are you sure? (I guess you probably are)
I was certain that they all run in the order they were created. I've got several parts of my engine that rely on this and certain things I've coded specifically to do with what order their events are ran in.
I don't remember. Maybe I'll be able to find the post I wrote about it. I just remember it surprised me.
 
Top