ENIGMA Forums

Outsourcing saves money => Issues Help Desk => Topic started by: luiscubal on February 20, 2011, 05:13:38 PM

Title: Help with GM's instance ID system
Post by: luiscubal on February 20, 2011, 05:13:38 PM
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.
Title: Re: Help with GM's instance ID system
Post by: IsmAvatar on February 20, 2011, 07:51:27 PM
I'll brief you on the little stuff I know:

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 = 5
instance.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.
Title: Re: Help with GM's instance ID system
Post by: luiscubal on February 20, 2011, 08:29:25 PM
I've done some investigation myself and this is what I got:

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).

I believe this algorithm describes GM behavior.
Title: Re: Help with GM's instance ID system
Post by: IsmAvatar on February 21, 2011, 12:58:21 AM
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.
Title: Re: Help with GM's instance ID system
Post by: luiscubal on February 21, 2011, 06:29:11 AM
Experiment:
I have one object "foobar" with a KeyPress <Space> and a Draw event.
KeyPress <Space>:
Code: ( (Unknown Language)) [Select]
if (room != room_last)    room_goto_next();else    room_goto(room_first);
Draw
Code: ( (Unknown Language)) [Select]
draw_text(x, y, self.id);
Visible, non-persistent.

Create two rooms. Put one object "foobar" in each room. Run the game.

Results:
Room with instance 100001
Space Pressed
Room with instance 100002
Space pressed
Room with instance 100001 (the same ID as the first)
Title: Re: Help with GM's instance ID system
Post by: IsmAvatar on February 21, 2011, 03:43:41 PM
Interesting. I accept your theory, then.
Title: Re: Help with GM's instance ID system
Post by: Rusky on February 21, 2011, 09:03:48 PM
I think a much saner (and probably more realistic) description of instance IDs is this:


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.
Title: Re: Help with GM's instance ID system
Post by: luiscubal on February 22, 2011, 09:20:50 AM
@Rusky I don't think your description is accurate.

Quote
Persistent instances are kept in a global, persistent collection with each member initialized when its room is first initialized.
Certainly not true. Destroying a persistent instance and going back to the room where it was first created will recreate the instance.
Title: Re: Help with GM's instance ID system
Post by: Rusky on February 22, 2011, 11:44:09 AM
Quote
Persistent instances are kept in a global, persistent collection with each member initialized if it does not exist when its room is initialized.

Still no phantom destruction, checking for regular instances or ID re-use.
Title: Re: Help with GM's instance ID system
Post by: Josh @ Dreamland on March 02, 2011, 09:29:54 PM
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).
Title: Re: Help with GM's instance ID system
Post by: freedom.limitless on May 07, 2011, 11:06:51 AM
Does enigma handle instance id?
Title: Re: Help with GM's instance ID system
Post by: Josh @ Dreamland on May 08, 2011, 11:15:26 AM
Yes.