When instance_exists() returns true, shouldn't this mean that the create event for that instance has been executed?

LEGOlars

Member
Hi,

Can someone explain why: When instance_exists() returns true, this doesn't mean that the create event for that instance has been executed?

Example:
if I have a room with the following creation order:
1. objHello
2. objBye

When I check instance_exists(objBye); in the create event for objHello, it returns true. But when I then try to read variables from objBye, it will throw a fatal error, because the create event only executes for objBye after the create event for objHello has finished executing. Is there any good reason why instance_exists shouldn't just return false in this case?

What I expect:
I expect the way that rooms spawn instances is consistent with how you would spawn it in code.
Similar to eg. using the creation code in the room editor to spawn the instances.
GML:
var lay_id = layer_get_id("Instances");

instance_create_layer(x,y,lay_id, objHello);

instance_create_layer(x,y,lay_id, objBye);
In this case, it would check whether objBye exists, but it has not been created yet. So it would return false.
 

Nocturne

Friendly Tyrant
Forum Staff
Admin
Rooms are not the same as code since you have already placed the instance in the room when the room is instanced, so the instance DOES it exist, but no events for it have yet been called. This is why you have the room creation order, so that you can see/set what order instances will run their create event in.
 

Nidoking

Member
While creation order is a great tool that I use pretty often, I've gotten into the habit of setting an alarm to 1 for any elements that need to wait until other elements have been initialized, especially when I'm creating them in code. That guarantees that by the time the time-sensitive initialization happens, all of the Create events that it depends on will have happened. I also declare all of my critical variables in the Object Variables list, just so that they're guaranteed to have a default value even before the Create event runs.
 

LEGOlars

Member
Rooms are not the same as code since you have already placed the instance in the room when the room is instanced, so the instance DOES it exist, but no events for it have yet been called. This is why you have the room creation order, so that you can see/set what order instances will run their create event in.
I understand how it happens. I just don't see a point in why it should work this way.

Yes, you can read the built-in variables like position & scale, but I don't think you lose any of that flexibility if your manage your creation order correctly? (which seems like good code practice anyway)
Meanwhile it invites for all sorts of bad code practices to be able to read -some- data from -partially created- instances, then run into trouble months later when you try to add something to the code. Maybe I'm just dumb but it took all my energy to figure out why this error suddenly started appearing after checking "instance_exists", because it never occured to me that the room editor invites this unique (but I think useless?) feature where the game is aware of an instance's existence before it is "created". There's no alternative like instance_is_created() to properly check it either.

If someone messes up their creation order, why not return false at instance_exists (the recommended method in the documentation to deal with these sorts of things) so it's easier to find the cause of the issue?
 
Last edited:

Nidoking

Member
You can create the functionality you're looking for by defining a "created" variable in the object, making it false in the Object Variables, then setting it true in the Create Event. Then you can check instance_exists and whatever_instance.created to get the effect you want.

The key phrase here to me is "If someone messes up their creation order". The answer to a problem is to solve the problem, not make something function in an unintuitive way to work around it in that flawed case.
 

TailBit

Member
In gms2 you can also set the variables in a different way in the object, by giving it a name, type and value.. (don't remember how to access it atm, typing from phone)

But those variables should be avalible earlier then the create event (unless I have gotten that wrong), and also gets inherited by child objects.
 

LEGOlars

Member
You can create the functionality you're looking for by defining a "created" variable in the object, making it false in the Object Variables, then setting it true in the Create Event. Then you can check instance_exists and whatever_instance.created to get the effect you want.

The key phrase here to me is "If someone messes up their creation order". The answer to a problem is to solve the problem, not make something function in an unintuitive way to work around it in that flawed case.
That's exactly what I was going for with this suggestion. Making it more intuitive. To not have seperated functionality for the different ways to implement the same instances & their variables. Your workaround is a really neat trick, but also a fantastic example of what's so unintuitive about the current system 😋 It requires you to initialyze variables in different places, in order to check if an instance has truly been created. Even looking at the terminology, what exactly is intuitive about an instance "existing" before it is "created"?
 

Nidoking

Member
Counterpoint: What's intuitive about instance_exists being false if I put the instance in the room and I can see that it's there? One of the important concepts from the very beginning of Game Maker (at least, as long as I've been using it) has always been "Don't rely on the same event being executed in a particular order between multiple instances." Creation Order is about the closest you get to being able to control that. If you've got one instance with a Create event which assumes that another instance's Create event has already executed, but you can't handle that with Creation Order for some reason, then it's as flawed a design as declaring a variable and assuming that it has a meaningful value without setting one. True, Game Maker doesn't have an "instance_initialized" function, but since you can write one yourself like I suggested, I can't imagine they'd make that a priority. In essence, I see Create events at game or room start as an edge case where maybe neither of us can be objectively correct. However, what the program does is quite clear, and short of filing a bug report asking for a new function to be added, I think you just need to accept that.
 

LEGOlars

Member
Counterpoint: What's intuitive about instance_exists being false if I put the instance in the room and I can see that it's there? One of the important concepts from the very beginning of Game Maker (at least, as long as I've been using it) has always been "Don't rely on the same event being executed in a particular order between multiple instances." Creation Order is about the closest you get to being able to control that. If you've got one instance with a Create event which assumes that another instance's Create event has already executed, but you can't handle that with Creation Order for some reason, then it's as flawed a design as declaring a variable and assuming that it has a meaningful value without setting one. True, Game Maker doesn't have an "instance_initialized" function, but since you can write one yourself like I suggested, I can't imagine they'd make that a priority. In essence, I see Create events at game or room start as an edge case where maybe neither of us can be objectively correct. However, what the program does is quite clear, and short of filing a bug report asking for a new function to be added, I think you just need to accept that.
Great. In your counterpoint, if instance_exists would've returned false when you can see it in your room editor, Gamemaker teaches you to think about the creation order. It shows you've made a mistake closer to the root of the problem, instead of showing it later when you try to grab a variable from that instance (which I imagine is the next step anyway, in most cases). It paves a clear path to understanding the inner workings of Gamemaker better.
By allowing you to jump into your instance before it has been created, Gamemaker is not removing your mistake with the creation order, it's delaying it. And by delaying it, it suddenly becomes difficult to find the root of the issue.

I don't want an "instance_initialized" function. I'd think that'd be equally confusing at this point. Although it would make more sense terminoligy-wise if they made a distinction between something "existing" and something being "initialyzed" rather than "created". Everything that exists has been created, but not everything has to be initialyzed.

So far I have no luck finding a good reason for instance_exist to return true before the instance has been created. And I have absolutely no problem accepting that. Maybe it even ends up being the price we have pay to take full advantage of the relatively new object variables. In that case a terminoligy change might be a consideration, but it's not up to me. I'm just doing my part posting a suggestion that I think can make GMS better. Cheers 😊
 
Top