• Hello [name]! Thanks for joining the GMC. Before making any posts in the Tech Support forum, can we suggest you read the forum rules? These are simple guidelines that we ask you to follow so that you can get the best help possible for your issue.

[SOLVED] (VM) Accessing any room instance by its room editor name crashes the game

vdweller

Member
EDIT: Not really solved, but it needs to be properly reported to tech support. Read this https://forum.yoyogames.com/index.p...ditor-name-crashes-the-game.87432/post-523888

Hi all,

I'm aware that this subforum is not for official bug reporting. I have created several bug tickets in the past, I am aware of the process. However for this specific bug I haven't been able to reproduce it in a clean, empty project. Therefore I'd like some input regarding this before I do anything.

OK so my project (Gleaner Heights) has a lots of rooms. I have found that some of them now face a specific issue. The rooms that seem affected aren't the "older" rooms, i.e. those created up to the point the game had its launch, but some rooms created after that point but prior to v2.3.

Let's take on of these rooms. As you can see, I have this here instance in the Room Editor:
1626367519916.png

This instance is not referenced anywhere else in the game. And the issue I'm describing does not pertain to this particular instance, but ANY instance in the room.

So this instance's name is inst_7D0F81DA. Changing this name to inst_foo also doesn't change the issue at hand.

In my Debug code, I write:
GML:
    if keyboard_check_pressed(ord("L"))  {
        inst_7D0F81DA.visible=0;
    }
I am just accessing that particular instance, which, at the time I run the game and do this, is very alive, active and visible (also checked through instance_exists() etc for debug purposes)

The game then crashes with the following message:

___________________________________________
############################################################################################
ERROR in
action number 1
of Step Event0
for object obj_control:

Unable to find any instance for object index '68928' name '(null)'
at gml_Object_obj_control_Step_0 (line 478) - inst_7D0F81DA.visible=0;
############################################################################################
gml_Object_obj_control_Step_0 (line 478)


I have found out the following interesting things regarding this:

  1. The bug, as I said affects only specific rooms. Other (most) rooms' instances can be accessed just fine.
  2. Replacing the above code with the following
    GML:
    with inst_7D0F81DA visible=0;
    doesn't cause any crashes.
  3. The bug only appear in VM, in YYC it works just fine (tested both, with Clean first and then Build).
  4. If I duplicate the room, delete the original and then rename the copy like the original, the problem goes away.

I really don't know what to make of all this. Clearly there's something here, and my code accesses room instance all over the place.

Is this file corruption? But if something is corrupted, why does it go away with room duplication? And why does it work in YYC?
 
Last edited:
Something weird about the with statement; if the instance (inst_7D0F81DA in this case) existed previously, the with doesn't crash. I know this because:
GML:
// Create & Destroy
var inst = instance_create_depth(0, 0, 0, objTest);
instance_destroy(inst);

// Surprisingly this won't crash
with (inst)
{
    show_message("???");  
}
I absolutely agree though, this seems very strange. Is there a reason you're referencing instances by their IDs though? Avoiding this may prevent whatever this is from occurring. Can you look them up somehow through code instead of using the room editor IDs? Does that fix anything?

I also remember hearing that IDs are not guaranteed to remain the same between sessions and GM versions. I'll admit I don't have a source for this, so take it with a grain of salt.
 

Vusur

