change instance`s object index


is it good practice to use this function? instance_change(); one of the things that worry me are the facts its not accesable after you run this function and if you try to acceess it it wuld return an error, which is what the manual says.
If you decide to change instance, it's because you no longer need the instance from which it was changed. It's a way of dumping an object for another one. Basically, it's a destroy the current instance and create another object at it's position. So yes, it's a good practice to do this if what you want to do is have another object at the current instances position.

The question you are asking is a bit weird because we have no context. Why would you want to change instance? If we have a context and a reason why you want to do it, we'll be able to say if it's the right function for what you need.

If you only want to change the image of the object, you would simply change the sprite_index to something else.

A few other things:
• if you change instance, the code after that line won't happen and never execute because you object does not exist anymore.
• object_index is usually used to get the handle of an object to change values of that object or do other actions AS this object
For example:
iii = other.object_index;

// 2 things....
// The with statement
with iii {
  // Whatever things you want
  // to change in that other object

// or simply accessing or setting a variable
iii.x += 16;
So again, Yes instance_change IS a good practice if your goal is to destroy the current object and create a different object at this exact location.

Hope this answers a bit because I find the question a bit confusing, or at least, lacks some details.


Forum Staff
That doesn't only change an instance's object_index, but also potentially executes its Create/Destroy/Cleanup events and lets variables from one object spill over into the other.

If used properly and with necessary caution, no problems should arise from using it.

Personally, I'm not a huge fan of it as it entirely flips the scope of anything I use it in to the point where it makes it do a 360 underwater while breakdancing. Errors are what concerns me the least here. I'd be more worried about the organizational nightmare I'd get myself into when changing back and forth between different objects once they reach a certain level of complexity.

The more important question here is what you're trying to use this for.


i am trying to switch teams. and becouse there are alot of instances that are in teams id like to narrow down the if nests, also to avoid using functions like instnace_place_list, sorry but when meny projectiles collide and we check for collisions and such, and create lists in the midst of the action, that will destroy performance. so every team having its own parent object is best solution since ill directly check for that specific instance, and makes instance_place usable, if we use instance_place, and have tteams as variables, it will take the wrong ID alot of the time, and will messup mechanics, and changing mechanics becopuse of a bad practice is a bad practice in itself.

anyway, does instance_change really also transfer variables over?


Forum Staff
You might want to use a quadtree collision system to optimize this. This will let you check for collisions only in certain regions of the room, against instances which are also located in that section of the room, entirely excluding anything that's too far away from it to even have a chance of colliding with it from the actual collision checks. That removes multitudes of more iterations and has vastly improved scalability over the system you're currently using, to the point that having to tell apart what's on what team will no longer be a concern and you can simply use a variable and an enum for it, since you'll only be checking collisions against a handful of instances.


aka fel666
There are two ways to look at GM objects / instances.

You can think of instances being, well, instances of objects. An object represents a specific game object, with all of its relevant data and events.
In which case, changing object doesn't make much sense.

The other way, is to think of instances as bags of related data. And objects as a bunch of events to apply to that instance. The object_index in this case acts like the state of that data.
In this view, switching object index is useful as a sort of state machine.

It's been commonly touted as bad practice to using instance change. But I think only because people make equivalencies to other programming language, and in that way are leaving a lot of what is great about GM objects and dynamically typed languages.

In your case, I suppose using instance change would be the best way to make use of engine features. However I don't think having a separate object per team is very elegant.
Imo it's much nicer to have the team be an instance variable, or be stored in a list; possibly both.


I prefer to create the new instance myself and handle any issues in that event then at the end delete the instance that created it myself. Saves a lot of head aches in my opinion.


One nice thing about instance_change as opposed to other methods of replacing one instance with another is that non-builtin variables that you've defined are preserved in the new instance, unless the Variable Definitions or Create event overwrite them (and if you're worried about that, I believe that passing false to instance_change suppresses both). You could use this to preserve information about the old instance, such as changing it into a different type of thing temporarily and then changing it back later. The ID also doesn't change, so if you've stored the instance ID somewhere, you don't necessarily need to find where it's stored and update it with the new ID. You need to be careful with things like Cleanup events, though. Generally, I only use instance_change to change to objects that share a common parent with all of the Cleanup I need, just to avoid issues with that.


well it separates areas like a grid but id guess its not a grid? it just shrinks and shrinks until it cant shrink nomore. so like you constantly divide squares. im not rly sure if this will work, like do you end when you get in a certain sized square or what? post some code. wont what i wrote be easyer and faster since its just one check? im going to loop thru all the instances anyway.