You don’t need Ray.new at all now. You just provide the origin and direction directly as parameters to the method:
local raycastResult = workspace:Raycast(rayOrigin, rayDirection)
The Raycast documentation is linked right there in the OP. You don’t need to make guesses.
Thanks! What a Great feature to be added!
I’m not sure how to feel about this feature since it might mess up a lot of code because of these drastic changes.
Awe yisss
This is exactly what i needed, and exactly in this form! I’ve got and redone Tankery’s projectiles to use this, and it’s a LOT less laggy now!
Finally now I don’t have to make a massive ignore list tables for my rays.
Don’t worry: The old raycasting functions, while deprecated, aren’t going anywhere thanks to the sheer volume of code that depends on them. You can safely continue to the old raycasting functions if you want, you only have to move to the new ones if you want access to the new raycasting capabilities like this one.
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
I don’t get it—so, this obvious flaw in the new system which makes it a lot harder to use is simply to train newer developers into using raycasts more efficiently? Forgive me if I sound a bit condescending but like: come on, dude. The only real benefit other developers seem to get out of this is a slightly more flexible blacklist system. I might be seeing this wrong but this sure looks like a downgrade from where I’m standing.
What you’re not seeing is that the old system could not work with new features like this. There was no acceptable way to add this and other new features we’re considering to it. We never want to deprecate old APIs and force people to learn something new if we can avoid it, deprecation of APIs happens through necessity.
Roblox’ policy on API design is not to have multiple different APIs that do the same thing (no simple / extended variants of the same API), so in adding a new API for raycasting the old has has to become deprecated. If there’s something you have an issue with, it’s really that policy, not this particular raycasting API.
Ah, that’s a relief. It would be very painful to see many games break because of an update to raycasting
This is exactly what I and a lot of others needed 
deprecating the old raycast functions is not a smart move, it may break a lot of games
im disappointed at roblox
deprecating does not mean it will stop working completely…
it will probably stop working later, i never said it will stop now
It has already been confirmed that the deprecated functions will not be removed:
I loved that you updated the RaycastParams I’m currently trying too learn roblox Scripting and this new Raycasting is kinda difficult for me too learn/master are you making any potential videos breaking it down so it’ll be ever easier for people who’s trying to get a hang on the new RaycastParams?
The performance difference is probably negligible but still I want to ask, is this new function faster than the old Ray.new method?
From my experience it really depends on how you use it. For example, a large filter descendants lags significantly more than a short one. After switching to the new API I haven’t observed a noticeable difference in performance. However, if you benchmarked the functions I’d probably expect the new one to be a tiny bit faster, and reusing the same raycastParams is very useful and probably better for performance than creating new Rays every time. Can’t confirm this though.
Agreed, this seems like a massive waste of resources and a cause of unnecessary confusion. This is off-topic but that’s only the fault of whoever decided to start this “initiative” that will be rolled out all at once without consulting developers in a specific thread first.
Instead of getting worked up on a boatload of assumptions when we don’t even know what such a change is going to look like, perhaps let it roll around first and wait for the separate announcement on the topic. (since we get an announcement for any significant API change – it’s not like they would be “oh but I mentioned it in a completely unrelated announcement as a side note, it doesn’t need an announcement”) Doubt they would deprecate huge parts of the API suddenly.
Also when any engineer at any company mentions “it’s being worked on” you should probably think in the order of many weeks / several months, not a shorter time scale than that. Engineering is typically very slow and methodical.
The new function should be very slightly faster (Since you can use the same RaycastParams over and over again rather than having to construct a new ray with Ray.new every time), but in most practical cases actually doing the raycast is the expensive part, not the Lua interop, so you won’t see a noticeable difference.
If you had a very large ignore list, and you reuse that ignore list between calls with the same RaycastParams now, then you could see a larger performance improvement.
And if you structure your code such that you use Collision Groups for hit filtering, then you could potentially see a very large performance improvement, since that entirely removes the need for allocating and modifying ignore lists.