Faster Lua VM: Studio beta

Updates Announcements
#29

I cache game:GetService'RunService':IsClient() into _G.isclient anyways so it’s a table index instead of a function call

It’s not for execution performance (I assume Roblox pure functions are fast) but it will

(I will anyways implement this myself to protect my code if this does not become a thing)

2 Likes
#30

Also another question, does the new Lua VM beta ship with typing features - and if not, will the final Lua VM ship with them?

1 Like
#31

Type annotations are a separate project - we intend to ship both this year, but they will ship separately and independently (incidentally, they share parts of the stack, specifically the Lua parser).

3 Likes
#32

O awesome. So does that mean with the new VM we’ll start seeing some slightly smarter inference in intellisense, since the type annotation stuff shares some components with the new VM?

1 Like
#33

Smarter inference will come after the type support.

5 Likes
#34

@zeuxcg Is this LocalScript Obfuscation - #12 by zeuxcg included in this update?

3 Likes
#35

Not fully. New VM no longer sends local variable names to the client, but it still sends function names and line information so that callstacks can be readable.

13 Likes
#37

Interesting stuff!

Curious to see how well this plays with a Lua in Lua implementation such as LuLu. I’m looking into building a Scripting focused game in attempt to help newer Users learn Lua. One of our obvious concerns is ensuring Users cannot abuse this system intentionally/unintentionally, and we’re looking to utilizing the Lua in Lua approach to implement more detailed sandboxing. Will come back with results later on.

6 Likes
#38

Here is the answer to your question: epic

Code used:

local f = nil;
local function asd(a)
	return f + a
end

asd(5);
2 Likes
#39

Ow. That is going to cause some issues for me. Aswell as the fact that doing game("Method") won’t be possible anymore, since I use it in a lot of places.

#40

I’m all for this! If bitwise operation support is being added, why not just skip ahead and add the bitwise operators from Lua 5.3 though?

13 Likes
#41

5.3 has actual “integers” and non-integers that behave differently when cast to a string (they add “.0” everywhere) so I don’t think importing the operators would work without also including the non-backwards-compatible number behavior.

3 Likes
#42

__namecall not invoked on () anymore?
I am asking because people have noted userdata("Method") (example game("GetService")) won’t work anymore?

It would be nice if someone could test this code for me assuming they’re a beta tester. (I’m awaiting response to become a member of the beta program as I just requested to be so.)

local userdata = newproxy(true)
local meta = getmetatable(userdata)

do
	meta.__index = {}

	function meta.__index:method()
		print"called method"
	end

	meta.__namecall = print
end

userdata:c()
print" "
userdata("c")

Said code outputs this for me:
userdata: <address> c

userdata: <address> c

I expect it to output this for users of the new VM:
userdata: <address> c

attempt to call a userdata value

3 Likes
#43

image
:pensive:

3 Likes
#44

Yikes! :pensive: I wonder why this would be affected at all.

3 Likes
#45

You were never meant to rely on that behavior.

https://devforum.roblox.com/t/roblox-altered-lua-quite-a-bit/35354/25?u=xaxa

9 Likes
#46

It was apparently an unexpected feature of the old vm:

I’m having a few issues with my own scripts aswell

image
image721×33 1.55 KB

5 Likes
#47

You don’t have any production code using __namecall do you? We were advised against using namecall multiple times in the past, as it wasn’t going to be forward compatible.

4 Likes
#48

Right, I guess it would make sense to have some backwards compatible distinction between integers and floating point numbers.

6 Likes
#49

I think this include idea is quite great, I notice that I find myself using the function environments quite a lot, specifically when dealing with a bunch of module scripts that need to access each other (paradoxically) which wouldn’t work using the normal require method.

I personally like the use of loading variables from one environment into the other. @Sceleratis for example, uses this in Adonis; I myself using it in a variety of other projects.

@zeuxcg

Is it maybe possible to get future improvements for this system so that we can continue to produce code that is loaded through the use of getfenv/setfenv?

Recently, I’ve come across an issue through using the normal method of requiring module scripts as each module would end up needing different functions from each module such that you end up with a circle of modules requiring each other.

Lua didn’t like this and I’ve since not found another method to complete what I want to do unless I setfenv/getfenv. Will we see some official documentation on alternative methods to use cases usually done with setfenv/getfenv?

4 Likes