Through my years of finding ways to better support custom maps. There’s still a lack of tools to allow my map submissions to have custom scripts that I can run in my own lua sandboxed environment. It’s an environment that’s designed to only interact with my framework.
Feature Request:
Anyways, it is quite a niche use case but it would be amazing if there were something of the following:
A LuaSourceContainer with the Source property that’s not only accessible by “command bar and plugins”. Preferably this script is more like a text file and cannot run in the DataModel while still have syntax linting configurable with a property like bool EnableLinting.
I’ll name this class TextScript for further references.
or
A LuaSourceContainer that has a method to only be allowed to run in a custom environment like so workspace.CustomScript:Run(customEnv)
I personally prefer the first option.
Why not ModuleScripts?
Well, I’ve made similar posts before for require() to allow a way to require the module into a custom environment, like so require(workspace.CustomScript, customEnv) but that has its own issues. And of course, by default it would require and run the script in the default environment currently.
Why not StringValues?
The technical issue would be StringValues has a character limit. The other issue is you can open it up like a script to work on, just like how no one writes readme or documentation in StringValues.
Why does it have to be in a sandboxed/custom environment?
I do a sweep of my custom map submissions for scripts, and generally check if everything is permitted to be added as a custom map, however that just means I have to go through all the scripts in the map. Ideally, nothing malicious go through, but it would save me a lot of time and have every script as TextScript that can’t run in the DataModel other than through my sandbox.
Sandbox and loadstring() are unsafe, just don’t use them, what if they leak?
Just like how ServerScriptService.LoadStringEnabled is disabled by default, I do believe it’s up to the developers to decide whether or not they would enable such a feature. While I do loadstring using a virtual lua machine instead of Roblox’s loadstring() since I also use it for some custom script client side, I do understand how it’s my responsibility to make sure the sandbox is properly sealed. Roblox on the other hand can help by strictly only allow this TextScript to run in a sandboxed environment and any access to DataModel will require permissions perhaps.
I just want to have more ways to support my community, and I believe Roblox does too.
BaseScript.Source used to be accessible (read/write) back in 2013/2014 (iirc, it’s been a long time) by the Level 2 identity (not sure if this is still a thing, but I know Luau still has some sort of identity context for permissions management), but was intentionally changed by Shedletsky since it also opened a whole slew of other issues.
With the direction of Luau, adding support for modifying the environment isn’t going to be a priority if added at all. In fact, although I hope they are willing to keep it as is, but Roblox wants to remove the ability to modify the function environment as it will allow them to do further performance optimizations currently not available.
For the foreseeable feature, your best bet is going to be vLua or other Lua-in-Lua VM implementations. This is something they’re not going to make more accessible, only harder to do.
Source:
Joined Roblox in 2008
Been around the Script Building community since 2013
Why not add parts with special attribute for custom maps? So when imported, your game’s scripts can search for those parts with their attributes, and if they have a specific tag let’s say name pointing to a module, it will run a function or a class’s .new() constructor passing the part as a parameter (so you can use that part for position/orientation if necessary). For organizing geometry parts from editor-only parts, you can simple put them in their respective folders within the custom map folder
The function environment is deliberately locked like this because it messes with a whole bunch of Luau optimisations.
The use of getfenv and setfenv deops the running thread because bytecode ops such as GETIMPORT and FASTCALL requires certain objects to be in known locations and changing the function environment moves these locations.
loadstring is the same, but its for a different reason.
The best idea would be to allow real-time compilation on the server but run it in a custom VM state where you can either allowlist or denylist certain Roblox functions and objects (i’m unsure of the performance of this?, and how it would it would play with the existing restricted objects)
Thanks for the feedback, I haven’t kept up to date with the development of luau so I was unaware of the changes to the environment or even locking it.
However, I have been using vLua atm to loadstring so far, crazy to see the maintainer of it reply to my post. Keep up the good work!
I guess my feature request boils down to a way to store and get source. So the aforementioned TextScript would be the desired addition.
@SomeScripter3
I get what you’re trying to say, but that may be too basic and lack ways to add custom logic and states. Like if a mapper wants to add custom interaction/puzzle logic.
Many reasons to not want to reinvent the wheel, especially when I’m currently a solo dev. I’ve considered it, but all that work just to work around a limitation of having to not store source in existing LuaSourceContainers is just too much for too little.
The point is, all I need is just a new SourceContainer where I can store and get source during run-time. Not StringValues, already mentioned why. Even if it just stores plain text, that’ll still be enough. Hence, TextScript.
You can also just have custom maps that are just models only (no scripts) and import them yourself
But i think another LuaScriptContainer would be cool, i like to have different script types in the game like reguler Script, LocalScript, ModuleScript. And i wonder what more script-types Roblox can come up with
Not entirely accurate. Certain places were whitelisted to have their scripts run at identity 3, which allowed reading and writing of Script.Source. I believe they were inaccessible from identity 2 as far back as 2010.
As for this feature request @MXKhronos, I’d advise against this conceptually. Even if it were possible, you can’t really trust code. And yes, sure, you may say that you’re willing to accept that risk now, but give it a few years and you’ll regret having to be vigilant against a malicious actor wiping player data.
I won’t repeat what Metatablecat and Reinitialized have said about script optimizations, since you seem to understand it. If it were up to Roblox, they’d probably make environments outright immutable (the impression I’ve gotten is that the Lua 5.2+ _ENV feature would be better, but that boat has sailed, so we’re stuck with it).