Setting instances in create event

Hello,
It's my first time posting here, hope you guys can give me a light:

I have a very simple isometric tile editor:
1623359380584.png

My obj_editor's create event has a variable 'brush' that holds an instance of one of the two brushes that I already have implemented:
GML:
brush = obj_toolbox.brush_continuous
I also have a obj_toolbox with variables holding an instance of each brush in it's create event
GML:
brush_continuous = instance_create_depth(0, 0, 0, obj_brush_continuous);
brush_point_n_click = instance_create_depth(0, 0, 0, obj_brush_point_n_click);
The two buttons on the right change what instance of obj_brush1 or obj_brush2 the editor holds:

GML:
handleClick = function() {
    image_index = active;
    obj_editor.brush = obj_toolbox.brush_continuous;
}
The problem is, I'm not sure if creating and seting instances on the create event is the right path. I can't use obj_toolbox in my obj_editor's create event because it says it's not yet set; And most importantly, I'm afraid that with this method, i'll create a bunch of instances of a brush whenever I change between them.

Any tips?

Thanks!
 
Last edited:

GarbageHaus

Member
Just my 2 cents, but I've gotten in the habit of defining all my variables/constants in the Create event anyways just to avoid the "not set" nonsense. It might be a problem if I get to a large amount of instances at once, but so far so good.

I'm not entirely certain I see where you would create a bunch of brushes. I guess I'm missing some code or I'm just being dumb. You could always just check if you're creating a bunch of instances by adding this in the Create event:
GML:
show_debug_message("Instance created")
Also, it sounds like you might want to make use of instance_exists() in some logical condition if it gives you troubles.
 
But do you think it's a good practice to do an instance_create in my create event? Like:

obj_house has a door, so in it's create event I do:
GML:
door = instance_create(obj_door)
That's what's feeling off to me.

I have a obj_editor, and in its create event I instanciate a brush.
 

TheouAegis

Member
There is nothing wrong with creating things in the create event. As long as what you're creating is not persistent, it will exist only in that room only as long as you stay in that room. However the only thing I don't like about what you have right now is your setting the variable brush based on the assumption that the other instance has already run its create event. Like the other person said, I was just set brush to noone at first.
 
That's totally fine. If you want to both create an associated instance and also grab a reference to that instance any time another instance has been created (such as your door example, I assume a house would be spawning the door when the house gets created or something like that), the Create Event is a perfect place for that.
 

Vusur

Member
But do you think it's a good practice to do an instance_create in my create event? Like:

obj_house has a door, so in it's create event I do:
GML:
door = instance_create(obj_door)
That's what's feeling off to me.

I have a obj_editor, and in its create event I instanciate a brush.
Strictly speaking, there is nothing wrong with this. You just have to think about the relationship of those two objects/instances. I don't know if you are familiar with the m:n-Notation between objects/instances. As a crash course with your house/door example and simplified:
m and n means, how many instances of the left side know exactly that many instances of the right side. So you could get something like 1:1; 1:n; m:1 and m:n relationships. Your example would be this:

house 1:1 door => One house instance has exactly one door instances and this door is assigned only to that house. In that case, everything is fine, you can create it in the create event of your house. Everytime you create a new house, it gets its own door.

We go a little further and do other relationships. Just as an example.

house 1:n door => One house instance has exactly n door instances and those doors are assigned only to that house. Still fine. You would have n create statements in the create event of your house. You maybe fill an array. So everytime you create a new house, it gets its own n doors.

The next examples make no real sense, but I do them for completion.

house m:1 door => m house instances have exactly 1 door instance and they all refer to the same door instance. Well, here you can't use the create statement in the create event of the house, because you would create m door instances. The door needs to be there before the houses are created. But we can flip it.

(flipped) door 1:n houses => 1 door instance belongs to n houses. Well, we know how to deal with that, but this time, we go in the create event of the door instead of the house. The door creates those n houses and sets itself to the door variable within the house, if you wanna store it there.

Now the ugly. You can almost ignore this because I don't see a real use to even get to this point. If you reach the next point, the strategy has probably some flaws in general.

house m:n door => m house instances have n doors and each house uses the same n doors. Well, here can we do nothing. Flipping won't work. You can still solve this problem, but not within the create event (I think). But a state machine could do the trick in combination with a third, independent object. The third object creates all the instances of house and door and sets their state to "init". Now they exists and execute the init state. Because they exists, you can assign them wherever you want. But you see, this has nothing to do with creating the instances within the create event. It's already a different approach.

So as long as it's not a m:n relationship, you'll be fine. Takes a little time to see something like this by a glance, but you'll get there.
 
Strictly speaking, there is nothing wrong with this. You just have to think about the relationship of those two objects/instances. I don't know if you are familiar with the m:n-Notation between objects/instances. As a crash course with your house/door example and simplified:
m and n means, how many instances of the left side know exactly that many instances of the right side. So you could get something like 1:1; 1:n; m:1 and m:n relationships. Your example would be this:

house 1:1 door => One house instance has exactly one door instances and this door is assigned only to that house. In that case, everything is fine, you can create it in the create event of your house. Everytime you create a new house, it gets its own door.

We go a little further and do other relationships. Just as an example.

house 1:n door => One house instance has exactly n door instances and those doors are assigned only to that house. Still fine. You would have n create statements in the create event of your house. You maybe fill an array. So everytime you create a new house, it gets its own n doors.

The next examples make no real sense, but I do them for completion.

house m:1 door => m house instances have exactly 1 door instance and they all refer to the same door instance. Well, here you can't use the create statement in the create event of the house, because you would create m door instances. The door needs to be there before the houses are created. But we can flip it.

(flipped) door 1:n houses => 1 door instance belongs to n houses. Well, we know how to deal with that, but this time, we go in the create event of the door instead of the house. The door creates those n houses and sets itself to the door variable within the house, if you wanna store it there.

Now the ugly. You can almost ignore this because I don't see a real use to even get to this point. If you reach the next point, the strategy has probably some flaws in general.

house m:n door => m house instances have n doors and each house uses the same n doors. Well, here can we do nothing. Flipping won't work. You can still solve this problem, but not within the create event (I think). But a state machine could do the trick in combination with a third, independent object. The third object creates all the instances of house and door and sets their state to "init". Now they exists and execute the init state. Because they exists, you can assign them wherever you want. But you see, this has nothing to do with creating the instances within the create event. It's already a different approach.

So as long as it's not a m:n relationship, you'll be fine. Takes a little time to see something like this by a glance, but you'll get there.
Thank you and everyone else for such instructive responses.

So in my case I have one obj_editor that holds an instance of a brush, so I think it's ok.
I think I'll manage, now I just have the problem that the instances of all brushes are on the room at the start of the game, not just when I select one.
 
Last edited:
Personally, I'd probably have a generic brush object, with the data for the brushes themselves stored in an appropriate data structure (or stored in functions that are attached to a brush method). Then I'd swap what data the generic brush object is reading when the user wants to change brushes.
 
Personally, I'd probably have a generic brush object, with the data for the brushes themselves stored in an appropriate data structure (or stored in functions that are attached to a brush method). Then I'd swap what data the generic brush object is reading when the user wants to change brushes.
What I did just now is I deactivated all the created brush instances and activated the selected one, when it gets selected.
Your suggestion sounds promising. I'll try.
Thank you!
 
Top