-
-
Notifications
You must be signed in to change notification settings - Fork 21.6k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Using other scripts by their class_name in an import plugin causes import to fail #81615
Comments
After restarting the editor (with filled As far as I remember, @KoBeWi previously fixed a similar bug with incorrect initialization order. |
Yes. If instead of completely wiping In my case, import is failing in CICD where it builds from clean every time, so it's not like I can just avoid deleting that file. |
I am on v4.2.beta3.official [e8d57af] and developing plugins and this is still happening. I now regularly 'rm -fr .godot' in order to see what will happen. The only way I have found to stop the errors is to resort to the const preload thing. Using class_name is fragile. Even starting the project twice does not negate all the parse errors caused by class_name references. |
Looking at this briefly (but be aware I have little experience with the Godot source), it looks like the problem is that _enter_tree() is being invoked before the global class cache is populated. This is logging from a run with extra debug print_line():
I'll try to see why the ordering is like this and whether it can be changed without breaking something else. |
Import plugins needs to be loaded early to import assets during the first filesystem scan. If you want to change order, the global class list loading should be moved earlier. |
Makes sense. From the stack trace, it looks like as of now there is nothing explicitly initializing the global class cache. It just happens to be written the first time a resource is saved as a side-effect. I'll see if it's possible to trigger the write explicitly before SceneTree::initialize() runs or at least before it invokes _set_tree(). |
Looking at editor_node.cpp there is already an attempt to retry loading addons that fail to load after waiting for the initial file scan, but it doesn't seem to be working for this case. (Note that this still would cause issues for import plugins even if it was working, so probably still would be worth fixing some other way). Going through it with the debugger, it looks like despite all the errors thrown out, this check passes:
with get_instance_base_type() returning EditorPlugin as expected. "Errors in the script cause the base_type to be an empty StringName." seems to not be true in this case, likely because the errors are coming from the attempt to preload("import_plugin.gd"), not from "plugin.gd" itself. As a result, the plugin is considered loaded and not added to pending_addons. When later, in add_editor_plugin, we try to add this to the tree using add_child(), it fails with:
because preloading import_plugin.gd fails. I am not sure if there is some way to detect those errors thrown by the file being preloaded. As mentioned above, even if we fixed this, this would still cause problems for import plugins as far as I can tell, so maybe the proper order would be: I am new to the godot editor so I am not sure if that order has other problems :) (some screenshots for extra info) |
It looks like when we load a script, we still consider it loaded even if there are parsing errors: godot/modules/gdscript/gdscript.cpp Line 2790 in 80de898
I think in order to work around that, the check in Line 3434 in 80de898
checks for whether get_instance_base_type() is not empty, assuming that if there is a parse error in the plugin script, it won't be set. The problem is that in this case the error is not in the plugin itself but in the script that it preloads, and thus despite the error (which shows up as a COMPILATION_ERROR within the gdscript loader), get_instance_base_type() is set to EditorPlugin, causing this problem. |
Godot version
4.1.1-stable
System information
Godot v4.1.1.stable (fabd7c89d) - Arch Linux #1 SMP PREEMPT_DYNAMIC Sat, 10 Jun 2023 00:35:35 +0000 - Vulkan (Forward+) - dedicated NVIDIA GeForce GTX 970 (nvidia; 530.41.03) - AMD Ryzen 5 2600 Six-Core Processor (12 Threads)
Issue description
I have been encountering a strange issue where builds of my project created and exported from a fresh clone of the repo are missing their translations. I've narrowed this down to a weird quirk of import plugin scripts (my project uses a custom editor plugin to import translations). It seems as though global script class names don't exist during the initial import.
The reproducer project contains a CSV file
translations/example.csv
and its corresponding .import set up to be imported using the "Translation Plus" plugin.If the two lines at the top of
addons/translation_plus/import_plugin.gd
that shadow the global class namesTranslationSet
andTranslationPlus
are commented out, and the project's hidden .godot directory is removed, then the next time the project is opened, importing example.csv fails.Steps to reproduce
translation/example.csv
is imported asTranslation Plus
.addons/translation_plus/import_plugin.gd
CSV Translation
. Errors are logged:Minimal reproduction project
csv-import-plugin.zip
The text was updated successfully, but these errors were encountered: