o yes!!! i hope this wont be disabled!!
Oh my goodness. I’ve been following this closely forever, I will be first in line to test this out! I’m extra curious to see how much faster it’ll make my more intensive projects like Blox. Thanks zeux and co!
Question: will enabling the new lua VM change anything about intellisense?
edit: also the bitwise suggestion below is awesome, pretty please?
Probably not a great place to ask this, but you guys should seriously consider adding a bitwise operations API (and including them as VM instructions like LuaJIT does)
It makes a lot of work far easier and far more efficient then it is without such APIs.
It already exists too: https://bitop.luajit.org/
We’re planning to add bit32 library from Lua 5.2.
It would also be really nice if you guys could pre-compute (and use in your optimizations) the results of Roblox written pure functions such as game:GetService'RunService':IsClient()
Much of my code is shared between the server and client (and sometimes studio) contexts, so I tend to put it all in one module while separating the minor differences with
if _G.isserver then
...
elseif _G.isclient then
...
else--studio
...
end
So it would protect my code a little more and save the client memory
I see the scripts can now run better, faster, and stronger (eh) than ever before. This is one of the updates to Roblox I was looking forward to!
A question I do have is how will this affect RunService and wait() if there are any changes or is it just a generalized speed up of the execution/running of scripts and can, essentially, go a lot faster.
One of the more widely used plugins to assist with plugin development is Hot Swap, which lets you run a plugin’s source from Studio without having to mess about with it leaving behind artifacts. It stream lines the development process for plugins dramatically. It unfortunately uses getfenv/setfenv in its source, as it needs to set the environment that the source runs in.
As a result though it’s going to get progressively harder to test plugins with Hot Swap and similiar plugins as changes to the new VM are made. This might not be the best place for this question, but are there any plans to add something to test plugins without third party tools or running it with the command bar?
Not sure how much of a perf gain that would be, but I guess if you’re checking if you’re in Studio 60 times a second maybe?
(you probably shouldn’t do that though, lol)
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)
Also another question, does the new Lua VM beta ship with typing features - and if not, will the final Lua VM ship with them?
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).
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?
Smarter inference will come after the type support.
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.
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.
Here is the answer to your question:
Code used:
local f = nil;
local function asd(a)
return f + a
end
asd(5);
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.
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?
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.