local part = workspace.MeshPart1
local partTwo = workspace.MeshPart2
local params = RaycastParams.new()
params.FilterDescendantsInstances = {part, PartTwo}
params.FilterType = Enum.RaycastFilterType.Exclude
sword:GetPropertyChangedSignal("Position"):Connect(function()
local result = workspace:Shapecast(part, -part.CFrame.UpVector * 100, params)
if result then
local originPosition = sword.Position + -sword.CFrame.UpVector * result.Distance
swordCast.Position = originPosition
swordCast.Rotation = sword.Rotation
else
swordCast.Position = sword.Position + -sword.CFrame.UpVector * 100
swordCast.Rotation = sword.Rotation
end
end)
Edited Post:
Ok I had a small lapse I guess when I read over the original release post or confused myself somewhere along the way. I was attempting to use some MeshParts and convert into models or use welds and all kinds of crazy things to make it work which always immediately stopped the function.
One step forward: So now I have successfully Shapecasted off a part attached to a tool placed in the workspace, but ending in the same result. Moving it around via Server side it works fine but the moment I equip the tool and update the part location the function stops.
I know I am probably doing this the hard way as calling Part-1 out at xCFrame to cast to Part-2 will work but I want to shapecast from a moving object that may not be a straight trajectory and the extra math will be a serious pain on top of the extra client-server delay.
This probably won’t be relevant to what you’re asking about, but big red flag with “Server side”. Because the player is the one holding the tool, it’s their jurisdiction to control the position of the tool (it is welded to their arm). That also explains why it breaks when the player reequips the tool, because they are reasserting the position of it. I guess the server and the client gets into a fight after that.
If you’re simply editing the .Position or .CFrame property of the tool, you’re definitely doing it wrong because then you are fighting with the Weld instance that’s trying to keep the tool ON the arm.
You should just clone the mesh itself, make it anchored, invisible, and fully collisionless (CanCollide, CanTouch, and CanQuery are all off), and use that as the casting hitbox. Just change the CFrame right before the shapecast operation from the server. Because it is fully collisionless you also don’t have to worry about setting a RaycastParams to exclude that meshpart; it’s already completely excluded thanks to .CanQuery = false.
Edit: They mentioned in the release thread that they will soon add a .CFrame parameter for shapecast, so you might not even have to do all this in the future.
This probably won’t be relevant to what you’re asking about, but big red flag with “Server side”. Because the player is the one holding the tool, it’s their jurisdiction to control the position of the tool (it is welded to their arm). That also explains why it breaks when the player reequips the tool, because they are reasserting the position of it. I guess the server and the client gets into a fight after that. If you’re simply editing the .Position or .CFrame property of the tool, you’re definitely doing it wrong because then you are fighting with the Weld instance that’s trying to keep the tool ON the arm.
I’m not actually setting or adjusting the position of the Tool or PrimaryToolPart or Welds in any way only the Shapecasted part which is mirroring the movement and rotation of a part on the tool, the idea is to have it free range but maintain the Shapecast for more that just a “click” by spawning an extra CFrame positioned part for a split second as most hitbox scripts would do.
(Imagine holding the beam constantly from the tool and being able to run with it pointed maintaining the Shapecast effect , very very similar to how it acts during Visualization testing and reporting back all collisions without having to spam the function every frame or calculate a dozen angles/directions vectors and program it to run them all like people do with 100s of raycasts currently.)
You should just clone the mesh itself, make it anchored, invisible, and fully collisionless (CanCollide, CanTouch, and CanQuery are all off), and use that as the casting hitbox. Just change the CFrame right before the shapecast operation from the server. Because it is fully collisionless you also don’t have to worry about setting a RaycastParams to exclude that meshpart; it’s already completely excluded thanks to .CanQuery = false.
While not shown in my example I am actually using the Shapecasted part to detect collisions and continuously perform an additional action. The CFrame param you see up there is for the Shapecast itself to maintain the appropriate distance from the Tool it’s mirroring and maintain the end function with 100% uptime and minimal performance hit. I can get this to work perfectly with any other moving item Except a tool so far and I think I am just overlooking another important detail. (It even works if you tween animate the part, its pretty cool, tons of unique uses for this even if the tool thing doesnt work out for me.)