As a Roblox developer, it is currently too hard to test client-side APIs in a production environment, such as AdService:GetAdAvailabilityNowAsync(Enum.AdFormat.RewardedVideo).
The ability to run code from the console as a trusted developer would be very helpful for this.
If Roblox is able to address this issue, it would improve my development experience because we could test locally these APIs, instead of trying to guess whether or not it’s going to work.
Running client-sided code on the devconsole would be a great update to it. Much more preffered than the memory updates it had in the last months.
I’m saying that while sure, they’re helpful, I can guarantee a lot more developers (new and intermediate) will make use of this more.
You should probably add “client code” to the title. I was confused reading this considering you already could execute server code.
This isn’t possible because the client doesn’t have a Luau compiler, and I doubt they’ll ever add one to the client because of exploiter issues.
This already exists, unless it was removed in like the last week or so
Is there a reason they can’t pre-compile it on the server in this case? I would assume this is what already happens when LocalScripts & ModuleScripts are dynamically inserted into the DataModel.
LocalScripts and ModuleScripts required by them get their bytecode sent from the cloud and the engine runs that, there is no Luau compiler on the client, the cpp side runs it internally i think.
Yes, that’s what I’m saying. Have the server compile the code and then send it to the client.
exploits dont need to use the dev console to execute scripts?
Yes but providing a significantly easier path doesn’t help.
The same logic applies with the anti-cheat, there are ways around it but the friction helps fight bad actors.
It actually would not be an easier path. Many exploiting scripts use tons of features and functionality specific only to executors. A lot of these scripts may be entirely obfuscated too so im not sure how well those would play with the roblox console.
You’re missing my point - yes what I said doesn’t apply if you skip steps to use an already-established executor.
I’m on the side of adding this, I don’t think there would be a noticeable jump or change in the amount of wild exploiters out there
Roblox does some stuff to its build of Luau that makes it incompatible with vanilla Luau bytecode.
I’m not going to disclose those here because I know more than I probably should in this area, but if Roblox made a change to said bytecode, it’d be a lot easier to hook luau_compile within the binary, than need to re-reverse engineer what tweaks they did to the bytecode.
Thats also assuming Hyperion would allow you to blindly hook the function without detecting it lol.
Roblox has some smart engineers, I’m sure they can find some way to make it work!
I support.
Though they most likely wont add this, but a good alternative is to use vLua, a loadstring reimplementation.
having arbitrary code execution scripts in your game can and will get it auto-moderated iirc
I could have sworn this existed at one point but was removed.
The issue with that approach though is lua in general doesnt have a manor defining a function and preserving function information:
take this function for example
local function foo() end
its named “foo” and is defined on line 1
you can only define it on 1 specific line and you cant preserve function name too among many other things
so unless roblox adds something like debug.setfunctioninfo or at the very least a wrapper to wrap a lua function with a specfic line or something loadstring recreations / compiler recreations arent really going to be a real solution
Yup, it might be noticable as a .rbxl file but you soon find the hard truth when you publish it.