Fix overriding _export_begin
, _export_file
and _export_end
from GDExtension
#80999
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Fixes #80593
In
EditorExportPlatform
, it's explicitly checking for a script before calling these virtual methods onEditorExportPlugin
, which prevents them from working correctly when implemented from GDExtension (rather than script).This PR changes the code to instead check using
GDVIRTUAL_IS_OVERRIDDEN_PTR()
which will check for both script or GDExtension implementations.Another (possibly better) way this could have been implemented is by making the default implementations of the virtual
_export_begin()
etc functions doGDVIRTUAL_CALL()
(calling into script or GDExtension), allowing the C++EditorExportPlugin
s to override those with custom implementations. It's done this way in a number of other classes. However, when I tried to implement it, there were issues with the fact that the in-engine classes takeHashSet<String> p_features
whereas the script/GDExtension versions takePackedStringArray
, and this would have been recreating thePackedStringArray
a lot more times than the current structure. If we changed the in-engine C++ API to takePackedStringArray
instead, this would not be a problem!But for now I've gone with the simpler approach.
NOTE: Currently marked as a draft, because I haven't actually tested it yet! The issue doesn't have an MRP, and there's a bunch of setup to test, but I will do it as soon as I can.