Question: LuaStates for Modding

[Acanixz]

Hi, I’ve been exploring modding in Godot using LuaStates, and I have a couple of questions.

• When executing code via a LuaState (for example, using lua.do_string), am I correct that the code is treated as a Lua table rather than a full Godot script? I noticed it can’t use Godot-specific keywords like export or signal.
• When I load instanced scenes that reference .lua files, do those scripts automatically have access to all Lua/Godot libraries, or is their environment limited in any way?

I'm trying to create a game with moddable characters, but I’m still figuring out how to attach character and weapon scripts without risking OS access or other risky GDScript libraries.

[gilzoide]

Hey @Acanixz, thanks for the question.

When executing code via a LuaState (for example, using lua.do_string), am I correct that the code is treated as a Lua table rather than a full Godot script? I noticed it can’t use Godot-specific keywords like export or signal.

When you use do_string, the code will be loaded and executed right away, just like if you loaded the chunk in Lua with load and called the returned function. If your script returns a table, then yeah the result of running such code with do_string would be a LuaTable.

But anyway, you are correct, you only have a "full Godot script" if you load it as a Resource in Godot (like var lua_script = load("res://some_lua_script.lua")) or attach it to an object in a scene or Resource (which will load the script using the same mechanism as GDScript's load function).

The table itself isn't special, the LuaScript Resource is. If you get the source code of a LuaScript and run it using do_string, you simply get the table returned by it:

var lua_script = load("res://some_lua_script.lua")
assert(lua_script is LuaScript)

var script_table = some_lua_state.do_string(lua_script.source_code)
assert(script_table is LuaTable)
# actually this could be a LuaError if you use the `export` function
# and if you don't really return anything, it would be null

When I load instanced scenes that reference .lua files, do those scripts automatically have access to all Lua/Godot libraries, or is their environment limited in any way?

The LuaState used by the LuaScriptingLanguage (which is what you called a "full Godot script") has all Lua/Godot libraries opened, just like GDScript has everything available. This is quite necessary to write Godot scripts. If you need a Godot script written in Lua to run Lua code in a sandboxed environment, you can use Lua's mechanisms for that, like passing an environment table to load or loadfile. You can find lots of discussions around programs calling untrusted Lua code with sandboxed environments in the internet.

I'm trying to create a game with moddable characters, but I’m still figuring out how to attach character and weapon scripts without risking OS access or other risky GDScript libraries.

You can either create a LuaState (or multiple ones, of course) and use it from GDScript for calling Lua, or you can use Godot scripts written in Lua and call Lua code with a sandboxed environment, both will work pretty much the same. You'll need to sandbox the environment for calling untrusted Lua code in both approaches. With a plain LuaState you have the choice to not open some of the libraries, which may make sandboxing a easier, but both ways work.

One way is to not really let people write "character and weapon scripts" directly, but rather have some way for Lua code to affect your characters and weapons that you have tight control over. You can expose your own global functions for them or expect that user scripts define some callback functions for you to call. We can discuss more about designing such a modding system specifically for your use case if you'd like.

[Acanixz]

Thanks for your response!
I'll keep experimenting this/next month to figure out the best solution. As a first step, I'll try passing the object through an environment table and see how comfortable it is to implement new behavior this way.