Does this work with Godot 4 alpha / nightly?

[komerdoor]

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]

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 (https://github.com/godotengine/godot-proposals/issues/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]

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

[gilzoide]

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]

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

Is it in now? Any updates on this?

[Calandiel]

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]

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]

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]

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]

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