Putting an Object in a folder breaks my game

Leon Hurley

Member
I'm in the very early stages of a simple strategy game which involves picking up things with the mouse to move them. At some point the object/mouse tracking seemed to break unless you moved slowly but I couldn't understand why as that's pretty much day one code I've not touched since. I've rebuilt the project from the last working version 6 or 7 times now and each time I 'fixed' it, the same problem occurred.

I've since discovered that organising my objects into folders somehow breaks the game. After a lot of experimentation creating folders and moving objects one at a time I've narrowed it down to the mouse object - if put that in a folder, it breaks the game. The only code in the mouse object is this in the Step event:

x = mouse_x
y = mouse_y

If I take the mouse object out of the folder, it sometimes fixes the problem but not always - I've versions of the game that seem to be permanently broken even if you delete every single folder, and other versions that work when you take the mouse object out of the folder. I've also found that if I delete the mouse object and recreate it from scratch - new object, same name, same sprite, same code - the game starts working again.

Literally no idea what to do here. Obviously leaving the mouse object out of a folder is the immediate fix but something is obviously very wrong.

[UPDATE] Simply moving the mouse pointer in the Object hierarchy breaks the game. Just moved it out of the way because it was annoying me in the middle and got the same game breaking effect. Had to delete it and recreate a new one to get the game working.
 
Last edited:

jo-thijs

Member
I'm in the very early stages of a simple strategy game which involves picking up things with the mouse to move them. At some point the object/mouse tracking seemed to break unless you moved slowly but I couldn't understand why as that's pretty much day one code I've not touched since. I've rebuilt the project from the last working version 6 or 7 times now and each time I 'fixed' it, the same problem occurred.

I've since discovered that organising my objects into folders somehow breaks the game. After a lot of experimentation creating folders and moving objects one at a time I've narrowed it down to the mouse object - if put that in a folder, it breaks the game. The only code in the mouse object is this in the Step event:

x = mouse_x
y = mouse_y

If I take the mouse object out of the folder, it sometimes fixes the problem but not always - I've versions of the game that seem to be permanently broken even if you delete every single folder, and other versions that work when you take the mouse object out of the folder. I've also found that if I delete the mouse object and recreate it from scratch - new object, same name, same sprite, same code - the game starts working again.

Literally no idea what to do here. Obviously leaving the mouse object out of a folder is the immediate fix but something is obviously very wrong.

[UPDATE] Simply moving the mouse pointer in the Object hierarchy breaks the game. Just moved it out of the way because it was annoying me in the middle and got the same game breaking effect. Had to delete it and recreate a new one to get the game working.
When you say that the mouse tracking breaks unless you move slowly, I would imagine the issue would be something else.
However, it is possible that moving an object in the resource tree breaks your project, for the following reason:
GameMaker generates an "object identifier" for each object in your game.
This identifier is an integer and will be used by GameMaker at run-time to refer to the object.
GameMaker:Studio generates these object identifiers based on how the objects are placed in the resource tree.
The first object in the resource tree gets the object identifier 0.
The second one gets as object identifier 1 and so on.
GameMaker also generates global constants for each object that has the object's name as name and the object's identifier as value.
This makes it so when you have an object called objPlayer, that you can simply write objPlayer in code and GameMaker will know what you're talking about.
objPlayer is a constant that gets interpreted as objPlayer's identifier.
Now, in GameMaker you can do things like:
GML:
objPlayer.x = mouse_x;
but because objPlayer is just a constant that is interpreted as objPlayer's id, you could also have used (assuming objPlayer is the first object in the resource tree):
GML:
myObject = 0;
myObject.x = mouse_x;
It may be possible that you made a mistake somewhere of this kind, where you passed a wrong object identifier that isn't updated to the new position of the mouse object in the resource tree.

