See above, that’s not the purpose of the new API. The purpose of the new API is to be able to add more powerful features like collision groups and ability to re-use ignore lists to raycasting. There was no space left in the old API to add said features.
Ideally a simpler raycasting interface should be provided by Lua libraries wrapping the core raycasting API rather than an additional redundant builtin function.
I’ve also noticed this behavior.
I like the new raycast function (especially if it’s faster, better, easier, etc) but I don’t like how it returns nil and I have to get distance, etc from the max distance itself,
it feels like the wrong way to do raycasts somehow and I was used to it always returning something even if it does not hit anything,
I have to write extra lines of code and checks for when it doesn’t hit anything now.
I still prefer the (now deprecated) old raycast functions sometimes because of this, even if the behavior is intended.
I would like to point out that, in my independant testing, the new raycast function is about 50% faster than firing the old event with blocklists (measured the time required to fire 2K rays, firing through two blocklisted parts and hitting an allowed part); despite seeming more complex in concept!
Good job, Roblox. I’m still experimenting with the new method, but it also seems to be a lot more robust (less weird missed detection errors) than the old one. After a bit of head-scratching while converting my methods (it seems the method of determining direction/length is a bit different), I’m finding the new method MUCH better.
The only “downside” i’ve found is that you can’t use the ray result explicitly to create “tracers” (for example) and instead need to use the inputs; a minor detail, but a bit less useful for debugging in principle, since it expects the raycast to be working precisely as you’d expect it to with the input, rather than relying on the output of what the ray-cast “did”. Again, if the module itself works as it should (which, as far as I can see, it does), this is a non-issue.
This is cool , but will
local raycastResult = workspace:Raycast(Ray.new(rayOrigin, rayDirection))
work?
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?