Update GDScriptLanguage::globals when a GDExtension is loaded in exported builds#105319
Update GDScriptLanguage::globals when a GDExtension is loaded in exported builds#105319ze2j wants to merge 1 commit intogodotengine:masterfrom
GDScriptLanguage::globals when a GDExtension is loaded in exported builds#105319Conversation
|
The EDIT: documentation updated |
ze2j
force-pushed
the
fix_gdscript_bug_with_gdextension_types
branch
from
b18c6a7 to
7af58c0
Compare
AThousandShips
added
bug
topic:gdscript
cherrypick:4.3
ze2j
changed the title
GDScriptLanguage::globals when a GDExtension is loaded in exported builds
Repiteo
added
the
cherrypick:4.5
| GDExtensionManager::get_singleton()->connect("extension_loaded", callable_mp(this, &GDScriptLanguage::_extension_loaded)); | ||
| GDExtensionManager::get_singleton()->connect("extension_unloading", callable_mp(this, &GDScriptLanguage::_extension_unloading)); |
There was a problem hiding this comment.
These signals are best disconnected in GDScriptLanguage::finish() to prevent spam in unit tests (godot --test).
There was a problem hiding this comment.
Thanks! I added the disconnections as requested.
|
Just to clearify: In exported games are extensions expected to be unloadable? |
ze2j
force-pushed
the
fix_gdscript_bug_with_gdextension_types
branch
from
7af58c0 to
f9ced2b
Compare
|
@HolonProduction I don't know in the general case, but in this particular case nothing prevents it AFAIK. TBH I never tried to unload a GDExtension from an exported game. This may deserve some additional tests to ensure it works, otherwise I would have to revert the unloading part of this PR. |
dsnopek
left a comment
dsnopek
left a comment
There was a problem hiding this comment.
The GDExtension parts of this seem fine to me. I can't speak to the GDScript parts
|
I still think it's important to know whether extension unloading is supported. |
Loading and unloading extensions at runtime should work. And, in fact, is a requirement for implementing #97991, however, that doesn't need to work in release builds. I would expect that needing to unload a GDExtension in a release build to be very uncommon. |
|
Then this should use named globals IMO. |
6 participants
Fix 104056
The root cause of the issue is that the
GDScriptLanguage::globalsis not updated when a newGDExtensionis loaded in an exported game. This leads to a GDScript compilation failure when the types defined by theGDExtensionare used explicitly in.gdscripts loaded from a pck file (such as a mod).The logic to handle this already exists (added in 93972) but is currently enabled only on editor builds. My proposed fix is to remove that constraint so it also applies to exported builds. I haven’t noticed any side effects, but I’m not very familiar with this part of the engine, so let me know if this isn’t the right approach.