So if I did something such as…
getfenv().print = 2
I would assume optimizations would be lost
What I am slightly confused by is if accessing a calling environment without making any changes such as
local env = getfenv(2)
will make the script lose optimizations.
It would be great if a script reading an env. table without ever writing to it was allowed to keep the optimizations. But as it’s been described, this is not the case.
Will assigning a library’s member to a variable or table cause any issues? I’m currently storing all global functions inside a table to keep my code clean in non-performance critical scripts.
An example:
local global = {abs = math.abs}--will this in any way affect the next line?
local val = math.abs(-5)Will this increase the speed of events like .touched as well?
This update does not affect physics computations. It’s about improving performance of Lua code.
I’m getting an error when using ResetButtonCallback:
repro steps: open a baseplate, put a localscript in starterplayerscripts and use ResetButtonCallback:
game.StarterGui:SetCore("ResetButtonCallback", function()
print "hello!"
end)
This is unrelated to the new VM, I’ll ping the engineer who implemented this.
I temporarily disabled this error message locally and ran the code, it produces this output:
17:52:45.916 - ResetButtonCallback must be set to a BindableEvent or a boolean
The change unfortunately causes an error before we can get to this warning message, so when this situation happens it is less clear what actually went wrong.
I’d love to see games push this new VM to its limit.
In the new Lua vm.
This way of calling a method in a Instance: Instance( method name )
How I used the method: game(“GetService”, “Players”)
Basically, another wall to call a method, but with more control and freedom.
Sadly, this was broken. Instead of the method doing what it is suppose to do. It errors.
attempt to call a userdata value
So, can we keep this feature. So that we don’t have to use loadstring or some other hidden methods of calling a method in Instance. Thanks!
I don’t think you have read the thread correctly. This wasn’t a feature at all it was a accidental result with their old __namecall.
I don’t believe they are going to be keeping it since it was purely accidental but who knows.
The way you propose is worlds hackier than proper solutions. I assume you mean dynamically calling methods (for whatever use case).
Try doing instance[method_name](instance, params...).
Like GetGlobals said, it was an accidental “feature”.
Thanks! I never knew that existed. Been looking around for an alternative.
Is there any way an exception could be made for things like getfenv(2).script? I believe that is by far the most common form of using getfenv or setfenv and in my opinion the most acceptable. The optimizations could be applied to a lot more existing code if getfenv(number).script didn’t disable the optimizations.
Approximate time for one cycle on my RTS (identical conditions):
It seems like V1 to V2 slowed down significantly for me, sadly. Still, it’s a massive improvement compared to before!
What do you mean by V1? I don’t think there were any changes that could reduce performance.
Also, if you can share your script(s) with me privately we can take a look and see what we can improve further.
When production test run, take 2 was enabled, I noticed it was slower than before despite no changes on my part.
I’ll message you regarding sharing my scripts.
Hello, I forgot to ask at lunch yesterday, could the new Luau VM be enabled on the main Phantom Forces place? https://www.roblox.com/games/292439477/Sniper-Update-Phantom-Forces
All seems good in the test place.
Currently getting some odd results with the following code:
local t = tick();
repeat wait()
local part = Instance.new('Part', game.ReplicatedStorage);
game:GetService('Debris'):AddItem(part, 3);
if (tick()-t > 3) then
print(part);
wait()
print(part);
delay(0, function()
print(part('aaa'), part);
end)
delay(1, function()
print(part);
end)
end
until tick()-t > 3
print('BREAKING')
Output:
Issue only occurs in Luau.