• Hey Guest! Ever feel like entering a Game Jam, but the time limit is always too much pressure? We get it... You lead a hectic life and dedicating 3 whole days to make a game just doesn't work for you! So, why not enter the GMC SLOW JAM? Take your time! Kick back and make your game over 4 months! Interested? Then just click here!

GameMaker instance IDs?

Neptune

Member
Does anyone know how instance IDs are chosen?
Is there any influence by resource tree assets / object index?

Any info is appreciated :)
 

Simon Gust

Member
instance ids just start at 100000 and go up one each time a new instance is created.

if you have instances placed in your room editor you can open the instance creation order window.

EDIT: corrected myself.
 
Last edited:

Neptune

Member
Hmm just as long as its not connected to the resource tree, and the IDs that the room editor chooses remain unchanged by resources as well.
 

❤️×1

Member
Hmm just as long as its not connected to the resource tree, and the IDs that the room editor chooses remain unchanged by resources as well.
IDs are for instances, the resource tree is for objects; it's not the same.

More importantly, you should NEVER hard code an ID, it's a great idea to have everything break down the line. What are you trying to achieve? I'm sure we can help you do it the right way.
 

Simon Gust

Member
Hmm just as long as its not connected to the resource tree, and the IDs that the room editor chooses remain unchanged by resources as well.
I don't like where this is going. You shouldn't rely on instance order.

EDIT: I meant to say shouldn't rely on instance order but I goofed language.
 
Last edited:

TheouAegis

Member
The instance names assigned automatically in the room editor are randomly generated constants.

The instance id values assigned to those named constants, that is, the id assigned to an instance that is manually placed in the room, is first based on its order in the instance order list. Then it's based on the order it was placed in the room. Yeah, that's confusing. It's been hit-and-miss trying to get it to update instance id assignment based on instance order in the room editor. It seemed like all you had to do was close the room you were working on, but that only worked once for me. Sooo...

If you create an instance in the room, it's assigned a name and the id 100001. You then create another instance in the room, it's assigned a different name and the id 100002. If you go into the instance order and move the second instance up, it will be reassigned id 100001 and the first instance will get 100002. If you run the program, then go back and rearrange the instance order yet again, there's a chance it won't change ids at all.

In other words, don't rely on the ids in the room editor. lol ... yeah I'm confused.
 

Neptune

Member
Hmm thanks for replies.

Sometimes i want an instance permanently destroyed from a room, so id have the instance add its itself to a ds map... And then check whether or not it should exist upon creation.

That way works, but i dont like using the instance IDs either...

Any other ideas?
Itd be nice to be able to remove an instance from the room-creation stuff with code... instance_layer_remove or something.
 
Last edited:

NightFrost

Member
One way to uniquely identify instances between multiple visits to a room is to have them generate a unique identifier for themselves from room name and x and y position (and maybe layer name if you have lots of stuff going on). When an instance creates itself it can then easily look up from some global list whether it should immediately destroy itself. Best to check in room start event I guess, so it only runs once for stuff that has been placed in room editor, and later instance_creates don't accidentally get affected.

Edit: if you have just a few instances, you also could give them unqiue name variables in the room editor's room start code.
 

TsukaYuriko

☄️
Forum Staff
Moderator
Sometimes i want an instance permanently destroyed from a room, so id have the instance add its itself to a ds map... And then check whether or not it should exist upon creation.
Instance IDs are not guaranteed to persist between builds of the game, so relying on them in any way is equal to paving the way for an update that breaks save files.
 

TheouAegis

Member
And thus reading between the lines, if your game is in the final build, you can rely on the instance IDs generated by the room editor. But that's a hard final build in that you cannot make any changes in the room editor nor the resource tree ever again.
 

Neptune

Member
@TsukaYuriko @TheouAegis
This is why i posted, i was worried that was the case.

@NightFrost I think something like that may work for this case...

If that doesnt, i guess id have to add those objects into my save system just to keep track of when they should exist.

Im still open to any other ideas!
 

Pfap

Member
I'm not entirely sure what you are asking or trying to do, but I recently used a system to map to instance id's created at runtime.



Control object create event
Code:
var i, j, o, width, height,inst;
i = -48;
j = 0;
o = 0;
//width = 18;
//height = 11;

var identifyer = 10;
width = 11;
height = 9;

/*
if repeating height first we fill like so:
1 2 3 4 5
6 7 8 9 10
if repeating width first we fill like so:
1 6
2 7 
3 8
4 9
5 10
*/

repeat (height)
   {
   repeat (width)
      {
   
   inst = instance_create_depth(i,j,-2000,my_obj);
 
  
   inst.unique_id = identifyer;
  
   ds_map_add(global.inst_map,identifyer,inst);
  
  
   identifyer += 1;
  
  
  
   //inst.image_index = irandom(15);
  
  
      o += 1;
  
  
      i += 48;
  
      }
   i = -48;
   j += 48;
}

Any object that you would need a complete way to access an id that might change would be handled something like this:

Create event of my_obj
Code:
//this variable will be updated from the control object
unique_id = 0;
I start my identifyer variable at 10, so that each unique_id will consist of 2 digits if you need more than 10-99 maybe start it at 100.


The way this works is if you save the instances unique_id variable then you can look up what id Gamemaker assigned at runtime through the map.


Edit:
You would have to add code to load unique_id from save instead of setting it at runtime also.
 

Neptune

Member
@Pfap Hmm, but then if i made an update after release, adding something to the resource tree would offset the values of the mapping to different instances... I think?
 
Last edited:

Pfap

Member
@Pfap Hmm, but then if i made an update after release, adding something to the resource tree would offset the values of the mapping (because '3' would be mapped to 'o_tree' instead of 'o_enemy'...)
Maybe, but if you need the built in id to control specific instances you could just do and this is probably bad practice:

Code:
with(all){

if unique_id == value_you_set{


//do stuff for the single instance that has the value you need 


}


}


The value you set unique_id with will be the same no matter where you put it in the resource tree.
There has to be someway to manipulate things to get what you need.
 

Neptune

Member
I think i might just skip the horrors of the room editor, and spawn them in with code, and then just save them like anything else (this is possible for this type of object).

Honestly though, this problem needs a fix... The room editor is super handy, but perma-respawn aint cutting it!
 

TsukaYuriko

☄️
Forum Staff
Moderator
A simple approach could work like this:

Define a global indexed structure capable of holding data, such as a buffer. A list or array would work too.
Assign a descriptively named macro to every instance which needs to be tracked.
The macro values are a number sequence, starting at 0 and increasing by 1.
Each tracked instance now has access to one unique index (as long as you don't assign the same macro to two instances) of the global structure, which can be used to store just about any kind of value.
If you chose a buffer as your structure, you can now save it to a file with a single function call and load it back just as easily. Due to their iterable nature, lists or arrays can be saved to a file sequentially without the need to explicitly address each instance's stored value, too. (Care should be taken to make all values the same data type to avoid issues during saving and loading, such as mixing strings with reals.)
 

Neptune

Member
Alright, so maybe a 2 by X grid -- 1 column for the unique ID, and 1 column for the boolean (exist / not exist).
That should work... I don't like it, but it works.
 

TsukaYuriko

☄️
Forum Staff
Moderator
No column for the ID - the index is the ID. Otherwise the next thing you're looking for is how to address the right index.
 

TheouAegis

Member
If you created all the instances via instance_create(), you could just stick in the Create event: value=instance_number(object_index)-1; then the value would be the index in the data structure; but that only works when not using the room editor. Instances placed in the room editor are "created" immediately (even though none of their variables are initialized...go figure).
 
Top