An other possibility may be (although I'm unsure how GameMaker:Studio 2 handles this exactly) the order in which objects' step events are executed depends on the resource tree.
If moving your mouse object in the resource tree makes it so the step event is somehow executed later, then the mouse object's position may be updated too late,
causing a desync between the mouse object's position and the actual mouse position during the step event of some other dragging related object.

To really pin down the issue, I would need to see more dragging related code of your project.

I hope this helps!
Let us know if you have any questions or updates on the issue!
 

Leon Hurley

Member
When you say that the mouse tracking breaks unless you move slowly, I would imagine the issue would be something else.
However, it is possible that moving an object in the resource tree breaks your project, for the following reason:
GameMaker generates an "object identifier" for each object in your game.
This identifier is an integer and will be used by GameMaker at run-time to refer to the object.
GameMaker:Studio generates these object identifiers based on how the objects are placed in the resource tree.
The first object in the resource tree gets the object identifier 0.
The second one gets as object identifier 1 and so on.
GameMaker also generates global constants for each object that has the object's name as name and the object's identifier as value.
This makes it so when you have an object called objPlayer, that you can simply write objPlayer in code and GameMaker will know what you're talking about.
objPlayer is a constant that gets interpreted as objPlayer's identifier.
Now, in GameMaker you can do things like:
GML:
objPlayer.x = mouse_x;
but because objPlayer is just a constant that is interpreted as objPlayer's id, you could also have used (assuming objPlayer is the first object in the resource tree):
GML:
myObject = 0;
myObject.x = mouse_x;
It may be possible that you made a mistake somewhere of this kind, where you passed a wrong object identifier that isn't updated to the new position of the mouse object in the resource tree.

An other possibility may be (although I'm unsure how GameMaker:Studio 2 handles this exactly) the order in which objects' step events are executed depends on the resource tree.
If moving your mouse object in the resource tree makes it so the step event is somehow executed later, then the mouse object's position may be updated too late,
causing a desync between the mouse object's position and the actual mouse position during the step event of some other dragging related object.

To really pin down the issue, I would need to see more dragging related code of your project.

I hope this helps!
Let us know if you have any questions or updates on the issue!
Thanks for this. I'm working today but I'll have a look properly tonight at how I'm identifying the mouse object and the things it's dragging. The object identifier thing makes sense although I've only used names, no numbers. I might have something screwy in a collision check somewhere though. I'll let you know.
 

Nidoking

Member
The object identifier thing makes sense although I've only used names, no numbers.
The name IS a number. In the same way that x is a name for a variable that stores a number, which is the horizontal position of the instance in your game, objPlayer is a name for a number that represents the object.
 

Leon Hurley

Member
The name IS a number. In the same way that x is a name for a variable that stores a number, which is the horizontal position of the instance in your game, objPlayer is a name for a number that represents the object.
Looking through the code the only references to the mouse pointer object are instance_place or place_meeting, a couple of which are var, but nothing I haven't done plenty of times before. I can't see anything out of the ordinary. This is the sum total of all references to the object:

Searching for 'obj_pointer'...
obj_dogs-Step at line 11: if place_meeting(x,y,obj_pointer) && mouse_check_button(mb_left)
obj_blockSearch-Step at line 9: if place_meeting(x,y,obj_pointer) && mouse_check_button(mb_left)
obj_goButton-Step at line 3: if place_meeting(x, y, obj_pointer) mouseOn =1 else mouseOn = 0;
obj_searchLine4-Step at line 11: if place_meeting(x,y,obj_pointer) && mouse_check_button(mb_left)
obj_blockParent-Step at line 3: //mouseCheck = instance_place(x, y, obj_pointer);
obj_blockParent-Step at line 50: var mouseCheck = instance_place(x, y, obj_pointer);
obj_searchLine-Step at line 11: if place_meeting(x,y,obj_pointer) && mouse_check_button(mb_left)
obj_searchLine3-Step at line 11: if place_meeting(x,y,obj_pointer) && mouse_check_button(mb_left)
Search Complete (8 results)

This is literally a few weeks of testing an idea out, it's not even a 'thing' really yet so there's nothing beyond basics.
 

jo-thijs

Member
Looking through the code the only references to the mouse pointer object are instance_place or place_meeting, a couple of which are var, but nothing I haven't done plenty of times before. I can't see anything out of the ordinary. This is the sum total of all references to the object:

Searching for 'obj_pointer'...
obj_dogs-Step at line 11: if place_meeting(x,y,obj_pointer) && mouse_check_button(mb_left)
obj_blockSearch-Step at line 9: if place_meeting(x,y,obj_pointer) && mouse_check_button(mb_left)
obj_goButton-Step at line 3: if place_meeting(x, y, obj_pointer) mouseOn =1 else mouseOn = 0;
obj_searchLine4-Step at line 11: if place_meeting(x,y,obj_pointer) && mouse_check_button(mb_left)
obj_blockParent-Step at line 3: //mouseCheck = instance_place(x, y, obj_pointer);
obj_blockParent-Step at line 50: var mouseCheck = instance_place(x, y, obj_pointer);
obj_searchLine-Step at line 11: if place_meeting(x,y,obj_pointer) && mouse_check_button(mb_left)
obj_searchLine3-Step at line 11: if place_meeting(x,y,obj_pointer) && mouse_check_button(mb_left)
Search Complete (8 results)

This is literally a few weeks of testing an idea out, it's not even a 'thing' really yet so there's nothing beyond basics.
Have you also checked the second possibility I suggested?
There's a lot of place meetings with obj_pointer in step events.
You set the x and y coordinates of obj_pointer to mouse_x and mouse_y in the step event, right?
What happens if you do that in the begin step (or end step) event instead?
Try using show_debug_message to figure out in which order step events are triggered.
Use a global variable to count the amount of steps that have passed and include that in the debug messages.
 

TheouAegis

Member
I've since discovered that organising my objects into folders somehow breaks the game. After a lot of experimentation creating folders and moving objects one at a time I've narrowed it down to the mouse object - if put that in a folder, it breaks the game. The only code in the mouse object is this in the Step event:
You aren't using the beta, are you? Everything you posted in your first post is symptomatic of an invalid (id) variable reference or improper use of self or other.

First thing's first, search the entire project for references to self and references to other. Make sure they are all self.id or other.id and not simply the keywords by themselves. If you find any such references, correct them and then test your project.

Search your project for all references to with. If any of those references is targeting a variable (e.g., with inst), trace that variable. If there is any possibility that variable could become -1 or 0, that variable is a probable culprit. Same goes for any variables used in dot notation (e.g., inst.x), but finding these references is much harder.
 

Leon Hurley

Member
Have you also checked the second possibility I suggested?
There's a lot of place meetings with obj_pointer in step events.
You set the x and y coordinates of obj_pointer to mouse_x and mouse_y in the step event, right?
What happens if you do that in the begin step (or end step) event instead?
Try using show_debug_message to figure out in which order step events are triggered.
Use a global variable to count the amount of steps that have passed and include that in the debug messages.
Okay, so changing the pointer step event to a begin step makes the problem happen, changing it back fixes it. I think my main problem atm is I can't fully grasp how reordering an object in the Object tree can affect code that's yet to run, and that lack of understanding is making it hard to know what to look for. I'm not even sure where to place a break point as a result. Placing one in the mouse pointer object just runs through everything and I can't see anything out of the ordinary there.
 

Roldy

Member
@Leon Hurley You have never said what happens. All you have said is 'the game stops working,' or the mouse 'breaks the game,' or 'At some point the object/mouse tracking seemed to break'

Is all that is happening that your in-game mouse stops dragging things?

Or are you receiving an error at runtime or compile time? Is your game crashing or just behaving in a way you don't expect?
 

Leon Hurley

Member
You aren't using the beta, are you? Everything you posted in your first post is symptomatic of an invalid (id) variable reference or improper use of self or other.

First thing's first, search the entire project for references to self and references to other. Make sure they are all self.id or other.id and not simply the keywords by themselves. If you find any such references, correct them and then test your project.

Search your project for all references to with. If any of those references is targeting a variable (e.g., with inst), trace that variable. If there is any possibility that variable could become -1 or 0, that variable is a probable culprit. Same goes for any variables used in dot notation (e.g., inst.x), but finding these references is much harder.
Not the beta, v2.2.5.481. I've not any self or others at all. There's a fair few inst.x call outs which I can work through, stuff like this:

GML:
var CollissionCheck = instance_place(x, y, obj_detectionRadiusObject)
if CollissionCheck CollissionCheck.visible = 1
None of that is runs until you do something, though. The slowdown happens from the start, when the only thing happening is moving the mouse around.
 

Leon Hurley

Member
@Leon Hurley You have never said what happens. All you have said is 'the game stops working,' or the mouse 'breaks the game,' or 'At some point the object/mouse tracking seemed to break'

Is all that is happening that your in-game mouse stops dragging things?

Or are you receiving an error at runtime or compile time? Is your game crashing or just behaving in a way you don't expect?
Sorry, yeah, when I said the mouse tracking breaks I meant that the object you're trying to pick up only follows the mouse if you move very slowly. If you go above a certain speed you leave whatever you're moving behind. Normally you can pick it up whiz it about in a blur and everything's fine but as soon as I move the mouse pointer in the Object tree it breaks. The only way to get 'fix' it currently is to destroy the pointer object and make a new one. Or never move it again.

What everyone is saying about the object number getting messed up by the move sounds like it has to be it but it's a bit beyond me to really get where I could be doing that. I'm not trying anything new (for me) so there's not any obvious culprit or area to zero in on.
 

Roldy

Member
Simply moving the mouse pointer in the Object hierarchy breaks the game. Just moved it out of the way because it was annoying me in the middle and got the same game breaking effect. Had to delete it and recreate a new one to get the game working.
Can you currently reproduce this? Have the mouse object in one position in the resource tree and the 'game works,' then move the mouse object to another position in the resource tree and then it 'breaks the game.'

If you can consistently reproduce this then look at the object id for the mouse object when it is working. And then look at what it becomes when you move it. If you moved it up the resource tree then all other resources' object id between its original place and its new position will change as well.

If you move the mouse object in the resource tree up/down just one position does it 'break the game?' If not does it break when you move it up/down two positions etc... if you move the mouse up 4 positions in the resource tree and it works fine but then when you move it one more position up it breaks, then the object you just displaced with the mouse object would be a good candidate to look at closer.

At some point with a systematic search like this, you may be able to narrow down exactly where it does and does not break and determine either the actual object id or instance id that may be causing your problems.

As a side note: you mentioned moving your code from the step to begin step causes the same issue? Input events occur between the begin_step and step events. No input event will trigger for a frame until after begin step, but before the Step event. So be aware of that and think about how it relates to your issue.
 
Last edited:

jo-thijs

Member
Okay, so changing the pointer step event to a begin step makes the problem happen, changing it back fixes it. I think my main problem atm is I can't fully grasp how reordering an object in the Object tree can affect code that's yet to run, and that lack of understanding is making it hard to know what to look for. I'm not even sure where to place a break point as a result. Placing one in the mouse pointer object just runs through everything and I can't see anything out of the ordinary there.
Ok, so that makes it likely that you have multiple step events that depend on their respective execution orders for a correct result.

The GameMaker manual explicitly leaves the exact execution order of events unspecified, as this is something prone to change in the future.
It's entirely possible that the execution order of step events depends on the order of the objects in the resource tree, which would explain the breaking when moving the object in the resource tree.
I'm not able to test this unfortunately, as I don't have GM:S 2 myself.

I would suggest looking at code relevant to the dragging process and looking in which order events need to be executed for everything to properly work.
Can you post the relevant code?

Can you currently reproduce this? Have the mouse object in one position in the resource tree and the 'game works,' then move the mouse object to another position in the resource tree and then it 'breaks the game.'

If you can consistently reproduce this then look at the object id for the mouse object when it is working. And then look at what it becomes when you move it. If you moved it up the resource tree then all other resources' object id between its original place and its new position will change as well.

If you move the mouse object in the resource tree up/down just one position does it 'break the game?' If not does it break when you move it up/down two positions etc... if you move the mouse up 4 positions in the resource tree and it works fine but then when you move it one more position up it breaks, then the object you just displaced with the mouse object would be a good candidate to look at closer.

At some point with a systematic search like this, you may be able to narrow down exactly where it does and does not break and determine either the actual object id or instance id that may be causing your problems.

As a side note: you mentioned moving your code from the step to begin step causes the same issue? Input events occur between the begin_step and step events. No input event will trigger for a frame until after begin step, but before the Step event. So be aware of that and think about how it relates to your issue.
Good suggestion.
 
Top