Member
I also remember hearing that IDs are not guaranteed to remain the same between sessions and GM versions
That is correct and can even change depending in which order you create instances. The thing is, this name used is not the ID. Its a constant name that holds the ID. We could name it ourself, if needed and refere to it in our code (if I'm not completly wrong).

That it crashes, when using the constant in a plain way, but works, when in a with statement is indeed strange. But with is a function, so who knows what it does internally.
If duplicating the room, deleting the original and renaming the dublicate fixes it, then it should not be a problem. There are sometimes similar situation (with different assets) and I had something similar in the past too. I was never able to reproduce it, but the duplicate trick fixed it back then.

Exporting and importing the whole project should also fix it. These problems usually points to some lost references in GMS. Export/Import rebuilds these connections, as far as I know. So when in doubt, just do that + clean the cash (the little broom icon next to the debugger and run button)
 

vdweller

Member
That is correct and can even change depending in which order you create instances. The thing is, this name used is not the ID. Its a constant name that holds the ID. We could name it ourself, if needed and refere to it in our code (if I'm not completly wrong).

That it crashes, when using the constant in a plain way, but works, when in a with statement is indeed strange. But with is a function, so who knows what it does internally.
If duplicating the room, deleting the original and renaming the dublicate fixes it, then it should not be a problem. There are sometimes similar situation (with different assets) and I had something similar in the past too. I was never able to reproduce it, but the duplicate trick fixed it back then.

Exporting and importing the whole project should also fix it. These problems usually points to some lost references in GMS. Export/Import rebuilds these connections, as far as I know. So when in doubt, just do that + clean the cash (the little broom icon next to the debugger and run button)
Export/Import, eh? I'll try it and let you know.

EDIT: Export/Import did nothing to fix the issue. Since there is different behavior between VM and YYC, this is definitely something the staff over at Tech need to look into.

Summoning @Dan from the depths of hell.
 
Last edited:

Roldy

Member
Export/Import, eh? I'll try it and let you know.

EDIT: Export/Import did nothing to fix the issue. Since there is different behavior between VM and YYC, this is definitely something the staff over at Tech need to look into.

Summoning @Dan from the depths of hell.
GML:
with inst_7D0F81DA visible=0;
This would not error if it is interpretting inst_7D0F81DA as an object ID like it says it is (object ID 68928). It simply wouldn't find any instances and do nothing.

If doing wonking stuff like renaming the instance or deleting it and giving it the same name fixes the issue (temporarily) then it would seem most likely some form of corruption. Somewhere 'inst_7D0F81DA' is having its value changed to '68928.'

Run the debugger. See if/when inst_7D0F81DA ever equals an instance ID 10000x, and then progress to pinpointing when it changes. Is it good on game start? Is it good on room start, room_end, etc.. Find out where so you can determine when it goes bad.
 

vdweller

Member
GML:
with inst_7D0F81DA visible=0;
This would not error if it is interpretting inst_7D0F81DA as an object ID like it says it is (object ID 68928). It simply wouldn't find any instances and do nothing.

If doing wonking stuff like renaming the instance or deleting it and giving it the same name fixes the issue (temporarily) then it would seem most likely some form of corruption. Somewhere 'inst_7D0F81DA' is having its value changed to '68928.'

Run the debugger. See if/when inst_7D0F81DA ever equals an instance ID 10000x, and then progress to pinpointing when it changes. Is it good on game start? Is it good on room start, room_end, etc.. Find out where so you can determine when it goes bad.
As I said in the first post, this affects entire rooms, not a specific instance. Renaming/deleting it and re-adding it doesn't fix anything. The fact that room duplication fixes this and that it's wrong only on VM makes me suspect it's not an error on my side.

Instance creation event for "inst_7D0F81DA" gives an id of 134634.
Subsequent (i.e. in a Step event ) debug print of "inst_7D0F81DA" gives the same ID.

I inspected the .yy files containing a specific instance reference and...everything seems OK? It's just a line in the room .yy referencing that instance like all the others. I just...don't know.
 

vdweller

Member
You keep going until you pinpoint when/where it changes.
It doesn't. Printing the ID and in the immediate next line accessing it crashes the game. It's not a programming/something got deleted issue (at least not on my part).
 

Roldy

Member
It doesn't. Printing the ID and in the immediate next line accessing it crashes the game. It's not a programming/something got deleted issue (at least not on my part).
What is the ID that is printed. In the instance list which instance has that ID. In the watch window what does inst_7D0F81DA and inst_7D0F81DA.visible report as?

In the watch window if you type in the numeric ID and right click->View As->Instance... what does it show
 

vdweller

Member
I managed to find the source of this bug, and holy poopio have I hit the motherlode.

The issue lies within room duplication. You see, duplicating a room also duplicates the instance names. So, although GM forbids you from giving the same name to two different instances, no checks are performed during room duplication. I have made a new test project which verifies this and reproduces it 100%.

Obviously instance names are stored in some C++ unordered_map or similar. In such structures, providing the same key twice messes it up and any queries may or may not return the correct result based on where the messed up key is touched upon in the query.

A glaring omission, if you ask me.

Will mark this "Solved" (lol) and will file a ticket properly. God damn it, Yoyo.
 
Top