Open Splizard opened 2 years ago
@Splizard Please upload a minimal reproduction project to make this easier to troubleshoot.
Minimal reproduction project 64975.zip
Only a linux.64
shared library file is included, so you will need to build the minimal main.c
file and add it to example.gdextension
in order to debug this on other platforms.
I'm running into this too with XR interfaces implemented in GDExternal. I've updated my reference implementation today so it can be reproduced with that.
This line fails:
XRServer *xr_server = XRServer::get_singleton();
Bit of a showstopper, shame we mist it for the stable release.
Ok, looking into this some more, the problem is due to this: https://github.com/godotengine/godot/blob/master/main/main.cpp#L2315
MAIN_PRINT("Main: Load Physics");
initialize_physics();
initialize_navigation_server();
register_server_singletons();
register_server_singletons
is where the singletons are registered for access by scripts.
This is after: https://github.com/godotengine/godot/blob/master/main/main.cpp#L2309
initialize_modules(MODULE_INITIALIZATION_LEVEL_EDITOR);
Which is the last time we call into the initialization of GDExternals meaning that GDExternals has no way to interact with the server singletons, even though some of them have long since been created.
The solution in @Splizard PR was to introduce a new initialization level, which we definitely don't want to do.
The problem that we have in this is that there have been many discussions over time about the timing of registering our singletons, and reasons for why the timing was changed. These reasons are poorly documented so changing the timing once again may cause other problems to surface.
For my use case, I definitely need access to the XRServer
singleton when we are calling into initialize_modules(MODULE_INITIALIZATION_LEVEL_SERVERS);
as XRInterfaces
need to potentially be registered with the XRServer before our graphics pipeline is setup.
The question here to answer is: What is the reasons all the servers need to be registered together? This is delaying the moment of registering because we don't create, say they physics server until much later, and this is correct. And there is an argument that only registering some servers, will lead to questions by users why the server they need, isn't available. There is something to say for consistency.
The flipside of the argument is that not registering servers as soon as possible after they have been instantiated, makes our initialization levels pretty much useless.
This will need further discussion with the results documented properly once and for all, but seeing the core team is currently preoccupied with GDC, this will likely happen afterwards.
Godot version
v4.0.alpha.custom_build.0c5f25495
System information
Ubuntu 22.04 Vulkan
Issue description
I'm writing a set of GDExtension/GDNative Go bindings and attempting to load all of the global singletons. I have tried loading them both at level 3 initialization time (
GDNATIVE_INITIALIZATION_EDITOR
) and/or when_ready
is called on a extension class. A select number of them fail to load and while I expected that Javascript and JavaClassWrapper fail because they require certain environments. I did not expect the Server types to fail.I might add that calling
Engine.get_singleton("DisplayServer")
for example, does work from GDScript. Is there something special about these 'Server' singletons? How is the initialization for these singletons meant to work from GDExtension?Steps to reproduce
Call
global_get_singleton
on aGDNativeInterface
with any of the failing cases shown in the Issue Description.Example