Scene corruption after forced reboot on Linux

[ckdarby]

Tested versions

v4.2.stable.official [46dc277]

System information

Ubuntu 22.04 - v4.2.stable.official [46dc277]

Issue description

Believe I did a sudo reboot now and was able to trigger a non-proper flushing of the file causing a corruption

scene/resources/resource_format_text.cpp:284 - res://scenes/game/Bullet.tscn:10 - Parse Error: 
  Failed loading resource: res://scenes/game/Bullet.tscn. Make sure resources have been imported by opening the project in the editor at least once.
  Failed to instantiate scene state of "res://scenes/game/Bullet.tscn", node count is 0. Make sure the PackedScene resource is valid.
  Failed to instantiate scene state of "res://scenes/game/Bullet.tscn", node count is 0. Make sure the PackedScene resource is valid.
  Failed to instantiate scene state of "res://scenes/game/Bullet.tscn", node count is 0. Make sure the PackedScene resource is valid.

Bullet.tscn

[gd_scene load_steps=4 format=3 uid="uid://bpw08h6qjtf80"]

[ext_resource type="Texture2D" uid="uid://87j7ldt0dsn7" path="res://icon.svg" id="1_rqlw1"]
[ext_resource type="Script" path="res://scenes/game/Bullet.gd" id="1_v4orp"]

[sub_resource type="RectangleShape2D" id="RectangleShape2D_21qps"]
size = Vector2(32, 32)

[node name="Area2D" type="Area2D"]
script = ExtResource("1_v4orp")

[node name="Sprite2D" type="Sprite2D" parent="."]
scale = Vector2(0.25, 0.25)
texture = ExtResource("1_rqlw1")

[node name="CollisionShape2D" type="CollisionShape2D" parent="."]
texture_filter = 1
shape = SubResource("RectangleShape2D_21qps")

[connection signal="body_entered" from="." to="." method="_on_body_entered"]

Steps to reproduce

Probably have the script opened in a potentially unsaved state and force a reboot...

Minimal reproduction project (MRP)

N/A

[akien-mga]

That Bullet.tscn doesn't seem corrupted. I can open it fine if copy pasting it to a project (after making sure to create a script at scenes/game/Bullet.gd).

Do you still get this issue after restarting the editor?

What about if you rename the .godot folder to something else, so it's re-created? (Please keep it around at first, because if that fixes the issue, checking the diff between the two folders could give a hint at to what the problem is.)

[MartinVacheron]

I just had the same problem and removing the .godot folder made the scene work again. I kept the old .godot folder and the differences on the .tscn file are:

Old one:

[folding]

node_unfolds=[NodePath("."), PackedStringArray("Theme", "Layout", "Layout/Transform"), NodePath("Button/PropertyName"), PackedStringArray("Theme Overrides", "Theme Overrides/font_sizes")]
resource_unfolds=[]
nodes_folded=[]

new one:

[folding]

node_unfolds=[NodePath("."), PackedStringArray("Layout", "Theme"), NodePath("Button"), PackedStringArray("Layout"),
NodePath("Button/PropertyName"), PackedStringArray("Layout", "Theme Overrides"), NodePath("Elements"), PackedStringArray("Layout", "Theme Overrides"), NodePath("Elements/ElementsNames"), PackedStringArray("Theme Overrides"), NodePath("Elements/ElementsValues"), PackedStringArray("Layout")]
resource_unfolds=[]
nodes_folded=[]

Hope this helps.

[akien-mga]

@MartinVacheron This specific difference is probably not the one that caused the issue. Is there no other difference? Files like uid_cache.bin are very likely different for example.

If you're able to share those two folders for us to compare, that could be quite useful.

[MartinVacheron]

Yes no problem for the folders, here they are. The first one is the one not working. uid_cache.bin seems to be unchanged.
.godot_corrupted.zip
.godot.zip

[ckdarby]

Here is the live video though I think the video will only be valid on Twitch for 7-60 days.

Here are the key points:

• ~2:00, I open Godot to the corrupted scene
• ~14:40, I git clone the code and recreated the entire Bullet.tscn
• ~22:35, I reload Godot. SAME corruption issue
• ~25:00, Godot core devs can see the pain I had of self blaming for even upgrading
• ~26:30, Decide to try to cheat around the bug. By abandoning any reference to Bullet.tscn and start a new file Test123.tscn
• ~28:45, Somehow Test123.tscn is now corrupt
• ~28:55, Corrupting Test123.tscn has now somehow uncorrupted Bullet.tscn
• ~30:35, Able to @onready and change the gdscript back to Bullet.tscn without any issue and reload Godot and have no issues now

