__namecall not invoked on () anymore?
I am asking because people have noted userdata("Method")(example game("GetService")) won’t work anymore?
It would be nice if someone could test this code for me assuming they’re a beta tester. (I’m awaiting response to become a member of the beta program as I just requested to be so.)
local userdata = newproxy(true)
local meta = getmetatable(userdata)
do
meta.__index = {}
function meta.__index:method()
print"called method"
end
meta.__namecall = print
end
userdata:c()
print" "
userdata("c")
Said code outputs this for me: userdata: <address> c userdata: <address> c
I expect it to output this for users of the new VM: userdata: <address> c attempt to call a userdata value
You don’t have any production code using __namecall do you? We were advised against using namecall multiple times in the past, as it wasn’t going to be forward compatible.
I think this include idea is quite great, I notice that I find myself using the function environments quite a lot, specifically when dealing with a bunch of module scripts that need to access each other (paradoxically) which wouldn’t work using the normal require method.
I personally like the use of loading variables from one environment into the other. @Sceleratis for example, uses this in Adonis; I myself using it in a variety of other projects.
Is it maybe possible to get future improvements for this system so that we can continue to produce code that is loaded through the use of getfenv/setfenv?
Recently, I’ve come across an issue through using the normal method of requiring module scripts as each module would end up needing different functions from each module such that you end up with a circle of modules requiring each other.
Lua didn’t like this and I’ve since not found another method to complete what I want to do unless I setfenv/getfenv. Will we see some official documentation on alternative methods to use cases usually done with setfenv/getfenv?
The lack of integers in Lua was indeed one of the main reasons for not having bitwise operators. That being said though, I’m not sure if it’s particularly relevant to Roblox’s implementation. The reason it mattered for vanilla Lua is that it used doubles for all numbers up until 5.3, which meant that they were 53-bit numbers, which is obviously a bit wonky for bitwise operations. To the best of my knowledge numbers in Roblox are already 64-bit though, so that probably isn’t an issue here.
bit32 library from Lua 5.2 works around this problem by truncating all inputs to 32-bit; this is also how JavaScript implementations deal with this issue.
So I’m guessing this is lua 5.3 but worse
Which also means we’ll have to rewrite our games to function on this new “faster” lua.
If my scripts don’t run before the server even starts then this is based.
Also soo sad to see that my friend’s ultimate table ( @bmcq_12 ) which was 50 gigabytes of pure tables won’t work anymore ;(
As stated before, we intend for all games to function as they used to on the new VM. The object("method") hack that was discussed in this thread is the only exception we know of so far - it’s not part of Lua specification and we have always stressed that this should not be used.
What problems are you encountering with your game?
Hopefully some improvements on the performance of FindFirstChild()? I just realised the other day that it can take up 3-4% of CPU usage on a low-end laptop while in a mouseMoved event, or in other blocks of code that run very frequently.
(I realize that the mouse moved event has much to do with this, but I still wonder if it can be optimized some.)
As my friend stated a script that is necessary to my game will not function anymore due to the new VM. It is probably because of the new limits to tables that breaks it.
Have they tested it in Studio with the new Studio update? New VM used to have a limit on the table data size but this limit has been lifted. If the game still doesn’t run in Studio then you should leave a link so that we can investigate it.
bit32 as it exists in 5.2/5.3 has a few problems, mostly stemming from the fact that the operation it performs isn’t signed. As an example, bit32.bnot(0) returns 4294967295, and bit32.bnot(4) returns 4294967291, when they become -1 and -5 respectively in Javascript’s implementations. That could trip people up if they’re expecting otherwise.
It’s interesting that LuaJIT library returns signed results but has a caveat in the documentation:
Returning signed numbers from bitwise operations may be surprising to programmers coming from other programming languages which have both signed and unsigned types.
It seems logical for us to use bit32 from Lua since that’s more in line with the “mainline” Lua but it is unfortunate that different libraries/languages decided differently.
I wonder why this would be affected at all.