Faster Lua VM: Production test run

Updates Announcements
#1

Just as a quick heads up.

We are running a full scale production test of new VM on clients only, for all games and all platforms.

The test started July 30th 8:30 PM PST and will proceed until July 31st 4:30 PM PST (for a total of ~20 hours).

Please report any issues that you discover in games - during this test we will temporarily disable the VM for places that hit any issues.

If you missed the Studio beta test thread, here it is: Faster Lua VM: Studio beta
If you have a popular place (1K+ concurrent users on average) that you’d like the new VM to be permanently enabled for after the test run, please let us know as well.

53 Likes
July 2019 Recap: Big changes and lots of hype!
#2

I hope all the testing goes well!
An extra increase in performance will allow current games to run smoother for their players and will enable developers to make their games even more complex.

Will also be great for mobile and other low-end platforms.

14 Likes
#4

Not sure I understand the question - the start of the test is in the past (since the test is already running), and the end of the test is in the future (since the test isn’t finished). Note that the times are in PST.

11 Likes
#5

This new change to the Roblox VM has ended up breaking the admin system/AE used by Hyptek causing players to be kicked after 5 minutes due to the client not loading. Please could you disable the new VM for the following places?

3 Likes
Faster Lua VM: Production test run, take 2
#6

Do you have any details as to what specifically the problem is? And yeah will disable the VM for these places in ~5 minutes.

2 Likes
#7

I’ve been told it breaks Rerubi

6 Likes
#8

Don’t know how. I’ve been thoroughly testing compatibility with Rerubi within the New VM, and experienced no issues and increased performance. Are you also using the provided compiler? Is your Rerubi up to date?

1 Like
#9

Probably not rerubj, rerubi is just a vm in lua itself. Nothing new there.

Probably the way the players spawn a in. If rerubi didn’t work then Adonis would’ve been broken for many games too.

1 Like
#10

something to do with

game("GetService","RunService").RenderStepped:connect(function()

leading to "attempt to call userdata value error on client.

1 Like
#11

Yep, like stated in the original thread, using that way to grab the getservice for run service has no support anymor.

I’d advise to change that to

game:GetService(“RunService”) and tell me if that works!

7 Likes
#12

It was stated around 50 times in the original thread that you can no longer call methods by using userdatas like functions (almost 3 pages of people trying to explain this someone). It was a byproduct of the way the old VM worked and just a bug everyone used for whatever reason.

4 Likes
#13

Same reason why you have to set an instance’s parent manually instead of making it an argument. (still works but is deprecated so it has good chances it will be removed from the new VM)

3 Likes
#14

It’s not deprecated, it’s just not recommended. There is no issue with using the second argument if you are making an Instance that will eventually have children or its properties changed.

Example would be a ScreenGui for custom particles.

3 Likes
#15

The main issue is it is just generally less efficient due to (magic) behind the scenes stuff that means you’ll incur a real performance penalty if you use Instance.new(“Type”, Parent)

1 Like
#16

Iv seen that this new VM is also breaking lots of exploits. Script executors and decompilers have to be remade for the new system, so I guess we get a period with less exploits and place stealing? :woman_shrugging:

4 Likes
#17

It’s because this VM doesn’t really have any variable names so it makes it harder to read our code even if they decompile it.

4 Likes
#18

I think that the main reason is because this is an entirely new VM and decompilers are made for the old one. Everything’s obviously going to be a lot different with this new system so exploits have to be rewritten as well? I don’t really care why, it’s just a period we can enjoy where there aren’t as many exploiters running about.

1 Like
#19

Don’t rely on it. With production tests and open beta, exploits have probably already been rewritten with the new VM.

2 Likes
#20

VMs are just middleman languages. All they need is to create a simple documentation and learn it. The exploits themselves aren’t hard to make.

#21

Yeah obviously, I’m just pointing out it’s a nice period with less exploits. Synapse can already execute scripts on the new VM but the decompiler still doesn’t work

1 Like