@akien-mga I hope all the core contributors watch the ~35 minutes at 2x speed to see the level of frustration as a new Godot user hitting this kind of bug. If I recall I have some harsh words said in the stream along the lines of, "This literally makes me want to quit using Godot."

[aesee]

I've had the same issue on the latest official from Steam (Windows).
I fixed the error on my side by removing 2 lines about the attached script from .tscn file, and now the scene can be open.

[TheRealSlander]

I had the exact same problem with version 4.2.1rc1 under Linux. What is weird is that despite the fact that I'm unable to open the scene in the editor due to corrupted .tscn file, running the project works without error.

To fix the corrupted scene(s), I simply removed the script references in the .tscn file(s) inside an external editor (2 lines), then reloaded Godot project, opened the scene(s) (which does not have an attached script anymore, so they open fine now) then reattached the corresponding script to the scene(s) via the editor. Saved the project.

I then reloaded Godot current project to ensure all was correct and all was fine.

I noticed the problem occurring with the same project once I upgraded my Godot version (from 4.2rc2 to 4.2 stable and from 4.2 stable to 4.2.1rc1. So it seems to occur each time the Godot engine is updated... Not sure about that though.

PS: The produced error in the debugger is not helpful at all, as it only says that the scene is corrupted but not in which way. Had a hard time finding how to fix the scene file.

EDIT: After more investigations, I found that from all the opened scenes in my project, the only ones that get corrupted are the ones containing preloaded PackedScenes as const / var in the attached script.

For example, one had this line:
const MY_SCENE_SCENE : PackedScene = preload("My Scene.tscn")
Hope this helps...

[MartinVacheron]

EDIT: After more investigations, I found that from all the opened scenes in my project, the only ones that get corrupted are the ones containing preloaded PackedScenes as const / var in the attached script.

Interesting, the scene that was corrupted on my side had a script with const variables containing PackedScenes too.

[aesee]

The script attached to my corrupted scene doesn't have PackedScene as a variable but contains the line with preload("My Scene.tscn")

[debris]

reproduced this issue as well in my project (4.2 macos). after removing .godot some other scenes also stopped opening with the same error message

[debris]

also reproduced on v4.2.1.stable.official [b09f793] macos

[rokuhime]

encountering the same issue on the steam windows v4.2.1.stable.official[b09f793] build for my own project :s
deleted the .godot files to refresh the cache but the issue persisted. project runs fine with the corrupted file

EDIT: After more investigations, I found that from all the opened scenes in my project, the only ones that get corrupted are the ones containing preloaded PackedScenes as const / var in the attached script.

can second this; the only thing that is preloaded in my project is the only scene thats corrupting

[tlobig]

thanks to @isaaccp I just found this issue here, I created almost the same issue #86154

I debugged this as much as I can.

First some workarounds that helped with loading:

• reload by Project -> Reload Project
• if that doesn't help first close all open scenes and/or scripts and try the reload again
• the "corrupted" scene doesn't load because it could not parse an attached script, so comment out the whole script (or any preload statement )and then reload

So, like just said, the underlying reason is that a script failed to parse during load of the scene and then the scene stays corrupted until you reload the project. One specific condition I found to cause this is using the preload statement. preload is followed through while parsing during opening the project. This will fail to parse if the preload in a chain leads back to the scene that's not yet instantiated because currently being loaded. There may be other conditions.

The bad thing about this is that a user will think all their work is ruined even though there are some easy fixes to load the scenes again.

What I already suggested in #86154 is to change the loading in the editor such that scripts are parsed after the scene has been instantiated. The necessary code edits are too far reaching that I don't yet dare creating a pull request, yet.

[goatt1167]

I just had the same problem.

I solve it by:

1. move the file out of the folder.
2. re-open godot editor, it reported file not found error
3. close editor.
4. re-open and move the file back in.

[Quanthon]

I had this issue caused by the "preload" method.
At first, I wrote
var BulletTSCN = preload("res://Bullet/Bullet.tscn")
Then I changed it to
@export var BulletTSCN: PackedScene
Now res://Bullet/Bullet.tscn doesn't crash

[goatt1167]

I just had the same problem.

I solve it by:

1. move the file out of the folder.
2. re-open godot editor, it reported file not found error
3. close editor.
4. re-open and move the file back in.

Never mind. It didn't work when I opened the project today. Redo the steps above will fix the corruption temporarily until the IDE is closed.

But add :ResourceType or :PackedScene has solve my problem for now.

var Card = preload("...") # old buggy code
v
v
var Card:PackedScene = preload("...") # new fix

[tlobig]

Tested with dev snapshot 1 of 4.3 it still prints an error at load, but does fixes the corruption.

[schroederactino]

In my case ... godot 4.2 on Mac renamed the script file attached to my scene from Asteroid.gd to asteroid.gd, after I changed the filename in the tscn it loaded. After a while it changed it back to uppercase. very strange... 2h of frustration because first time I redid the whole scene. And godot physics is so broken I had to use Jolt (good there is an extension)... Godot is disqualifying itself... ;-)

