I’m not sure if doing this is a great idea so I want to know the pros and cons of it:
The pro is that you can cover a greater surface area, con being it pays it’s price in processing power. More Ray’s equals more work for the player’s machine.
Why exactly would you need to use this many?
Sorry for troubling you with two posts, but I wanted to make a good melee hitbox.
Would something like this be more reasonable?
I enjoy trying to put my little bit of knowledge to good use .
In that case it makes sense to use Ray’s in that way since most other methods of melee touch detection aren’t consistent.
Yes, that seems like a perfect amount for checking one direction.
Don’t be afraid to post whenever you have a question if you can’t find an answer for it already!
Thanks for helping me so much, I swear this will be my last post for today .
In your case i’d make a single ray cast and use math.clamp
Are you using those attachments for raycasting to detect the local player?
What does that do exactly? I’m not sure what math.clamp does.
I’m using it for both npcs and players, the one for the npcs will be serversided.
print(math.clamp(6,0,9))--6 because 6 is not less than 0 and not greater than 9
print(math.clamp(-1,0,9))--0 because -1 is less than 0
Why not just put and expanded Hitbox around the character and npc models and weld it to the HumanoidRootPart?
If you are talking about using .Touched for the hitbox I don’t think I wanna do that because of how unreliable it can get when it’s laggy.
No use an expanded htibox along wiith raycasting from attachments on the sword.
The thing is, I don’t want the attachments to be on the actual sword, I want the rays to check in a rectangular shaped area like in the picture.
I’m not really sure how I would use this in my situation
I recommend looking into a Region3 check. As Raycasts evaluate against every part in the workspace to determine which parts intersect with it. Do that multiple times, and you got yourself a laggy game.
Region3 is the same thing, but it’s a 1 time check within a invisible bounding box that you specify. Think of it as checking what parts in the workspace collide within 4 corners in the world that you specify. (You only have to provide 2 points to create the Region3) It returns a table of all intersects within the region.
For example, if I’m at position (0, 10, 0) and I want to check what collides in that area with a 5 stud radius. Here’s how my Region3 would look like:
local HalfBoxSize = Vector3.new(5, 5, 5) * 0.5
Region3 region = Region3.new(Player.Position - HalfBoxSize, Player.Position + HalfBoxSize)
That would create an invisible bounding box from the player’s position, spreading out by 2.5 in all axis, which creates a cubic collision bounding box. Anything that falls within that volume in the world is considered colliding. It’s like creating an invisible part with a bounding box, but only programatically, you’re not creating an actual object.
However, you could weld an object to an enemy, and position/size it however you want. If you create a part with a size of (10,10,10) and weld it in front of the enemy. You could create a Region3 check that is positioned to that part, and expands by (5,5,5) in both directions from that center position. It’s the same concept as the code above.
Region3 also supports whitelists. So if you know what parts you’re looking for, you can specify them. ROBLOX will check if your box is colliding with any of the specified parts. Instead of looking through the whole workspace. Which save a LOT of processing time and ups your performance.
Hope this helps!
I mean raycast from root to closest body with math.clamp, that will prevent ray cast from going that far
Thanks, I always thought region3 might be useful sometime, I will look into it to see if it works for me.
I was going to make the ray cast to a certain amount of blocks forward so there’s no need for that.
My idea is to fire a bounding box towards the target of whatever size you desire. If it falls within that box, fire a raycast to determine if it’s in sight. Then, you act from there.