We have :FindPartOnRayWithIgnoreList() and :FindPartOnRayWithWhiteList() - Which are great, by the way.
I was really taking the time to think about what would be handy to have with raycasting, and I got this idea that I personally think is brilliant.
I don’t have a good method name down, so I’ll just call it :FindPartOnRayWithCondition() - Here’s the implementation:
BasePart, Vector3, Vector3, Material FindPartOnRayWithCondition( Ray ray, function conditionChecker = nil, bool terrainCellsAreCubes = false, bool ignoreWater = false, )
the conditionChecker function would be run each time we intersect a part, passing in the part we hit and the position we hit in 3D space as its arguments. If this function returns true, we will include that part (and in turn, “hit” it.), otherwise if the function returns false the ray will ignore the part and move on.
An example of this:
local Start = Vector3.new()
local Finish = Vector3.new(0, 45, 30)
local ray = Ray.new(Start, (Finish-Start).Unit * 1000)
local Part, Position = workspace:FindPartOnRayWithCondition(
ray,
function (Part, Position)
if Part.Transparency > 0 then
return false --Do not count the part as a hit
end
return true --Otherwise count the part as a block we can hit.
end
)
This idea could be very useful for several things including Artificial Intelligence, ignoring characters without having to store their character in a table, and ignoring hats without keeping track of everything. However, I do not think this idea has very many uses other than being able to see through windows and such. The idea has potential, and would be very useful for people that make Artificial Intelligence.
Here’s an identical feature request I made a few years back:
This would be super useful. I ended up implementing something like it in lua, but I can’t really add specific smooth terrain collisions to an ignore list.
Or you know what would be better? All the part intersections in a table with its hit points and surface normals. If I remember correctly, you have to check through every part in the way so returning those parts as a table shouldn’t be any more resource expensive.
When making the whitelist raycast method, this was one of the things that crossed my mind. My main concern with it was it calling the Lua function from C++ too often, which is the case when checking many, many different collisions. This would make the method rather expensive to run compared to the others. One way I thought about customizing it was to make a “Filter” of conditions that could be given when the method was called. Instead of a function, it would have been some kind of data structure, making it far better for performance. If I had stayed longer, I probably would have experimented with it.
