Packed scene files sometimes get "corrupted" when moving files within editor

[trollusk]

Godot version

4.0.3

System information

Windows 11

Issue description

I reorganised a project by dragging some files (various types including .tscn, .tres, .gd, images) into subdirectories within the project's filetree. This was all done within the editor.

After doing this I found two scene files would not open, giving the alarming popup message "scene file is invalid/corrupt".

After panicked googling and deleting the .godot directory (which did not fix the problem), I found that the problem was that scene A (the scene named in the message) contained an instance of scene B, and in scene B's .tscn file, the root node had been saved with a name but no type, i.e. instead of the line in the .tscn file saying:

[node name="PlayerScene" type="ActorScene" groups=["players"]]

It said:

[node name="PlayerScene"]

So Godot seems to have "lost" the root node's type when moving the scene file. Manually typing in the missing info enabled the file to load. The other "corrupt" scene depended on this scene, so it now loaded as well.

This seems like a really serious bug, as it means Godot's management of the project filetree is untrustworthy. It's worsened by the fact that the message produced by the editor is so opaque and unhelpful. It doesn't even identify the file causing the problem (scene B).

Steps to reproduce

Not sure but I think it would involve having a scene that contains child nodes which are instances of other scenes, then moving the .tscn files to other directories.

Minimal reproduction project

N/A

[Calinou]

Can you reproduce this on 3.5.2?

[djrain]

I also got a corrupt scene today after moving files in the editor (4.0.3 RC1), likely same issue but not sure. I believe I had one of the relevant scenes open while doing the move, and I got a glitched popup with some pinkish background but no visible text. Next time I opened that scene it was corrupt. Fixed it with version control because I couldn't tell what was wrong with the file.

[Zoomulator]

I got a corrupted tscn file yesterday as well, using 4.0.3. It was regarding an inherited scene, but I can't recall if it was the base or the derived scene that lost the type attribute. Happened after moving some files too.

I quickly found the problem since I'm using git and could just do a diff to spot the corruption, so I fixed it and went on with what I was doing and forgot about it 😅 I'll take better note if it happens again.

[bertodelrio256]

this happended to me today, moved a scene and all its materials to another folder in the editor and now the scene is corrupted. v4.0.3.stable.mono.official [5222a99]

[lenonk]

This just bit me as well using 4.1.1.stable.mono. In my experience it only happens when you move an inherited scene.

[svdragster]

Steps to reproduce in 4.1.1:

1. Create new scene a.tscn
2. Create new inherited scene a_inherited.tscn (rightclick a.tscn, "New Inherited Scene")
3. Close both scenes
4. Create directory
5. Move a.tscn into subdirectory
6. Move a_inherited.tscn into subdirectory
7. When opening a_inherited.tscn, a message will appear that the scene is corrupted.

a_inherited.tscn before move

[gd_scene load_steps=2 format=3 uid="uid://bxeqxduc17tid"]

[ext_resource type="PackedScene" uid="uid://bmq63y5aqfrxo" path="res://a.tscn" id="1_6fl5w"]

[node name="a" instance=ExtResource("1_6fl5w")]

a_inherited.tscn after move

[gd_scene format=3 uid="uid://bxeqxduc17tid"]

[node name="a"]

When you move both files at the same time, Godot will crash (#79850)

[Rindbee]

It seems to be due to the timing of saving the scene. Therefore, to reproduce this issue, it is necessary to ensure that the inherited scene is opened.

godot/editor/filesystem_dock.cpp

Lines 1877 to 1897 in c495eb5

	if (old_path != new_path) {
	_try_move_item(to_move[i], new_path, file_renames, folder_renames);
	is_moved = true;
	}
	}
	if (is_moved) {
	int current_tab = EditorNode::get_singleton()->get_current_tab();
	_save_scenes_after_move(file_renames); // Save scenes before updating.
	_update_dependencies_after_move(file_renames);
	_update_resource_paths_after_move(file_renames);
	_update_project_settings_after_move(file_renames);
	_update_favorites_list_after_move(file_renames, folder_renames);
	EditorNode::get_singleton()->set_current_tab(current_tab);
	print_verbose("FileSystem: calling rescan.");
	_rescan();
	print_verbose("FileSystem: saving moved scenes.");
	_save_scenes_after_move(file_renames);

There are two _save_scenes_after_move(file_renames) calls, the purpose of the first one (L1885) is to save the modifications of the scene before moving (In order not to lose modifications when reload_scene()). This should happen before scene files movement occurs (L1878), as the paths cached in node are not fully updated, especially those dependencies.

I'm not sure about the purpose of the second call (L1897). If it is necessary, then save_scene_list() should be a deferred call to ensure that saving happens after reload_scene().

godot/editor/filesystem_dock.cpp

Line 1534 in c495eb5

callable_mp(EditorNode::get_singleton(), &EditorNode::reload_scene).bind(file).call_deferred();

godot/editor/filesystem_dock.cpp

Line 1625 in c495eb5

EditorNode::get_singleton()->save_scene_list(new_filenames);

[Rindbee]

Moving the directory may result in the path not being updated.

Peek.2023-09-16.07-22.mp4

[ameliaIsNotDefined]

Thank you so much. I've been looking around for answers and this was by far the most useful. Saved me a tonne of pain of remaking the scene(s)

[Ahren-with-an-h]

I just encountered this in 4.2.1.
I moved a scene and it's two inherited scenes to a new folder in the editor. The program crashed and it corrupted all of them. When I remade one of them and opened it and the original in vscode I could see the corrupted one was missing this line:
[ext_resource type="PackedScene" uid="uid://ddf87wu2brttt" path="res://collectables/collectable.tscn" id="1_flveo"]

And the second half of this line:
[node name="Lifepot" instance=ExtResource("1_flveo")]

When I updated the original with the above it mostly fixed it. I had to redo the sprite to get it to show up when used in a tilemap.