Corrupted Scenes due to Caching in .godot

[dekaravanhoc]

---

Bugsquad note: This issue has been confirmed several times already. No need to confirm it further.

---

Godot version

4.1.2 stable

System information

Godot v4.1.2.stable - Windows 10.0.22621 - Vulkan (Mobile) - dedicated NVIDIA GeForce RTX 4070 (NVIDIA; 31.0.15.3640) - AMD Ryzen 7 3700X 8-Core Processor (16 Threads)

Issue description

Basically, I get corrupted scenes all the time. With the scenes and all resources completely ok and working. (Build works without Problems.)
Also there is no Info why they are corrupted/cant be opened.. In 3.x at least you always could open the scene and fix dependencies etc. But thats another topic.

So the main problem is, that rebasing in git basically corrupts my project (several scenes in it) everytime.
It worked fine before the rebase.
To fix this I need to delete the .godot folder. I load the project - still getting corrupted scenes issues (probably due to some weird racing conditions, without caches in .godot) - reload it again and then everything works.

This workaround works basically all the time when something goes corrupt.

Sorry if this already exists I looked through the issues and did not found anything (which is a little bit weird, as I guess it should happen to nearly everyone who uses git with rebase.

Steps to reproduce

Have a more or less complex project.
Rebase in Git.

Minimal reproduction project

https://github.com/dekaravanhoc/Godot-MRP-Corrupted-Scenes

Starting the project (no .godot), shows an error for scene_loaded. Reloading it and the error is gone.
Running scene_loader.tscn - no problem.
Running scene_loaded.tscn - also no problem except, errors for scene_loaded and custom_ressource loading.
Deleting .godot corrupts scene_loaded.tscn and scene_loaded_inherited.tscn. Reloading fixes it.
Change some stuff - that does not break anything - adding vars etc.
Do 2-3 Commits and squash them.
Corrupts the scene_loaded.tscn and scene_loaded_inherited.tscn

[KoBeWi]

In 3.x at least you always could open the scene and fix dependencies etc. But thats another topic.

This is fixed by #83024

So the main problem is, that rebasing in git basically corrupts my project (several scenes in it) everytime.

Rebasing the project should not have any effect on its stability, unless you happen to break some dependencies or track the .godot folder (which is not recommended).

[dekaravanhoc]

.godot is not tracked
The rebase does not change anything (i.e. just squashing commits).
Opened Scripts and Scenes in Godot also get an update that something changed after a rebase (even so no content changed).

[KoBeWi]

Rebase will affect modified time of the files and Godot will detect that, even if their content is the same. It should not have any effect.

[dekaravanhoc]

That what I guessed regarding the file change detection in Godot.
Ill try to build a MRP in the next days.

[charliewhitfield]

In my experience, .godot/global_script_class_cache.cfg often fails to update classes when a change is made outside of the editor. This happens to me quite frequently because I work on the same project on two computers, using Git to update the project files (but not global_script_class_cache.cfg because it is not tracked).

It seems I can add a class without difficulty. But a removed classes on one computer is never (or at least not usually) removed from global_script_class_cache.cfg on my other computer. Changing a class in some other way also won't update and leads to errors that never resolve without deleting the .godot directory. So... since updating to Godot 4, I've found it necessary to delete the .godot directory EVERY time I make any class change other than a simple addition

Note: In Godot 3.x it was possible to update classes in a Git submodule (such that project.godot was not updated) and the editor was nevertheless able to resolve class differences and fix project.godot accordingly. Godot 4 can't seem to resolve problems when global_script_class_cache.cfg is in conflict with actual project files.

If I'm not mistaken, this seems related to #83395. In that issue, one creates a class error by duplicating a file. Well, the error is perfectly expected. However, unlike Godot 3.x, the editor can't seem to resolve these errors without the user manually deleting .godot.

[jdies]

Godot 4.2 beta - I just fixed a corrupt scene by copying the scene somewhere to save it, git revert the scene, overwrite the unchanged scene. Just putting this here, might open a proper issue report later, can't put time in a reproduction project right now.

1. Had many RigidBody2D in the scene moving at high pace and, while the game was running, changed Project Settings > Physics > 2D > Solver Iterations from 16 to 64
2. Game started slowing down significantly, I killed the Godot editor with task manager
3. Reopened project, the scene that was previously opened was now corrupted and couldn't be opened anymore

Again, here is how I fixed it

1. Copy the corrupted scene somewhere
2. git revert the corrupted scene
3. open project, open the previously corrupted scene - works now
4. close project, replace the now working scene with the one before the git revert
5. open project, open the scene. Everything works + my changes are there again

The entire godot workflow resolves around scenes. It's a really big issue if they get corrupted at random.

Seems like caching (or whatever temporary state) is the issue here, and seems like there's a number of other issues because of that too. Maybe a button for the user to nuke all caches really is a good idea as a first step. Even if rebuilding these caches takes some minutes, it still would be faster than googling.

[charliewhitfield]

Maybe a button for the user to nuke all caches really is a good idea as a first step. Even if rebuilding these caches takes some minutes, it still would be faster than googling.

+1 for that. Or, what I really want is a button to nuke '.godot/global_script_class_cache.cfg' without nuking all of my imported assets. (Note: deleting 'global_script_class_cache.cfg' by itself breaks the project. The only option seems to be to delete the entire .godot directory.)

[dekaravanhoc]

Hey,

I got some updates and narrowed the problem down in my case after some research and sparse information on this matter.
I think the biggest Problem is, that the error messages from the engine are so opaque...

But back to my case.
The issue resolved around preloading of resources and seemingly resulting cyclic references based on Static Typing, that lead to corrupt scenes.
And also preloading the same resource (tscn) twice from different code parts)

