EditorExportPlugin: Call _export_file for all resource types
#93878
Conversation
|
I've tested this with all the scenarios I can think of... It seems that remapping imported resources in the Testing is very welcome, of course! |
|
Has #90365 really been reverted? Can you link the PR reverting it? It hasn't been marked as reverted or linked in any revert PR Edit: Or do you mean that this reverts that PR? |
Yes, I meant that this PR reverts that other PR. I’ve updated the PR comment to have more clear wording about this. |
This reverts commit 398892c.
allenwp
force-pushed
the
EditorExportPlugin_export_file_90365
branch
from
02e08c7
to
460e486
Compare
allenwp
force-pushed
the
EditorExportPlugin_export_file_90365
branch
from
65fc19b
to
f3f4a7d
Compare
allenwp
changed the title
EditorExportPlugin: _export_file is called for all resource typesEditorExportPlugin: Call _export_file for all resource types
- Alternate fix to godotengine#67844 that calls `_export_file` for all resource types instead of implementing `skip()` for customize functions. - Fixes godotengine#93823. - Moved logic surrounding "Skip" and "Keep" imported files to happen before resource customization. Fixes godotengine#93825. - Also fixes an issue that I suspect might exist where progress bars during export were incorrect due to imported files in the project that are configured as "Keep" or "Skip".
allenwp
force-pushed
the
EditorExportPlugin_export_file_90365
branch
from
f3f4a7d
to
8e65966
Compare
|
I've left the commit that reverts the 4.3 beta 2 approach as a separate commit. Please let me know if I should squash this to be a part of my commit or if it would be better for a maintainer to revert it separate from my PR (not sure what the best practice is for Godot). |
|
Thanks! |
_export_filefor all resource types instead of implementingskip()for customize functions.EditorExportPlugin: Skipping a scene in_customize_scenegives error message #93823.EditorExportPlugin: Error when customizing "Keep File" resources #93825.If this PR is merged, it supersedes #93820 because that PR is based on the other previous fix that is reverted by this PR.
I'm currently keeping this in draft with separate commits for the purpose of review. I can switch this over to a final pull request and squash the commits into one when others have had a moment to look at the changes. (Or leave some as separate, like the revert for example. Not sure what the preferred practice would be.)