RaycastResult has a false-positive comparison condition

RaycastResult appears to be making a piecewise comparison of the data on an equal operation, and not a simple memory-address comparison, but is missing a comparison of the Position values for each object.

This creates a false positive with 100% repeatability whenever you do an == comparison, or attempt to use the table.find function on two RaycastResults that have identical Instances and Normals, but different Positions. Here’s some example code that will always return true in a blank baseplate place:

local Cast1 = game.Workspace:Raycast(Vector3.new(20,40,0),Vector3.new(0,-100,0))
local Cast2 = game.Workspace:Raycast(Vector3.new(-20,40,0),Vector3.new(0,-100,0))

print(Cast1,Cast2)
print(Cast1 == Cast2)

And here’s a screenshot if it being ran (The last print here should be false, as the RaycastResults here are not equal


)

And here’s the repro file (though should not be needed as it’s not game-specific):
RaycastResultComparisonError.rbxl (31.2 KB)

2 Likes

After experimenting with this some more, it appears that RaycastResult, when using comparison operators, only compares if the Instance property is the same.

To test this, I duplicated the baseplate and had a 2nd raycast pointing upwards towards it.
image

task.wait(2)
local Cast1 = game.Workspace:Raycast(Vector3.new(20,40,0),Vector3.new(0,-100,0))
local Cast2 = game.Workspace:Raycast(Vector3.new(-20,40,0),Vector3.new(0,100,0))

print(Cast1,Cast2)
print(Cast1 == Cast2)

The result:

1 Like

I believe it also compares the normal hit too. Just not the Position

Definitely a bug but I’m curious why you’re comparing RaycastResults.

Generally comparing them is a bad idea because two results may be different even if they are very close to one and other (close enough that for all practical purposes you could consider them equal).

1 Like

I was hoping they would use a memory address comparison, which would be a convenient and fast index to sort some of my data by. I have what can best be compared to as a “point cloud” that I’m taking slices of, and connecting into lines, and storing the rest of the data of each point by the raycast result just made sense. It allowed me to remove points from the cloud without the list shift were the index was just a number, and also let other tables quickly use a hash lookup to get what they needed.

So think like three different tables that need to talk to each other, and the main one is indexed by the RaycastResult. I was noticing I was getting hit with a lot of false positives on some of the other tables and comparisons, and eventually traced it back to this issue. I’ve since implemented a temporary modification to my code to let it run for now, to wait around and see if the behavior gets fixed or not.

Edit: I wanna clarify I was comparing the same RaycastResult to itself. Not two very close ones.

Any update on when this might be fixed/ if ever? I just re-tested, and I’m still having this issue. I’m not familiar with the dev pipeline of you guys, but it’d be much more reassuring to have an idea of what’s going on in the process.

Sorry, looks like it got lost in the shuffle. Submitted a fix for it now, but it will take a few weeks to come out because it’ll need to wait for a mobile force update.

2 Likes