Duplicated material replaces original on save in MeshInstance3D

[DigitOtter]

Godot version

4.0 beta 2 (also in commit 15a8e17)

System information

Linux (also tested on Windows 10), Vulkan

Issue description

When duplicating a material, MeshInstance3D nodes that have the original material set in surface_material_override will have these materials replaced with the duplicated material when saving and restarting the Godot editor.

Steps to reproduce

• Open a new Godot project in the editor
• Set a 3D main scene
• Create and save a new BaseMaterial3D called mat1.material, set the Albedo to an arbitrary color
• In the FileSystem view of the editor, right-click on mat1.material and select duplicate, name the new material mat2.material
• Change the color of mat2.material
• Create a new MeshInstance3D node in the scene, select a New BoxMesh as its mesh
• From the FileSystem view, drag-and-drop mat1.material onto the new cube. It should have the color in mat1.material
• Save the scene, restart the editor
• Instead of the intended mat1.material, the cube's surface_material_override should now be set to mat2.material

For the attached minimal reproduction project:

• From the FileSystem view, drag-and-drop mat1.material in the materials folder onto the cube in the main scene
• Save the scene, restart the editor
• Instead of the intended mat1.material, the cube's surface_material_override should now be set to mat2.material

Minimal reproduction project

gd-mat-duplicate-master.zip

[Calinou]

Related to #60849.

[alazifk]

As we figured out in #67893:
The problem is that the two materials get the same uid when a material is duplicated. (left click in FileSystem/Copy UID to check).

This does not happen if the material is named *.tres. Which might be by accident.
It seems like the following branch in void FileSystemDock::_try_duplicate_item might be executed:

else if (p_item.is_file && (old_path.get_extension() == "tscn" || old_path.get_extension() == "tres")) {
			// FIXME: Quick hack to fix text resources. This should be fixed properly.
			Ref<FileAccess> file = FileAccess::open(old_path, FileAccess::READ, &err);
			if (err == OK) {
				PackedStringArray lines = file->get_as_utf8_string().split("\n");
				String line = lines[0];

				if (line.contains("uid")) {
					line = line.substr(0, line.find(" uid")) + "]";
					lines.write[0] = line;

					Ref<FileAccess> file2 = FileAccess::open(new_path, FileAccess::WRITE, &err);
					if (err == OK) {
						file2->store_string(String("\n").join(lines));
					}
				}
			}

[Calinou]

This is likely due to the same cause as #54774.

Quoting from that issue:

We've implemented a temporary fix before alpha 2 which covers all the text resources (#55584)

This checks out with your statement that .tres resources behave correctly, but not binary resources.

[PucklaJ]

This issue can probably be closed now due to #66706 being merged

[akien-mga]

Duplicate of #54774