Non nil and NaN
1 Like
To answer your question again, it’s because each Vector3 is its own object, which means it’s unique. I would suggest storing it as a string or using some other method if that’s how you have to store it in the table.
OP is constructing a new Vector3 which seemed to be the issue yet this prints true 
That works because the comparison operator is overloaded.
Try it with rawequal and it will fail.
This works with strings because Lua strings are interned. In other words, when you create two strings of “Hi”, it actually reuses the first one for the second one internally. String “interning” is a common practice in many (if not most) languages.
If you want to create your own “interning” system, you would have to create your own constructor for Vector3s and cache every version in memory. This is costly, and I would avoid doing it personally. You might as well convert the Vector to a string if you really have to use the vector as the key.
2 Likes
That’s because of the __eq metamethod. If you were to do print(rawequal(Vector3.new(), Vector3.new())) you would get false.
1 Like
That would be because the metatable for Vector3s has an __eq metamethod. They’re not identical pieces of data yet they compare properly because of this.
when 3 replies in a row hit the nail…
Anyway, this thread’s also been pretty informative for me as I read through it.
A curious question: how come you aim to use Vector3s as keys? What is the merit in doing so?
Voxel terrain generation where I can easily index a chunk with it’s position.
3 Likes
I have an idea for you. Instead of having your keys as the Vector3 objects, turn the Vector3 to a string, and from that point use it as the key.
So instead of doing
t[Vector3.new(1,2,3)]
just do
["1, 2, 3"]
tostring(Vector3.new(1, 2, 3)) also does the job
1 Like
Yes, when using it on a variable. Otherwise it’s pointless to type all that.
Use tostring(v3) as the index