Everything you see there is my own creation.
3 Likes
I created my own version of this module because I wanted to get rid of some complexity and use my own ray cast visualizer. However, I made something that might be of use for this module:
function CastDetector:GeneratePoints(resolution)
local Increment = 1 / (resolution - 1)
for alpha = Increment, 1 - (1 / resolution), Increment do
local Attachment = Instance.new("Attachment")
Attachment.Name = "CastPoint"
Attachment.CFrame = self.Object.Bottom.CFrame:Lerp(self.Object.Top.CFrame, alpha)
Attachment.Parent = self.Object
end
end
It generates a line of attachments between a top and bottom attachment.
Before:
After:
The resolution argument specifies how many points in total including the top and bottom attachment.
Obviously this is only meant for normal swords and such.
12 Likes
definitely a cool module, I’ve used it a few times already!
1 Like
V.1.53
Due to the large amount of people DMing me lately about why their rays aren’t appearing, I’ve updated some of the outdated API and clarified the troubleshooting sections in the module. The module will now also scream warning messages when it detects an anomaly that prevents rays from being cast (for example, incorrect attachment names or transparent parts).
Functionality has not been altered. Hopefully this will help those that are still confused. If you are one of them, please consider DMing me or replying below so I can help.
4 Likes
Hello. I’m having trouble understanding why I would use Raycasting to detect hits rather than using the part.touched event in a tool. Can anyone explain the concept?
1 Like
I touched base on this topic a little on one of the threads I listed in the OP. But to summarize, I needed a way to have hitboxes that do two things: Be as accurate as possible while also maintaining adequate performance.
For simpler cases, like the classic Roblox sword, Touched is all you need. You don’t have to fiddle around making rays or region3s.
My games are based around extremely fast and fluid combat. Take this gif as an example:
Touched will not work with these kinds of animations because Touched relies on physics to register. If you played any games on Roblox where something flies really fast, sometimes you can see it phase or glitch right through solid objects when it should be bouncing back. Matured game engines like Unity and Unreal Engine still suffers from this. This is the same concept. Using raycasting will allow you to achieve hit detection velocity that is impossible with touched. It’s also, in my opinion, easier to work with then Touched.
In addition, if you are moving bricks with CFrame, Touched will not register them because they are not considered “physics”. Raycasting will fix this.
Region3s are another popular way for people to detect hits, even for Cframed parts, but they are static and not much you can do with them in terms of hitbox shapes.
Ultimately, there is no right or wrong answer to what you should use. Use whatever you feel is the most appropriate for your setup. Experiment, keep trying things out, and eventually, you will come to understand the limitations of each method. Raycasting for hitboxes suffers from resolution problems, meaning wider objects need fuller raycasting setups to achieve what Touched could already naturally do. Region3 is great but it requires modification for angles and lets in unnecessary parts.
All can be performance heavy if used wrongly, but in my testings, Raycasting is the easiest to get right.
19 Likes
I have a problem, the raycast won’t properly follow my model until after it gets a hit. After that, even deinitializing and reinitializing the hitboxes it still works.
EDIT 1: After further testing it seems that this only gets fixed attacking unanchored dummies, not anchored dummies or any player
2 Likes
How is the model getting created? Client or server sided? Might be a networking issue.
The model is added on character load, cloned from server storage.
Also, it seems that dying makes the raycast not follow the model again.
Is the raycasting done on the server as well? Are the animations of the model being played on the client or is the client sending its input to the server which makes the model play its animation?
The only thing that is on a local script is inputs which then fire remote events to the server, which then does everything else
animations are on the server as well
Try setting the model’s primarypart network ownership to the server.
PrimaryPart:SetNetworkOwner(nil)
The animations might not be replicating properly on the server since its close to the player. Are you using attachments or setpoints to create the raycasting?
attachments, I’ll try that then
Unfortunately did not work, any other ideas?
You can use #help-and-feedback:scripting-support showing all relevant code and rigging to get more in-depth help, to avoid clogging up this topic. (your problem is not really relevant to anyone else reading this topic)
3 Likes
Whats the best way to use this module for square hitboxes? Like a rock? I was thinking on adding attachments to every face of the rock but it dont seems be very good to performance.
You can run hundreds of rays a second without affecting performance one bit. Creating rays in of itself are very cost efficient and you shouldn’t worry about that.
What you should be worried about is how far the rays will be shooting. 1000 rays that shoot 1 stud is better than 100 rays that shoots 100 studs. So unless your rock is going 100 miles an hour, you shouldn’t worry about performance.
However, for your specific problem, I would consider going back to touched, region3, or my personal favourite, using :GetTouchingParts
5 Likes
Thanks for explanation! I think I will still use your module because I like it very much and it works nice for me. And I consider raycasting better than the others hitboxes ways. And as the rock wont be moving (its not a projectile), I think its fine.
1 Like
In my personal experience, for the people that have double sided weapons (like me): I’m pretty sure putting the attachments down through the middle of the weapon should work, because that way, you always land a hit - regardless of which side of the weapon hit. Works best for swords.
The raycast hitboxing works off for me. My friend has found an issue regarding the hitboxing: for some reason, the hit rays can damage the player that casted them - resulting in the player sometimes getting hurt by their own sword.
Here’s a gif of that happening:
https://gyazo.com/4d72d64c8c24c8ce3dc7bca025fc9a54
Do you have any clue what could be the cause of this? And how to fix it? I thought something like this wouldn’t have been an issue. No changes were made to the module – I followed the instructions (with the connection/disconnect variable function) and this started becoming a problem just now.
The supplied Initialize function includes an ignore list. Use that and the rays won’t register it. If it still damages the character, you might have something else interfering.
local Hitbox = Raycast:Initialize(Weapon, {Player.Character}) ---Ignores character
6 Likes