(Fixed) What may really be a bug with unique names...?

Godot Version

v4.4.1.stable.official [49a5bc7b6]

Question

(Note this is not the FAQ about accessing unique-names from the wrong scene. This is the reverse, where there should be local unique-names, but for some reason they are not being found…)

We have a set of nested scenes, each with its own gdscript:

Main (class: Main, script-file: main.gd) +- Location (class: LocationDisplay, script-file: location_display.gd) +- MonsterDisplay (class MonsterDisplay, script-file: monster_display.gd)

And there are unique names defined at each level.

My problem is that the unique names defined in monster_display.tscn/gd are not being found.

I initially saw this as MonsterDisplay finding nodes from LocationDisplay instead, but I have read elsewhere on the forum that this is (semi) intentional behaviour when the local scene has no unique names. However the local scene does have unique names:


I have confirmed this is consistent (and I think wrong) behaviour by:

  1. renaming the nodes in MonsterDisplay, in scene and script, when I do this, the script stops finding the nodes in its parent, but still cannot find the local nodes
  2. renaming the nodes in LocationDisplay, in scene and script, with exactly the same effect
  3. completely destroying MonsterDisplay and recreating it, from scratch, under a different name, this has no effect on the problem…
  4. closing Godot, deleting the .godot directory, and reopening, this also has no effect

So I think I am correct in saying that, for some reason, the unique-names in MonsterDisplay are not being found, so the scene thinks it has none, and falls back on searching in its parent. With the overall effect that if parent and child have the same node names, it finds the ones in the parent, and if the names are different it can’t find anything at all…

It is not large, so there is a zip of the whole project here: https://drive.google.com/file/d/1xvIHSsWvB2m_nIyafCsCXQYdfkefPy3I/view?usp=sharing

Thanks,

Ian

For clarity, that Zip has the MonsterDisplay nodes renamed to NameBob and DisplayBob, which is the cleanest demo of the problem, I think as that doesn’t find “Name” and “Display” in the parent… I think finding stuff in the parent is just a side effect of not finding the local nodes… but you can rename to remove the two "Bob"s if you want to see that.

Ah, wait, I was looking for the nodes in _init rather than _ready, this was not the case originally (I had @oneready vars), but I broke it when changing things for debugging, and it will have mislead me with the tests I made on this, let me go back and identify when things really didn’t work…

OK, so as far as I can tell, after correcting how I was looking for the nodes things are still as I described and I can now add the following:

  • moving MonsterDisplay into Main is still broken
  • making MonsterDisplay the main scene is not broken
  • renaming the nodes neither breaks anything when using MonsterDisplay as the main scene, nor fixes anything when not…
  • commenting out the whole of monster_display.gd except for a _ready where I can stick a breakpoint doesn’t change anything either
  • nor does completely renaming everything away from monster* (I was really getting desperate at this point…)

Updated archive with:

  • MonsterDisplay directly in Main
  • most of it commented out
  • empty _ready so you can breakpoint it…

Aagh! I worked it out, I had managed to insert the class into the scene-tree rather than the actual scene I wanted… hitting “+” on a node and then searching for your custom class name does that, rather than drag’n’dropping the scene from the resource tree… Now I realise what I did it is obvious, but as a semi-newby I had no idea those weren’t doing the same thing :sad_but_relieved_face:

1 Like

I love that you managed to post the original issue, document your thought process and resolve the problem by yourself all within 1h.
That’s the way to go! :slight_smile:

By the way, you can mark your last message as a solution to the problem, so that it shows as solved and the topic will be closed after a month. No need to update the title.

1 Like