Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Does this work with Godot 4 alpha / nightly? #19

Open
komerdoor opened this issue Feb 27, 2022 · 9 comments
Open

Does this work with Godot 4 alpha / nightly? #19

komerdoor opened this issue Feb 27, 2022 · 9 comments

Comments

@komerdoor
Copy link

Will this work with Godot 4 as I am already moving some of my code to it. I could not find any information on that.

@gilzoide
Copy link
Owner

Hi! Well, not yet, no =/

Godot 4 deprecates the GDNative API in favor of the GDExtension API, which right now does not support registering new scripting languages, which is exactly what this plugin does as a PluginScript.

There is a proposal for getting this functionality into Godot 4, which explains very well the missing API for registering new languages (godotengine/godot-proposals#3927).

I really want to have Lua PluginScript support Godot 4, but it will take some time until there is actual support for doing it, then some more time implementing the new interface and porting code to use the GDExtension API.

@Calandiel
Copy link

lt looks like the mentioned proposal was already implemented. Did they provide all necessary functionalities for lua?

@gilzoide
Copy link
Owner

Did they provide all necessary functionalities for lua?

As far as I looked into it, yes it did. Although last time I checked this addition was not in godot-headers yet.

@hendursaga
Copy link

Although last time I checked this addition was not in godot-headers yet.

Is it in now? Any updates on this?

@Calandiel
Copy link

Although last time I checked this addition was not in godot-headers yet.

Is it in now? Any updates on this?

Not exactly on topic, but a potential temporary workaround is simply calling lua.dll (or luajit.dll) from C# with native interop or using MoonSharp. Though, that'd of course require the build of the engine with C# support as I don't think GDScript has such capabilities.

@gilzoide
Copy link
Owner

gilzoide commented Jan 5, 2023

Hi @hendursaga. Yes, the scripting instance extension API is in godot-headers, probably for a long time now.
It should be possible to implement Godot 4.0 support, but I haven't looked into it yet. Like, at all.

@gilzoide
Copy link
Owner

gilzoide commented Jan 5, 2023

Not exactly on topic, but a potential temporary workaround is simply calling lua.dll (or luajit.dll) from C# with native interop or using MoonSharp.

Well, yeah, that's actually a nice way to use Lua in Godot. But it would not be a way to implement Godot objects directly in Lua, which is the point of PluginScripts/Script Language GDExtension.

Using MoonSharp or calling the Lua API directly from the DLL would be more like using Trey2k/lua. Which is totally fine, depending of what you're using Lua for. They're 2 different ways of using Lua, serving potentially different purposes.

@Calandiel
Copy link

Not exactly on topic, but a potential temporary workaround is simply calling lua.dll (or luajit.dll) from C# with native interop or using MoonSharp.

Well, yeah, that's actually a nice way to use Lua in Godot. But it would not be a way to implement Godot objects directly in Lua, which is the point of PluginScripts/Script Language GDExtension.

Using MoonSharp or calling the Lua API directly from the DLL would be more like using Trey2k/lua. Which is totally fine, depending of what you're using Lua for. They're 2 different ways of using Lua, serving potentially different purposes.

Indeed, hence only a potential workaround ^^ Your plugin definitely does a lot more than what lua's dll does by itself.

@gilzoide
Copy link
Owner

gilzoide commented Jan 7, 2023

FYI, I was looking into how porting the PluginScript to GDExtensions would go.
The binding of variants (Godot structures like Vector2, Array and Object) seems to be quite simpler in GDExtensions than in GDNative, but creating a new language needs the implementation of a subclass of ScriptLanguageExtension, which is not very nice using the raw C API.

Thus I'm thinking of a different approach for implementing Lua support in GDExtensions: instead of using LuaJIT's FFI for the whole implementation, we can generate Lua/C bindings for Variants based on the extension_api.json file and possibly use godot-cpp to implement the ScriptLanguageExtension subclass. Later on, if at all, we can generate FFI-based bindings for better JIT support in LuaJIT.

Pros:

  • Support for PUC Lua and other implementations. Maybe even web support with some WebAssembly implementation of Lua, who knows?
  • Decoupling the Lua <-> Godot bindings from PluginScript / ScriptLanguageExtension.
    This would make it easy enough to create WeaselGames/lua-like functionality using the same code.
    Not everybody that uses Lua in Godot needs the whole new scripting language stuff, an extension class that exposes Lua VMs might be enough for lots of cases.

Cons:

  • Major rewrite 🤦

If anybody has more ideas on the subject, please feel free to bring them to the table! =D

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants