GMS 2 Instance Deactivation and Depth

Binsk

Member
Howdy,

Alright, so I've always avoided instance deactivation and generally handled the 'deactivation' bit myself. However I am designing an extension that requires I "pause" objects regardless of how the user of the extension has programmed them. Because of this I am trying to use deactivation but am coming across weird depth sorting issues when I reactivate them.

For the sake of my demo I have two objects:
1) [gradient] -> draws a colored gradient over the room
2) [circle] -> draws a white circle inside the room

When I deactivate I loop through the active objects via with(all), deactivate them, then store their ids in a queue. When I need to activate them again I go through the queue and do so one by one. This method is used to prevent activating objects the user may have deactivated themselves at some other point.

The issue is this:
If I added gradient to the room last, everything works fine. If I added circle to the room last, it is always behind gradient upon reactivation. They are on the same layer inside the room editor with the circle always coming second, thus rendering correctly if I don't use deactivation.

Changing the order of activation (from queue to stack) does nothing and the only way I can seem to get this to work right is by placing each on their own layer via depth=, which I obviously can't do in this case.

Has anyone come across this issue and if so, how did you go about solving it?

EDIT:
I switched to just using instance_deactivate/activate_all for testing and it still has the issue so I suppose it has nothing to do with manually deactivating one-by-one. Not really sure how to solve this at this point, I'm still brainstorming.
 
Last edited:

Yal

šŸ§ *penguin noises*
GMC Elder
Have you tried giving the gradient a lower depth? Instances of the same depth (or on the same layer) are not depth sorted in any particular order, and the unpredictable order they do get put in isn't even guaranteed to stay the same between steps. So things like this will just kinda... happen unless the instances are explicitly on different depth.
 

Binsk

Member
@Yal , When testing I did and that fixed it. The problem is that since this is an extension I can't guarantee that the person using the extension will have explicit depths. Because of this I was hoping there was some other way to revert the render order, even if a bit hacky. I always assumed that, when on the same layer, instance creation order determined render order but that doesn't seem to be the case.

If there is no reliable way to resort objects then I suppose I'll have to implement some manual sorting settings that the user can choose from. That is unfortunate.

Thank you for the help.
 
I'm not sure on this, but it's worth a shot. You say your deactivating everything at once, and then reactivating one at a time right? You should debug your reactivation order and see if that changes the order in which they are placed. You may need to do something where you deactivate things in order, and then reactivate them in reverse order... if that makes sense.
 

Binsk

Member
@robproctor83 , Thank you for the idea. I gave this a go, both in reversing reactivation and in reversing deactivation order, and it doesn't make a difference oddly enough. I also tried using the built-in deactivate_all and activate_all functions and even these cause this issue.
 
Well, your issue with setting depth is that your concerned the user may not have a depth set? Well, you could just set the depth for them then, no? When you loop to disable, just check if there is a depth, and if not add one. More than likely they will have non depth defined objects in the order they are created, so I would think it's safe to assume if you loop by ID you would be able to generally define draw order for objects that don't have a custom depth... If the user is relying on the specific order of non depth defined objects then chances are those objects are not in situations that would be an issue for you. I'm making assumptions here, but I can't see why that wouldn't work.
 

Binsk

Member
That is what I am going to have to do. It does break some of the seamlessness, however, simply because it can cause differences that the user doesn't expect and doesn't understand why.

Anyway, thank you everyone for the help. It looks like there is no perfect way of doing this so I will make do with a couple hacks.
 

Yal

šŸ§ *penguin noises*
GMC Elder
You could always just add it to a "known issues" list when releasing the asset, and then suggest that the user explicitly gives objects different depths if their draw order matters? If the user don't have any draw order dependencies and your asset starts reordering instances behind their back, it could lead to other types of issues (like the game slowing down because of hundreds of temporary layers being created)... so no matter what you do, it could lead to some sort of issues for the user. Better to inform them so that they can pick whichever option suits their use-case the best.
 
Top