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 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.
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?
