no. as i understand it, this isn’t regarded as a limitation, it’s a basic principle of the system. “the script” is where user-defined functionality is defined, and it gets a clean slate on launch.
if anything, future work will make script sandboxing more complete.
i’m currently writing two scripts which I want to use together and I’m thinking whats the best way to keep them working separate, yet share some state and ui
use a modular architecture.
main.lua
local ui_state = { ... }
local bl_state = { ... }
local mod_a = include('lib/module_a')
local mod_b = include('lib/module_b')
mod_a.init(ui_state, bl_state)
mod_b.init(ui_state, bl_state)
...
lib/module_a.lua
This = {}
local ui_state = nil
local bl_state = nil
This.init = function(ui, bl)
ui_state, bl_state = ui, bl
--- do stuff...
return This
(you can also provide arguments to loadfile directly, but IMO the syntax is hard to follow and it’s better to be explicit about what is happening.)
there’s nothing really stopping you from making a script that launches other scripts, but: 1) engine assignment won’t work, 2) there could be name collisions if any of the scripts declare globals), 3) if the point is to share state then you need to do that explicitly anyways.