Ok - gotcha - that’s Lua 5.3. Our current plans don’t include adding bitwise operators or first-class integers.
Do you know if there will every be a change from 5.1 to 5.2/5.3?
Adding onto this; I’m sure with the new parser implemented by Roblox, it would be easier to implement Lua 5.3 syntactic features, and it could be a nice goal even if not in the near future.
The implementation of bitwise operators (with or without the integer subtype), goto, and maybe even string hex escapes could introduce some nice shortcuts for operations that would otherwise be harder to write as function calls or boilerplate. Bit operations I can also see having dedicated opcodes in the new VM to be blazing fast.
Empty statements would also be one of those improvements without an use really but that’d still be nice to have.
1 Like
If you want any or all of those things, I’d encourage you to make feature request threads for them. Like Zeux said above this isn’t the place for these sorts of requests.
Lua 5.1 -> 5.3 transition is not compatible so it will never happen by itself. Feature requests for specific things out of 5.2 or 5.3 that we don’t have are welcome although we don’t promise to honor them 
As mentioned earlier we plan to introduce first class support for some builtin functions to VM, bit32 is definitely on the list. We shouldn’t need operators for this because we want things like math.max to also be fast.
Amazing job! My scripts are running much faster now.
Do you have an estimate on when the un-added debugger functions will be added to the new VM?
Regarding the compatibility of the new VM, would calling this function:
local function tableObject.doStuff(table, argument)
print(argument)
end
with this:
tableObject:doStuff("Hello world!")
output “Hello world!” in the new VM? This is essentially the reverse of what is in the original post. Instead of adding an argument, it removes an argument. I find myself to be using this a lot when programming in the style of OOP.
I am not familiar with Lua outside of Roblox, I apologize for being so clueless.
That’s an explicitly defined and necessary feature of Lua, so no.
tableObject:doStuff("Hello world!") is syntactic sugar for tableObject.doStuff(tableObject, "Hello world!") and that’s not going to change.
3 Likes
“self” in Lua is nothing more than a highlighted variable name which is accepted as a standard when declaring methods. You can even set it to whatever value you want inside your function and it will work correctly. In your case, “table” acts like “self”.
2 Likes
Absolutely Awesome! Works amazing with my games!
Following in @Dev0mar’s footsteps, I’d like this to be enabled for the game I develop a reusable framework in. Universe ID is 1204364051
I’d say “self” is a little bit more than just a highlighted variable name that’s accepted as the standard. It’s used as the default name for the hidden parameter when declaring methods using the : sugar. So rather, it’s sorta forced to be the standard, but I think I’m being pedantic.
True, but it is still treated like a normal variable name. When creating functions normally, you can change it with whatever before assigning them to a table.
A little late to this but both vanilla and Roblox numbers are 64 bit. You may be confused on the size of the double data type mantissa, since it’s composed of 53 bits, but the data type itself is 64 bits with 3 components. Vanilla Lua doubles and Roblox Lua doubles are the same data type.
I was sort of flying by the seat of my pants there so yeah that’s what I meant; doubles have 53 ‘integer’ bits which makes for some awkward bitwise operations. Lua’s integer subtype has 64 bits which makes for some more normal ones.
Because of this, bit32 library that we’re adding converts all numbers to 32-bit first - so you don’t technically need full integer support; JavaScript does the same.
1 Like
Heads up: we’ve enabled the new VM for everybody who asked to enable it for a specific place id (we can’t do it by universe id); the full place id list:
1720015937
297878978
299659045
3079879442
3480168444
3091365167
176053469
516483782
187659887
2850020562
560612018
Note that it’s only enabled for these places only on desktop clients (Windows native client and macOS client, not Windows Store client). We’re waiting for all clients to update to a recent enough version to make sure we can safely enable it on other platforms like Xbox and mobile.
To manage the effort of enabling this which is a manual process we can enable the VM on more places if these places have around 1000 concurrent players or so - this is to make sure we don’t spend too much time doing this. If you have a smaller game, please be patient - we will likely enable the VM on client/server in around a month. (Studio might take a bit longer because we don’t have the debugger finished yet) If you have a popular place that you’d like the VM be enabled on, please message me privately as it’s easier to keep track vs the messages here.
Oh I forgot to put my place here earlier today.
ID: 2004770133 - I’ve thoroughly tested this in studio and it appears to work well. (This is a place id)
It isn’t popular, or even released, so I don’t mind waiting.
He literally says in his post that it is not going to change.
2 Likes