Godot fails to open a scene, claiming a script is missing, but the script is there!

[unfa]

Godot version

v4.1.1.stable.official [bd6af8e]

System information

Godot v4.1.1.stable - Arch Linux #1 SMP PREEMPT_DYNAMIC Thu, 06 Jul 2023 18:35:54 +0000 - Vulkan (Forward+) - dedicated AMD Radeon RX 6800 XT (RADV NAVI21) () - AMD Ryzen 9 3900X 12-Core Processor (24 Threads)

Issue description

When I was working on my game, changing stuff in scripts, at some point the game started crashing during normal play, I've found that it throws an error... that makes absolutely no sense. It says a property doesn't exist on a scene that uses a script that has that property.

Then opening a scene that uses this script fails claiming the script is missing.
It's not missing though - it's there, and other scenes using it open fine.
What's even weirder is that all of these problems aren't there if I go back one commit in my game's git repository, even though the faulty commit didn't affect the feral script or the troublesome scene.

Here's a thorough video demonstration of the issue. I tried a few versions of Godot and had the same results. I've recorded the video using an Arch-Linux provided binary for 4.1.1 stable, but I tested again on an official build from Godotengine.org and had the exact same problem.

I tried clearing .godot to force a full project reimport, I tired running the editor with _sc_ (self-contained mode) and renaming existing editor_data folder to have a clean slate - no change.

Please watch the video for a deeper context and more detail:
https://youtu.be/gmFhS-m0AUM

Steps to reproduce

The only reproduction steps I can provide is to open my game's project and try it on your system:

1. Follow the guide here: https://codeberg.org/Liblast/Liblast#_how_to_edit_the_game TL;DR: clone the repository with git-LFS, or it won't work.
2. Test the main branch and see if the game works (it should as it does in my video).
3. Then checkout this commit and see if it fails like it does in my video: https://codeberg.org/Liblast/Liblast/commit/915cbc735f2a416bc2985e02ea0c2bc838c8e012

Minimal reproduction project

N/A

[atirut-w]

Can you provide a minimal way to reproduce this? The commit diff is pretty sizeable and it could be a change someone forgot to stage for all I know.

[unfa]

I have stashed all changes and switched to a different branch and it did work there - wouldn't that mean that any unstaged changes were rolled back at this point? I then went back to the faulty commit without popping the stash and the problem occured again.That seems to indicate only the committed changes have had impact here, no?

[atirut-w]

I can try the repro steps later today, but changes that big can make it harder to figure out the exact cause. Sorry if that came out as being aggressive.

[KoBeWi]

This might happen if the script has error or it preloads anything with an error. I just had a similar problem when upgrading an addon from Godot 3.

[unfa]

I can try the repro steps later today, but changes that big can make it harder to figure out the exact cause. Sorry if that came out as being aggressive.

No problem. I'll try to narrow it down a bit, but I'm not sure when and how successful it'll be.

[unfa]

This might happen if the script has error or it preloads anything with an error. I just had a similar problem when upgrading an addon from Godot 3.

Wouldn't that be fixed after restarting Godot and/or clearing the import cache?

[KoBeWi]

In my case I had to fix the broken scripts. I didn't try clearing the cache, but they were new files, so it likely wouldn't help.

[unfa]

Yeah, I've done a search&replace in files and this started happening afterwards, but Godot's behavior is erratic and doesn't really point me towards fixing any mistakes I could have made in my scripts.

[KoBeWi]

Usually there should be some error in the external console, pointing to some filenames.

[unfa]

Hmm. I didn't check there. I assumed the debugger would tell me what's up
It said something, but it seems like it's not accurate, so there must be something else beneath that.

[KoBeWi]

Can you post the full output you see when trying to load the scene? (from the console)

[unfa]

@KoBeWi Here you go:

❯ ./Godot_v4.1.1-stable_linux.x86_64 --path ../Game/ -e
Godot Engine v4.1.1.stable.official.bd6af8e0e - https://godotengine.org
Vulkan API 1.3.246 - Forward+ - Using Vulkan Device #0: AMD - AMD Radeon RX 6800 XT (RADV NAVI21)
 
ERROR: res://Assets/Effects/PlasmaComboExplosion.tscn:737 - Parse Error: 
   at: _parse_node_tag (scene/resources/resource_format_text.cpp:283)
ERROR: Failed loading resource: res://Assets/Effects/PlasmaComboExplosion.tscn. Make sure resources have been imported by opening the project in the editor at least once.
   at: _load (core/io/resource_loader.cpp:273)
WARNING: Blend file import is enabled in the project settings, but no Blender path is configured in the editor settings. Blend files will not be imported.
     at: _editor_init (modules/gltf/register_types.cpp:73)
ERROR: Condition "nc == 0" is true. Returning: nullptr
   at: instantiate (scene/resources/packed_scene.cpp:92)

[KoBeWi]

I'd suspect GameState.gd changes. The script is indirectly referenced by the faulty scene via a chain of class names.
Maybe I'll just download the project instead of guessing 🤔

[KoBeWi]

Ok I managed to open the scene. In Projectile.gd remove the preload for PlasmaComboExplosion.tscn. It's a global script so if the scene is preloaded, it will never be unloaded (even in the editor) and it seems to cause some problems.

[unfa]

Oh... Hmm. I wonder why Godot arrived at such an error message. Do you think something like this could be made explicitly recognized by Godot, so users can get an error that'd let them fix the problem?

[unfa]

This works! I can carry on with my project - however, I have no idea how you've found that this is the problem.
Are preload a mindefield still?
They used to cause some horrible problems, so I got rid of all preloads like a year+ ago, but I've seen that problem was fixed so I started using them again - looks like they are still dangerous...

[KoBeWi]

Preloads are fine, but in global classes they can cause problems apparently.

[cliedelt]

I can confirm this issue ! There is a problem with "class_name" and preload. After removing the class_name in another class with preloads (which was not causing the issue) fixed the issue.

[clivecrous]

Can confirm I too had this issue ( specifically #80324 ) and removing class_name definitions from all my scripts that were using preloads "fixed" the issue:

ERROR: Condition "nc == 0" is true. Returning: nullptr
   at: instantiate (scene/resources/packed_scene.cpp:92)