[MinusSevenOfSpades]

I've also encountered this issue. One thing that helps every time is to open all related preload dependencies (mostly scenes) that are included in attached script.

[apples]

Also encountered this issue, it was very annoying to workaround.

In the end though, a simple Project -> Reload Project was the best remedy.

It seems like the scene gets corrupted in-memory, and even poking the .tscn file won't convince the editor to try again.

I do have a few preload lines in my scripts, but not directly in any scripts related to the corrupted scenes.

[PerMalmberg]

I just had the same problem.
I solve it by:

1. move the file out of the folder.
2. re-open godot editor, it reported file not found error
3. close editor.
4. re-open and move the file back in.

Never mind. It didn't work when I opened the project today. Redo the steps above will fix the corruption temporarily until the IDE is closed.

But add :ResourceType or :PackedScene has solve my problem for now.

var Card = preload("...") # old buggy code
v
v
var Card:PackedScene = preload("...") # new fix

Been experiencing this on Windows, Godot 4.2.1, For the last week. Have re-created the scene many times but the issue comes back.

The quoted post solved it for me, i.e. using explicit typing instead of inferred:

var scene := preload("res://test/scene/creeper/creeper.tscn")

becomes this:

var scene:PackedScene = preload("res://test/scene/creeper/creeper.tscn")

So my scene file is fine, there's something happening during the load of the scene. Haven't dared close Godot yet so don't know if it will work long term.

Edit: Reopened Godot, the issue is back :(

This is written in the error log:

Failed to instantiate scene state of "res://test/scene/creeper/creeper.tscn", node count is 0. Make sure the PackedScene resource is valid.

[mizuto]

Ran into the same issue. For me I was preloading the scene the script itself was attached to.
The corruption message went away after changing preload to just load.

[PerMalmberg]

It seems any change to the script and a save/restart "fixes" it, but it comes back after the next restart. The bug has been confirmed so lets hope for a swift resolution.

[tlobig]

Tested with dev snapshot 1 of 4.3 it still prints an error at load, but does fix the corruption.

bug's already fixed, 4.3 just needs to get to a stable release

[thiscris]

Also had this problem (4.2.1 Linux). Following goatt1167's comment made the scene openable again.

It is worth to point out that I had an issue with circular references - the script in the corrupted scene (scene A) was preloading another scene (scene B), but the script in scene B was also preloading scene A.
An oversight and not an intentional design. I think that it could easily happen to other developers without noticing. Maybe this could be checked for and given as a warning when failing to open scenes?

[MrTeacher-tech]

This occurred to me with circular references of attached scripts like thischris mentioned... Once you have one and exit the editor it seems you are prone to the error. To fix it, deleting my .godot folder did not help (all though that seems to help some people).

My solve: I opened the .tscn file in an editor and deleted two lines (found them by searching for (ExtResource):
Line 3: [ext_resource type="Script" path="res://assets/creature.gd" id="1_fxdw2"]

Line 21: script = ExtResource("1_fxdw2")

Keep in mind this removes the attached scripts from the scene.

In the future I will try to avoid circular references with scripts and see if that helps.

[thiscris]

@MrTeacher-tech, if we are talking about circular reference, in theory you should be able to reopen the scene if you comment out the reference in the script file (editing it in an external editor). I haven't tested it.

[mazmystic]

Just had this issue (or at least a very similar one—the script was referencing a custom class, not an preloaded) in my project. (using MacOS). I could recreate the steps that broke it, which may be helpful to fixing this bug.

This was fine:

extends Area2D

var my_variable: Node
[everything else...]

This corrupted the scene file:

extends Area2D

var my_variable: CustomClass
[everything else...]

Things that could be relevant (I don't know that much about the inner workings of Godot):

• The script containing CustomClass (which extends Node2D btw) comes further down the list than this script in the file hierarchy
• my_variable is the first variable in this script
• my_variable is not assigned a value initially in the script

What this whole thing smells like to me is that Godot is trying to parse a script that references a resource before it knows that other resource exists? I suppose that is what circular reference means? I feel like there should be some sort of failsafe, if this is the case.

EDIT: It's definitely a circular reference. I'm realizing now that the CustomClass script has a preloaded instance of the scene that the above script was in.