I guess I understand how room/object/script IDs work. GM sets them at compile time, then adds some variable that contains the last ID and then "object_add"-like functions just increment that variable and use it as ID.

However, instance IDs are more problematic. Instances can be persistent, there are multiple rooms to be considered, etc.How are instance IDs handled? In particular: instances in different rooms, having a persistent instance and going back to the room where it was created, and interaction with instance_create.

GM is in general relatively well documented, but the GML language itself and these kinds of "small details" are not. Knowing this sort of thing would be helpful.

ID's start after some high number like 100000 so that they don't conflict with object IDs. This allows you to do things like:object.x = 5instance.x = 10

On game restart, all the instance IDs are bumped up, so that the lowest instance ID is higher than the highest instance ID of the last run. Because of this, it's bad practice to reference instance IDs directly, or to try to hang onto them after game restart.

I can't tell you about the behavior of persistence, but it's very easy to inspect and find out for someone who has a copy of Game Maker installed.

1. When moving back to a room with a persistent object, the instance still retains the same ID and no other object is created.2. When returning to previously visited rooms, the remaining instances too retain their IDs.3. Only instance_destroy calls the Destroy event. Moving scenes does not call this event.4. However, when returning to previously visited scenes, non-persistent instances do receive a Create event.5. When instances from a room are destroyed and then the room is revisited, all destroyed instances are recreated(both persistent and non-persistent).6. All properties attached to an instance are destroyed when the instance itself is destroyed. Revisiting a scene (and thus having the instance back again) does not use the previous variables.

Based on this, I have a theory about instance behavior.

1. Instances are created in a room with a given ID.2. When an instance is created, GM checks if another(possibly persistent) instance already exists in the room. If another instance with the same ID already exists, the instance is not created.3. When a room is left, all non-persistent instances are destroyed(although the event itself is not called).

Unless you're using a non-standard definition of ID, I do not believe your theory holds.Create a room with a non-persistent instance. Record the instance ID. Leave the room for another room, and return. Record the new instance ID. If the two IDs do not match, your theory is disproved.

I think a much saner (and probably more realistic) description of instance IDs is this:

GM keeps a global instance ID counter. Each instance placed in any room or created at runtime gets the next higher ID.

Persistent instances are kept in a global, persistent collection with each member initialized when its room is first initialized.

Non-persistent instances are kept in room-specific collections which are initialized each time a room is initialized.

This accounts for "phantom" destruction of instances when you leave a room, "checking" for non-destroyed instances when re-entering a room and the "re-use" of IDs when a room is re-entered, all of which sound like centrifugal force- they only exist in specific reference frames. Statically placed instances are simply created with their statically assigned ID either on room initialization or, with persistent instances, on first initialization. The fact that destructors are not called on room change is, from this reference frame, an omission, not some extra call to the create event later on.

Luis, your points are all correct. Rusky, your first point is correct. GM does not distinguish persistent instances from regular ones except in room start/end, during the former of which a check is done for an instance of that ID (exclusively for persistent instances) and during the latter of which persistent instances are not destroyed. I'll grant that it's possible, but unlikely, that Mark keeps a separate list of persistent instances, but a check for an existing ID is a likely O(1) operation and eliminates the need for a second container.

But yes, a counter is kept, and IDs are never re-used (except, of course, with instances placed in the room editor).

Logged

"That is the single most cryptic piece of code I have ever seen." -Master PobbleWobble"I disapprove of what you say, but I will defend to the death your right to say it." -Evelyn Beatrice Hall, Friends of Voltaire

"That is the single most cryptic piece of code I have ever seen." -Master PobbleWobble"I disapprove of what you say, but I will defend to the death your right to say it." -Evelyn Beatrice Hall, Friends of Voltaire