What about the actual Ray type itself? Or is it just these methods?
The new Raycast method doesn’t use the Ray class, so I think it would also be deprecated.
I am asking because of methods like Camera:ViewportPointToRay which return a ray object. And it feels kinda weird using one of those with the new api. But maybe that is just me.
That function didn’t work nicely with the old API either, since you had to decompose the ray it returned to scale up the length. Things haven’t changed in that regard.
Alright, and will new variants be made that return RaycastResults instead perhaps? Because I thought the purpose of the new api was to make ray casting easier? And to not use actual ray objects?
1 Like
So… now that we’re making new raycasting functions, can we also get boxcasting and spherecasting? lol
11 Likes
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.
1 Like
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.
5 Likes
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.
2 Likes
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.
1 Like
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!
1 Like
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.
3 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
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.
1 Like
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.
1 Like
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 
3 Likes