Editor needs to gracefully handle files being renamed or moved outside of the editor

[blackears]

I've been developing an addon for Godot and am running into huge problems whenever I try to move files outside of the Godot editor. If I simply move files to a different directory or rename them and then try to open the project in Godot again, I get a ton of error messages about the files either not being findable or being duplicates of other files. This is effectively preventing me from using branching and merging with git. Even just moving a group of files into a new folder for organization causes my project to be unusable.

If I copy and paste the code into a new project and load that, it works fine. But my old repository has a ton of errors and I can't figure out a way to just tell the editor to forget everything it has cached and start new. One person suggested disabling and reenabling the plugin, but that didn't fix anything. In the short term I need a work around so that I can use my repository again.

Attached is a simple project where I created an addon and also created a file named Foo.gd in the root directory. I gave Foo.gd the class_name Foo and create a new instance of it in the addon's main object. At this point the addon was working, even if I closed and reloaded Godot. Then I closed Godot and created a subdirectory called subdir and moved Foo.gd into it using Windows Explorer. When I next loaded the project in Godot I got the errors

res://addons/testplugin/testplugin.gd:4 - Parse Error: Could not parse global class "Foo" from "res://addons/testplugin/Foo.gd". res://addons/testplugin/testplugin.gd:7 - Parse Error: Could not find script for class "Foo". Attempt to open script 'res://addons/testplugin/Foo.gd' resulted in error 'File not found'. res://addons/testplugin/testplugin.gd:-1 - Compile Error:

While I think this is a bug that needs to be fixed, in the short term I just need a workaround so I can make my repository usable again. Is there a way to do this?

AddonMoveFiles.zip

[theraot]

Note that the attached zip does not include the .godot folder, as a result I get the error messages on the first load, but Godot regenerates the .godot folder and works correctly, despite having shown the error messages.

There were no subsequent error messages reloading the project, disabling and enabling the plugin, nor adding an scene and running it. Furthermore, I tried moving the file around both while Godot was running and while it wasn't, and Godot got the changes correctly.

I also tried introducing a parse error in the file, closing Godot, moving the file, and opening Godot again (which failed to enable the plugin, of course), and fixing the parse error in Godot, and enabling the plugin. Despite the spill of error messages it worked correctly.

I have been unable to find a situation where the error messages don't go away. So, I believe Godot is being eager in showing these error messages despite being able to recover correctly.

---

Anyway, I suppose there might be a situation where forcing to regenerate the cache is necessary. I just have been unable to find it. So know that the cache for the list of classes is in .godot/global_script_class_cache.cfg and you could edit with any text editor if it comes to it... Or remove it and have Godot regenerate it. That might be the solution for your old project.

[theraot]

OK, I managed to get the issue to happen on one of my projects. In this case I moved a script that is referenced in a scene (attached to one of the nodes). And, you know, I thought ids would fix that. Apparently Godot saved the script again creating a duplicate. Removing the script made it work, but turns out Godot saved the script inside the scene file instead of looking for the file elsewhere. Again, I would have expected ids would fix that.

Addendum: The solution was to attach the correct script.

[theraot]

I have become convinced ids are just not reliable enough for this task. This is how:

I have a scene with a child node with a script attached. Saved. I take note of the id Godot generated. I remove the node and reload the project. Then I add a new node with the same script, and take note of the id that Godot generated. The ids are different. And this is the same machine. In fact, I didn't find a persisted cache of id to path. Adding such cache would be one more thing that can go out of sync anyway.

So in the situation where we are merging changes made in different machines at different times, we cannot trust ids to match.

Because of this I would propose to use the class name as fallback when available. This means adding the class name to the scene files where the script is referenced, and when the script is not found at the path saved in the scene file look for a script matching the class name and use that - yes, I think this should take precedence over the id.

[blackears]

Here is the project with the .godot file. I left it out because your submission process for regular issues requests that you do so.

AddonMoveFiles.zip

[blackears]

@theraot I'm not quite sure from your post how you used a class name to resolve an issue. I've been naming all my classes and even use class inheritance in a few places - I have a background in C++ and C# and like to use those features.

The uv_editor_viewport.gd is a control and not one of the files I was trying to move. I can see how moving that would have caused a problem since it is referenced by a scene node. Most of the files I moved are not referenced that way. And in any case, after I reverted everything they should have been back in their old spot. (The files I was moving were in /actions, /commands and /tools which provide the functionality of the addon). Some were deleted instead of moved. While I would have expected some errors, my first repo is now completely locked by them no matter how many times I reload. And deleting the .godot folder does not change anything.

[theraot]

@blackears My idea is to modify the way Godot saves the references to the scripts in the resource files (including scene files) to include the class name, and when the file is not found try to find it by class name (as I was saying here: #6907 (comment)). Godot does not currently do what I'm saying. I need to write either an issue or proposal, probably both, and then make a pull request. I'm looking at existing related issues and proposals first.

Looking at the files you mention, the ones on /actions and /commands appear to be only referenced by class name, but there are files in /tools that are referenced in resource files (the ones in /data/tool_tags). Regenerating the .godot folder won't fix those. I'm guessing these are the issue, and also that the change I have in mind would address them too.

[theraot]

@blackears Anyway, for your fix before any changes to Godot, you would have to find the problematic references and fix them.

[blackears]

@theraot There aren't any problematic references because everything has been reverted to it's original state. All the references should be valid (though I still get errors when I load). But your proposal does sound like a good one and I hope it fixes the issue.

[theraot]

@blackears Well, I don't know. I don't see anything wrong with the paths. They are using "/", and fully in lower case. No special characters, or names that would work on one OS but not the other. Plus you say you have reverted the changes and removing the .godot folder does not fix it. So no idea.

Anyway, I found that "Edit dependencies..." -> "Fix Broken" fixes the problem I was describing. Which also means the issue is that Godot is not prompting the user to do that. So I opened an issue about it.

[blackears]

I've tried deleting the .godot file before, but that does not solve the problem for me. Perhaps this is a Windows specific issue? Anyhow, in this run I renamed .godot to .godot_ so the editor wouldn't find it and reloaded my scene. I'm still getting errors:

AddonMoveFiles.zip