Question: In the old VM, you guys got rid of tail calling. I think it was removed due to debugging complexity? Is that still the case, or do we get tail calling back in the new VM?
We don’t have existing plans to revive tail calls. There are more call kinds in the new VM so guaranteed tail calling is somewhat more involved compared to vanilla VM, and in regular code the performance advantages are not significant. So I would say it’s unlikely that they will come back.
Tail recursion is still possible by creating a variable before the function. Sure, it’s no optimized like in the default Lua, but most cases can be easily replaced with a while loop.
Without proper tail recursion, you risk stack overflows with recursive functions. But yeah, usually they can be reformatted into a while
loop
Right but the thing is, you risk stack overflows with recursive functions anyhow unless all calls are in tail position Generally speaking “interesting” recursive algorithms are non-trivial to implement with tail recursion, and “boring” recursive algorithms are trivial to implement with iteration.
I’ve been waiting for this update. Thank you!
I have been hyped about this update since it was announced in Beta! Thank you for making the games better and Better!
So regarding multi-threading, how is such a thing like that going to be implementation wise? Is it going to be done via the roblox lua API functions or is it going to be automated internally in the VM? I feel like lua is very tricky language to do such a thing effectively.
Local script will never be safe.
The reason why is because local scripts run on the user’s computer. Meaning that they will always be able to access them if they run on their computer.
It is the same for place stealing; Exploiters will allways be able to steal places because roblox sends the places to their for their client to render and so that the character isn’t really buggy.
Uh… What? The place can’t exactly be stolen. Anything inside the ServerStorage and ServerScriptService isn’t replicated. Also, the thing that is being sent isn’t the place itself, but rather the properties, which include hierarchy meaning that a place can be somewhat reconstructed.
If the entire place was sent then decompilers wouldn’t be required as the scripts would already contain the source.
there has been multiple instances where my prior and current pc havent been using the GPU for some reason. Oh and roblox lags a lot sometimes when I move my mouse too much, same thing happened more regularly on my prior pc [x2]
Because all the logic is done on the CPU. That includes particles, beams and other integrated stuff. Running on multiple threads might make it faster, but only if they include multithreading on the C++ side. Your GPU will still not be affected in any way.
I honestly like this update. I can use more coroutines then ever in one script! makes it very useful for loops.
sadly exploiters have already caught up, most of them created updates before the full release just to be ready
This has been really frustrating. Error messages turned from:
attempt to concatenate field 'Foobar' (a nil value)
…to…
attempt to concatenate field a nil value
(or whatever it is, I had to turn it off for the debugger).
Errors like these make debugging significantly more frustrating, especially when the line is something like:
local thing = foo.Foobar.Baz.Qun
Code like this is used regularly in Roblox, as well.
local cframe = model.PrimaryPart.CFrame
If I get an error about indexing a nil value, what’s the nil value? model
? PrimaryPart
? Luau won’t tell me.
Would be nice for at least the owner to get the names or always show it in Studio.
My understanding of what “debugger” means is the actual breakpoints system, which does not work yet.
This is not about the local variable names, the mechanism that Lua uses to recover this information is fragile and impractical to support. We can improve the error messages to show the key names which is how this is generally handled in other languages / environments.
edit: removed the part about asking for a feature request thread because there’s only one thing we can do really which is to 1) specify key name in the index/newindex errors if it’s a string, 2) specify both operands in arithmetic/concat so that you get smth like “attempt to add number and nil”.
But it still makes it much easier to obfuscate your code.
Before this update you had to use completely nonsensical variable names, but now you can create multiple variables with random names and one at the end with the name you want. In other words, you can make your obfuscated code actually readable now.
An example of what I mean (a really bad example, but I don’t feel like I have to make something useful to prove my point):
local a,b,c,TheRealName = TheRealName,c,a,b
This is what decompilers might generate:
local var1,var2,var3,var4 = var4,var3,var1,var2