There’s no need, you can accomplish anything you need to with only one group.
The solution that you’re missing is that you can make a dedicated “raycast” collision group to use for the raycasts. If you do that, you can set exactly the set of collision groups which the ray to collide with while not impacting your other gameplay which depends on collision groups.
Was making RaycastParams an object necessary? Why not a plain table? Honestly this is one of my biggest gripes with TweenService; you have to make a TweenInfo object to pass into TweenService:Create(). This is going to be especially annoying since the RaycastParams constructor doesn’t take any parameters and all the properties have to be set individually.
Yes. If it were a plain table you would have to reflect the whole ignore list over to the C++ side every time, because there would be no way for the API to know whether the table contents had changed since the last call. Vs with a RaycastParams object the ignore list only has to be reflected at the time you assign it, and it’s stored inside of the RaycastParams struct on the C++ side afterwards.
I think you now broke all games that using all these functions,
I don’t really like this update, I don’t even know how to fix my gun because my gun using RayCasting Function.
None of the existing functionality was changed or turned down. It’s just marked as deprecated. Please read more carefully before posting. If your code is broken then there’s another reason for it, use #help-and-feedback:scripting-support if you get stuck.
I noticed that the ClosestPoint method of Ray is unavailable with the new raycasting functions. This is essential to my game. Is Ray being deprecated, and if so when will this function be ported?
Ray is not being deprecated.
Is there any possibility of this behavior changing? The old raycasting API supported finding the position even if there was no part detected, while the new API doesn’t return anything if it doesn’t hit a part. The old behavior is actually more useful (see FastCast), and it’s the one thing stopping me from using the new API entirely.
If there was no part found, isnt the only useful piece of data the end point? Which is just origin + direction?
Perhaps allow more than 32 collision groups as well to go along with this???
And also…
FindPartOnRayWithIgnoreList still seems appealing in some cases.
For example, how would I ignore two different collision groups?
In fact, what if I only want to ignore some of the parts in a given collision group?
There are MANY cases where you can’t just change a parts collision group and be done with it.
Edit:
None of the existing functionality was changed or turned down. It’s just marked as deprecated.
In that case that’s all good. As long as we can use those previous ones, although I still feel there might be some new problems…
This initiative to update the API won’t break backwards compatibility, right?
This new way of raycasting is very poorly executed. You can’t do RayParams.new() and put the parameters directly into the function, the RaycastResult object returns nil when it doesn’t hit anything (unnecessary and annoying IMO), and I’ve encountered a particular case where the ray goes right through a part some times and some don’t. Very unpredictable behavior. I tried running the exact same code using Ray.new() instead and it worked fine.
I really don’t understand why it’s necessary to remove a function as widely used as Ray.new(), especially with the new method being so unstable.
Did you read any of the thread before replying?
For a good reason: parameter lists aren’t easily extensible. This has been explained in detail, for example here: Let us use the .new() constructor to fill in RaycastParam's properties - #4 by tnavarts
This has also been explained in previous replies and it’s trivial to adjust your code for it:
https://devforum.roblox.com/t//644467/13
https://devforum.roblox.com/t//644467/83
File a bug report - complaining here won’t get it fixed: #platform-feedback:engine-bugs.
Nothing has been removed. This has been explained several times in the replies above.
I do know many people have already pointed out some of the stuff I said. I was summarizing everything I’ve encountered bad about this new method of Raycasting just to prove my point that this API is buggy, counter-intuitive, and unnecessary.
I don’t know how to replicate this bug. I do not want to share my code either. Therefore I figured the best thing to do was to just point it out here.
The whole purpose of deprecating something is to discourage people from using it, and eventually remove it/make it obsolete. Not sure what you’re trying to say.
While the purpose is to discourage people from using it, it will not be removed in any foreseeable future. This would break thousands (millions?) of games. The only way it could be removed, is if it wouldn’t break games to do so.
Also, Ray.new() isn’t being deprecated, the functions listed in the original post are.
The problem is when the world is very dynamic I don’t think we can cache raycast results because of the inaccuracies it will lead to. For example, maybe after 1 frame a part will be somewhere else but the ray result will still be the old one. Assuming you mean caching ray results.
Buy yah I would love faster raycasting if it’s possible.
Faster raycasting seems cool, but won’t it cause more lag spikes. If we have an example:
There is one instance of Game (Server), we have another stuffs like door functions object functions and other. This might cause the API in an instance suddenly experience ping which can be circa 10000ms. Which might lead to failure of other APIs like datastore.
I’m saying that this might cause if an game which gets alot of players for example 1000 players a day and they all suddenly starts shooting won’t this cause the situations like with Adopt Me?
(Yeah sorry for my lack of english)
Raycast property is very useful. Thanks for the information.
