Access to ScriptServer

[Kehom]

Godot version

4.3 beta 2

godot-cpp version

master

System information

Windows 10 and Linux Mint

Issue description

If implementing a module, we can include the script_language.h file then access ScriptServer. However this is not exposed to GDExtension. I don't know if there is a reason for that.

That said, there are a few things that are very useful. Of particular interest to me is querying if a scripted class inherits from a specific base. I know that we can manually do that by first obtaining the list of "global classes" (ProjectSettings::get_singleton()->get_global_class_list(). However this option means that we always have to iterate through the list of classes. Caching the data might result in outdated data. From my understanding ScriptServer is always updated whenever a scripted (global) class is created or removed.

I understand if not exposing ScriptServer is actually desired.

Steps to reproduce

Minimal reproduction project

[AThousandShips]

Feature proposals are tracked here, this is for bugs. Please open a proposal instead.

[Kehom]

Err.. Quite frankly I didn't know if it was exactly a bug or a feature proposal because we can include script_language.hpp, albeit the class in there only contains the ScriptNameCasing enum.

That said, sorry if this was indeed meant to be a feature proposal.

[AThousandShips]

I think it's intentional to give access to the relevant code, but let's see what the feedback is, my bad!

[dsnopek]

Whether or not to expose ScriptServer the usual way is more a question for whoever is responsible for the Scripting API, rather than something for the GDExtension team to decide.

However, it does appear as though ScriptServer is not exposed the normal way on purpose: if it were, then GDScript (or other scripting languages) could interact with it, which seems undesirable.

So, assuming we don't want to expose it in the normal way, we could add some new functions to gdextension_interface.h in order to access it, and then in godot-cpp make a wrapper class that mimicks the API of ScriptServer?

[Kehom]

I do believe ScriptServer should not be exposed to GDScript. That said, since the intention of GDExtension is to have parity with Modules, then I do believe we need some sort of access to that server. So indeed, not exactly the "normal way".

[aloiscochard]

It would be very useful to be able to use ScriptServer from a GDExtension, for example it would allow something like luascript to be installable as an add-on from the asset store as opposed to having to build the engine from source.

That's a pretty big deal in my humble opinion.

[dsnopek]

@aloiscochard It's definitely possible to add scripting languages to Godot via a GDExtension, that doesn't require access to ScriptServer. I'm not sure why the luascript project you linked to is implemented as a module rather than a GDExtension - if there are technical limitations they encountered, I'd be very curious to learn what they are!

[aloiscochard]

@dsnopek I don't know for luascript project as I was really using it as an example to integrate my own scripting language.

I thought I need to access ScriptServer to do those operations: https://github.com/perbone/luascript/blob/master/register_types.cpp#L55-L56

How to register a new file extension and it's handler without access to ScriptServer? If you know of a project doing this already I'll be very happy to dive in there and find the answer myself.

Thanks for your help!

[dsnopek]

@aloiscochard

How to register a new file extension and it's handler without access to ScriptServer? If you know of a project doing this already I'll be very happy to dive in there and find the answer myself.

This is a test project adding Gravity script support that I use for testing the ability to registry scripting languages, but it's very incomplete:

https://gitlab.com/snopek-games/godot-gravity-lang

And the Luau GDExtension is a full extension that adds support for the Luau scripting language:

https://github.com/Fumohouse/godot-luau-script