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
Fix plugin script classes defined even if inactive. #32434
Fix plugin script classes defined even if inactive. #32434
Conversation
Related: #31401 (comment) |
This effectively implements that comment @aaronfranke. It's the EditorFileSystem changes that filter plugin-based script classes out of the registration process (which is what everything else, including CreateDialog, bases its script class awareness off of). |
editor/editor_file_system.cpp
Outdated
@@ -1411,6 +1411,9 @@ String EditorFileSystem::_get_global_script_class(const String &p_type, const St | |||
} | |||
|
|||
void EditorFileSystem::_scan_script_classes(EditorFileSystemDirectory *p_dir) { | |||
if (p_dir->parent && p_dir->parent->name == "addons" && EditorNode::get_singleton()->is_addon_plugin_enabled(p_dir->name)) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
You said you're filtering out inactive plugins, but doesn't this filter out enabled plugins?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@akien-mga Whoops. You're right. It was previously two separate if statements (when I tested it), and when I refactored it to one I forgot the exclamation point. Nice catch. Fixed now.
2f36f28
to
168f6cd
Compare
Could be a starting point for https://github.com/godotengine/godot/issues/19178#issuecomment-471099148 ? |
Thanks! |
@willnationsdev This PR prevented VisualShaderNodeCustom's to be loaded from addon subdirs. Can you make a fix PR ? |
@Chaosus I'm confused. Do they use the script class system? And shouldn't they be blocked from being used anyway unless their relevant addon has been enabled? Edit: the only change I made was in the |
They are not connected to plugin system but registered through class_names. |
@Chaosus So, what would be the best fix for this then? Should I just add an exception to a specific type of resource? |
I dont know - they are used standart *.gd extension so need to check if they are derived from VisualShaderNodeCustom anyways. |
@Chaosus Ahh, ok. So it could be any type of script, so long as the base native class is VisualShaderNodeCustom. |
Yeah |
@akien-mga I would just revert this commit for now. I'm trying to break down a good "fix" for this, except that you either do or don't want an addon's script classes to be registered by Godot. And if the addon doesn't provide a plugin, then there is no interface in the ProjectSettings by which to mark the addon as active/inactive (because it marks plugins, not addons). Better to let them all through for now until we update the GUI to be able to toggle script classes contained in addons that don't have plugins. |
Might also make sense to put these kinds of changes on the 4.0 milestone and do them alongside an overhaul to the addon/script class system as discussed in godotengine/godot-proposals#22 |
Alright, reverted as discussed above. |
Currently, script classes will always be registered no matter where they are defined in a project. This change correctly filters out scripts from being registered if they are in a plugin's subdirectory and if that plugin is inactive.