godotengine
Add enabled module names to the list of supported features for the project manager
This PR enhances the project feature warning system in the project manager by listing all enabled modules as supported features. This allows people to manually list required modules in their projects, and does not require Godot to know about those modules at all - Godot only knows that the project asks for XYZ and it's missing.
As an example, I tested a project with this text in project.godot:
config/features=PackedStringArray("4.0", "GDScript", "WebP", "WebXR", "Voxel")
And this is what shows up in the project manager of Godot compiled with WebXR disabled:
4.0, GDScript, and WebP are all supported, so they are not warned about. WebXR is disabled, and Voxel is not present, so they're not in the supported features list, and the project manager warns about them.
Should the warning test in the project text have a "Missing modules:" prefix (or "Missing:" if there isn't enough space)?
@Calinou The system doesn't make the distinction of whether a feature is a module or not. It's purposefully simple, just a list of strings. The strings can be modules, or they could be other features, or engine versions.
The code for this is mostly simple, but it does require adding a new method to each module's config.py. We could use the folder names, but since these names are displayed to the user, I think nicer names are better.
I would use the folder name to keep it simple, and pass it through EditorPropertyNamesProcessor for prettification.
@akien-mga I just tried this, I added this one line to call process_name and it crashes instantly.
EditorPropertyNameProcessor::get_singleton()->process_name(s, EditorPropertyNameProcessor::Style::STYLE_CAPITALIZED);
================================================================
handle_crash: Program crashed with signal 11
Engine version: Godot Engine v4.0.alpha.custom_build (29d19240aa4d39680741b4a167f12dd20f2ff10a)
Dumping the backtrace. Please include this when reporting the bug on: https://github.com/godotengine/godot/issues
[1] 1 libsystem_platform.dylib 0x00000001a6b874a4 _sigtramp + 56
[2] HashMap<String, String, HashMapHasherDefault, HashMapComparatorDefault<String>, DefaultTypedAllocator<HashMapElement<String, String> > >::find(String const&) (in godot.osx.tools.arm64) (hash_map.h:467)
[3] HashMap<String, String, HashMapHasherDefault, HashMapComparatorDefault<String>, DefaultTypedAllocator<HashMapElement<String, String> > >::find(String const&) (in godot.osx.tools.arm64) (hash_map.h:467)
[4] EditorPropertyNameProcessor::_capitalize_name(String const&) const (in godot.osx.tools.arm64) (editor_property_name_processor.cpp:60)
[5] EditorPropertyNameProcessor::process_name(String const&, EditorPropertyNameProcessor::Style) const (in godot.osx.tools.arm64) (editor_property_name_processor.cpp:87)
[6] ProjectSettings::_get_supported_features() (in godot.osx.tools.arm64) (project_settings.cpp:99)
Specifically, it crashes in capitalize_string_cache.find(p_name); in _capitalize_name.
Branch with slightly more extensive changes: https://github.com/aaronfranke/godot/tree/module-names-wip
EditorPropertyNameProcessor is a node singleton initialized in EditorNode. So get_singleton() returns null here, thus the crash.
I think you can create the node and add it to ProjectManager like in EditorNode:
https://github.com/godotengine/godot/blob/168ee3e6c406dcb0c87454a05a9f2b863027ccaa/editor/editor_node.cpp#L5892-L5894
How is this supposed to be used? The module names are not added automatically in project.godot, so if you open a project and add a module-specific node, the feature list won't inform you about that.
@KoBeWi For now the intended usage is to manually add them to project.godot with a text editor. Not the best, but better than nothing.
The use case is mostly meant for custom modules, but it applies if projects want to warn about requiring built-in ones for users running minimal builds. Thus why I allowed each module to supply its own text in the initial version of this PR - EditorPropertyNameProcessor doesn't know about custom modules.
For now the intended usage is to manually add them to project.godot with a text editor. Not the best, but better than nothing.
That's pretty much as good as nothing if the feature is not even documented anywhere. How users are supposed to know that this exists or how to use it?
I'm closing this PR because it's not important enough, it's incomplete (as good as nothing since there's no GUI for editing this list), and there is disagreement on the implementation. This would be good to salvage if anyone wants to come back to it with a more complete workflow in mind (manually editing project.godot was my workflow).
This would be good to salvage if anyone wants to come back to it with a more complete workflow in mind (manually editing project.godot was my workflow).
tbh even a button to copy the current features to project.godot would be enough, placed somewhere that isn't very obscure.