Welp, this will be one hell of a switch. All of my games use FindPartOnRayWithIgnoreList ;(
I’ve never touched the newer raycast methods, but I’ll definitely try it out (and hopefully, I’ll like it 
)
7 Likes
I love that raycasting is being worked on! These new API signatures will make things a lot more elegant.
I noticed that you folks switched to new enums/API but they still use non-inclusive language like “whitelist” and “blacklist”. Switching to these new signatures and deprecating the old ones would have been an opportunity to change this to e.g. “allowlist” and “denylist”, but that train has now passed. Is Roblox looking into using more inclusive language in new publicly exposed API?
18 Likes
Yea, so I wasn’t involved in designing the new Raycast API (just this new property), but it has been released for a while, and I know I at least wasn’t aware of the exclusivity of this language until a couple months ago.
I believe now there is an initiative being worked on to update language across all our API, and should be rolled out all at once.
15 Likes
So is this pretty much a blacklist but for collision groups instead of having a big table filled with objects? This is amazing!
3 Likes
Not sure how I feel about this. On the one hand, this is awesome being able to have it all simplified into one function. On the other hand, I did like the giant table method because I could run a for loop and add specific parts in some rays and different parts in others. Not sure how I really feel about the collision group but I’ll adapt.
Overall very excited to see this
5 Likes
There are unfortunately some use cases where it’s slightly harder to get what you want thanks to returning nil, but it’s the better behavior, as it forces you to actually think about how to correctly handle the case where nothing was hit: Some pieces of code just used the “hit” position before in cases where they really shouldn’t have been.
When considering the potential use cases, I found that the majority do want a branch, and I think that people will tend to write more correct code with the new API.
The goal of the raycast API is not to make raycasting easier to use for developers. The old API was easier to use, the problem was that it was not sustainable and was holding us back from adding very useful and highly requested features like this one. The cost of having that more powerful and flexible raycast is that it’s more complex to use.
Ideally people can write simple to use wrappers around the full Raycast API it if they don’t need all the power it provides, though I understand there’s not great ways to distribute / find such wrappers right now.
6 Likes
You can still do this! In fact, it will have exactly the same performance as before, the reflection cost just happens at the time when you assign the table into the RaycastParams object, rather than the point where you call the Raycast method.
And in the case where the black/whitelist does not have to change, you get better performance as it doesn’t have to be reflected an additional time.
10 Likes
This seems like a very bloated and ugly function. What if I want to raycast in such a way that everything is accounted for, regardless of collision groups? A use case for this would be in a plugin that renders the map from a top-down perspective. It seems like this new function does not provide a way for this, and therefore I would have to use the deprecated functions.
These functions should therefore not be deprecated, since there are still use cases which are not covered by the new parameters.
12 Likes
The behavior will be exactly the same as it was before in the case where the parameter is set to the default collision group, as Raycasts have always acted as though they were part of the default collision group.
In your top down perspective example, this gives you more flexability: You can create an explicit “world map” collision group to use for said Raycasts, and toggle it to have exactly the collidability that you want to filter what objects show up on the world map.
3 Likes
Is this true? I thought Workspace:FindPartOnRay had never accounted for collision groups in the past; so you’re saying that, before this update, if I called workspace:FindPartOnRay()..., and some part was in a collision group that was non-collidable with “Default”, it wouldn’t be accounted for with this call? Or do you mean just the WorldModel:Raycast function?
This sounds really sketchy. I would have to manually set the collision group of every part in the workspace, and hope that the user does not save and close their place before I complete the operation and set collision groups back.
5 Likes
Yeah, I’ve literally run into this myself. This update only adds functionality. I’m actually really glad they added this as I have some collision groups that collide with each other but not Default and I’ve never been able to use raycasts with them.
3 Likes
Or leave RaycastParams.CollisionGroup as Default, use RaycastParams.FilterDescendantsInstances and set RaycastParams.FilterType if you want to replicate the exact functionality of the old methods.
3 Likes
All raycasting variants exposed to Lua have always only hit things which collide with the Default collision group. You can try it out for yourself if you don’t believe me, this change hasn’t touched the old raycasting functions at all, the behavior they have right now is what they’ve always had.
Well… yes, if you want to use collision groups then you will have to set collision groups on the relevant objects.
Is this true @tnavarts, or does the collision group behavior take precedence over the whitelist/blacklist?
1 Like
In that case this is a net positive in my opinion! I see this as an absolute win!
1 Like
Collision groups are an additional filter on top of the whitelist/blacklist. The whitelist/blacklist specifies which objects are candidates for collision, and then the collision group further filters more objects out of that set of candidates.
So, you can set a collision group to filter out additional objects for a raycast which already has a whitelist/blacklist.
1 Like
That sounds really bad then, and the API should be updated to have a way to ignore this filter (ideally this should have been the case by default, but 
)
I’m already seeing ways in which this is going wrong when I try to select a part inside of a filter group non-collidable with default. It turns out all of my plugins, and the built-in plugins won’t let me select these parts by clicking on them because there’s no method that lets you raycast with it without explicitly searching in that collision group.
Would collision groups be faster than using tags? Currently I use the collection service for tagging items which I want to be ignored, so would it make sense to switch over to collision groups? It would be cool if the RaycastParams worked with tags as well and not only collision groups.
1 Like
This is really an issue with collision groups, not an issue with raycasting. Either it should not have been possible to disable collision with the default collision group, or there should have been an explicit “actually everything” collision group that’s always available in every place.
We’re aware of this issue.
3 Likes
The real issue seems to be that collision groups are leaking into the raycast API. IIRC, raycasting came out long before collision groups, so it seems like there have been backwards compatibility issues in the first place, and I personally was completely unaware of the interaction between collision groups and raycasting.
1 Like