Will there ever be a “faster” Raycasting, if that is even possible?
Like “Ray caching” between callbacks. The first callback is the most expensive, the next ones are less expensive.
I know there was discussion earlier about this returning nil, and that it was intended, so how would I go about using this to find the end point of the ray?
Also, whats the difference between this and
local PS = game:GetService(“PhysicsService”)
local part, pos = workspace:FindPartOnRay()
local group = “CollisionGroupName”
if not PS:CollisionGroupContainsPart(group,part) thenend
because in my opinion, just like using the TweenService, it will be very tedious to keep making new RaycastParams every time I want to change how the ray will interact with the game.
@tnavarts, The ignore list isn’t mutable, so if the list changes you’d have to create a new RaycastParam anyways, I don’t really see the point of using it, and using CollisionGroups instead of an ignore list is probably not a good solution either since it causes complications, you can only pass one CollisionGroup and CollisionGroups can’t be created on the Client which is where I do Raycasting thus this causes further complications.
1 Like
I feel like we should be able to set arguments for RaycastParams.new() like TweenInfo.new(). It feels really awkward having to create it then change individual properties later.
You don’t actually have to create a new RaycastParams if all you want to do is modify the ignore list. You can modify it the same way you create it:
RaycastParams.FilterDescendantsInstances = {unpack(additionalItems)}
Though, @tnavarts, it would be slightly more handy to have the array be mutable, as adding a new instance to it would be as simple as doing table.insert( RaycastParams.FilterDescendantsInstances, newItem). At the very least I think an error should be throw when trying to do this as I wasted quite a bit of time trying to figure out why my rays weren’t working properly.
1 Like
I considered having a way to something like that when I designed the API, but (ironically given you complaint) I was worried it would be too easy for people to accidentally “leak” an ever-growing ignore list which they never cleared out.
Locking the returned table so that you can’t accidentally insert into it thinking you’re modifying the RaycastParams would have been very unconventional, as no API calls currently return a locked table. Either way, we can’t change the API now whether or not it is actually a good idea because people might already legitimately be getting the ignore list and using the table for their own purposes.
I can look into adding a lint for this scenario though, so that the studio script editor would warn you if you try to do that.
1 Like
Will it be so we can pass multiple collisionGroups anytime in the foreseeable future? As stated we can only pass one currently. My case is narrow and there is no easy alternative.
My game has characters swim in terrain water. The Humanoid makes arms canCollide true when in water to let physics, buoyancy, work on them. If a player fell with their arm tucked along a thin vertical wall into water their arm would then pin them to the wall as it would still overlap just having become cancollide.
I ended up giving the arms and legs a nocollide group so this could be fixed, but now I want to make a mouseoverShowName and it ignores their arms. I can’t just raycast each collision group individually, the wall wouldn’t be in the nocollide scan, nothing would be.
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.
3 Likes
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.
2 Likes
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.
1 Like
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.
4 Likes
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?
2 Likes
Ray is not being deprecated.
3 Likes
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.
1 Like
If there was no part found, isnt the only useful piece of data the end point? Which is just origin + direction?
4 Likes
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.
2 Likes