First Case: So I got Scene A that preloads Scene B.
Scene A also has a static var holding the instance of itself, when it gets instantiated.
Scene B uses that instance.
After deletion of .godot I get the error (Scene B) could not be loaded correctly.
After restarting this issue is seemingly resolved as I do net get any more errors in the console. But it is not.
As using this Scene B in Scene C (preloading/@export) seems to over time corrupt Scene C.

Second Case:
Edit
The Below Conclusion was wrong. I tested it a little bit more.
If you have a Singleton that preloads a Scene A and this Scene A somehow references back to the Singleton. (Directly or through added Resources or through Typed Variables it errors, when you start the scene. It still starts, and runs without problems, but if you inherit from that Scene or use it a a Resource etc. you start getting corrupted stuff.
Probably thats the same issue above, it just needs to be some cyclic Reference even through added ressources to the Class/Scene that preloads.

And I guess this would not only be the case with preloading but also adding Scenes/Resources via exports.
Edit End

I got Scene A and it gets preloaded in Scene B and Singleton C .
Also Scene B references Singleton C and uses the preloaded Scene indirectly through Singleton C and directly through preloading it.
A least there I get an error - that Scene A gets loaded from a different place, when starting without .godot
Also after restarting the editor the error is gone.
Only the same issues arise.
Solved when one preload is changed to load.

I only got there because I did a little refactoring and starting Scenes by itself in the process. Leading to error messages, that did not come up, when the game was loaded by starting the main scene. These error messages where still not helpful, but at least I had a starting point for some digging.

Cyclic referencing due to code interpretation of the editor when using preload?
The thing is, that these Scenes work fine. They run and you can open them without problems. So everything seems fine. Only if you use these Scenes for other Scenes the problem arises, as these Scenes get broken and you do not know why, because the tscn file is correct and every resource and reference is working too and it works when you run the game....

I am not quite shure how the rebasing fits in there, but nuking the caches did not really solve the problem, it just postponed it until some Scene gets corrupted beyond obvious repair (Using one of the Scenes described above i.e. inheriting from a Scene or preloading it.)

Hope that helps. Atm it feels pretty unusable to me, with the whole corrupted scene issues and error handling.

Edit
Added MRP and was also able to reproduce the git rebasing issue with it.

[RpxdYTX]

Still happening on 4.2.1.stable.arch_linux. what i found interesting (and what led me to this issue) is that the editor panics with a corrupt file but the preload doesn't (meaning that it's anoying to edit the scene, but should stiil work on release). Reloading the cache for a specific file could be a good fallback for when the engine finds a corrupt file, making so that the error only appears if the actual file is corrupted, not the cached one.

[MayaKerr]

If I'm not mistaken, this seems related to #83395. In that issue, one creates a class error by duplicating a file. Well, the error is perfectly expected. However, unlike Godot 3.x, the editor can't seem to resolve these errors without the user manually deleting .godot.

I'm having this issue with the duplicated classes-- would it resolve my class issues if I deleted the .godot in my project, or will this screw my project up more?

[MEELOJEELO]

Im having the same issue here, has there been any kind of fix?

[KoBeWi]

It should be fixed in 4.3.

[voidexp]

@KoBeWi can you link the PR/commit by which this is fixed? I'd like to give it a couple of runs, because seem to experience this issue a lot in after-rebase scenarios.

[KoBeWi]

#92303 fixes script issues.
#85159 and the follow-up fixes issues with corrupted scenes that can't be opened.