Pages: [1]
  Print  
Author Topic: Help with GM's instance ID system  (Read 2761 times)
Offline (Unknown gender) luiscubal
Posted on: February 20, 2011, 05:13:38 PM
Member
Joined: Jun 2009
Posts: 452

View Profile Email
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.
Logged
Offline (Female) IsmAvatar
Reply #1 Posted on: February 20, 2011, 07:51:27 PM

LateralGM Developer
LGM Developer
Location: Pennsylvania/USA
Joined: Apr 2008
Posts: 891

View Profile Email
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.
Logged
Offline (Unknown gender) luiscubal
Reply #2 Posted on: February 20, 2011, 08:29:25 PM
Member
Joined: Jun 2009
Posts: 452

View Profile Email
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.
Logged
Offline (Female) IsmAvatar
Reply #3 Posted on: February 21, 2011, 12:58:21 AM

LateralGM Developer
LGM Developer
Location: Pennsylvania/USA
Joined: Apr 2008
Posts: 891

View Profile Email
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.
Logged
Offline (Unknown gender) luiscubal
Reply #4 Posted on: February 21, 2011, 06:29:11 AM
Member
Joined: Jun 2009
Posts: 452

View Profile Email
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)
Logged
Offline (Female) IsmAvatar
Reply #5 Posted on: February 21, 2011, 03:43:41 PM

LateralGM Developer
LGM Developer
Location: Pennsylvania/USA
Joined: Apr 2008
Posts: 891

View Profile Email
Interesting. I accept your theory, then.
Logged
Offline (Male) Rusky
Reply #6 Posted on: February 21, 2011, 09:03:48 PM

Resident Troll
Joined: Feb 2008
Posts: 961
MSN Messenger - rpjohnst@gmail.com
View Profile WWW Email
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.
Logged
Offline (Unknown gender) luiscubal
Reply #7 Posted on: February 22, 2011, 09:20:50 AM
Member
Joined: Jun 2009
Posts: 452

View Profile Email
@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.
Logged
Offline (Male) Rusky
Reply #8 Posted on: February 22, 2011, 11:44:09 AM

Resident Troll
Joined: Feb 2008
Posts: 961
MSN Messenger - rpjohnst@gmail.com
View Profile WWW Email
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.
Logged
Offline (Male) Josh @ Dreamland
Reply #9 Posted on: March 02, 2011, 09:29:54 PM

Prince of all Goldfish
Developer
Location: Ohio, United States
Joined: Feb 2008
Posts: 2953

View Profile Email
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
Offline (Unknown gender) freedom.limitless
Reply #10 Posted on: May 07, 2011, 11:06:51 AM

Member
Joined: May 2011
Posts: 12
Yahoo Instant Messenger - freedom.limitless
View Profile Email
Does enigma handle instance id?
Logged
Admit it, at some point in time you've tried to see if you have super powers.
Offline (Male) Josh @ Dreamland
Reply #11 Posted on: May 08, 2011, 11:15:26 AM

Prince of all Goldfish
Developer
Location: Ohio, United States
Joined: Feb 2008
Posts: 2953

View Profile Email
Yes.
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
Pages: [1]
  Print