Yeah, I’ll be testing out rays in a moment.
Kind of sad that theres no parameter for GetTouchingParts to also grab non-collidable parts.
You should ask it as an engine addition honestly, I don’t see it being a complicated method to be implemented (probably one line of code).
I think the collision group method will fit better, it’s just a bit harder to get the logic.
I think I have a solution, actually.
Simply run 4 rays that follow along the tip of the sword to the bottom of it.
Visualized, it’d be something like this:
The sword would be the rectangle and the arrow would be the ray.
I think it’d only need minimal math, so I hope this works when I test it out.
This could also allow for easy editing of the hitbox.
1 Like
Hello, have you ever considered taking a look at Raycast Hitbox 4.01: For all your melee needs! ?
It’s the perfect thing for you to use in this specific case, however if you do not want to use the module directly then I suggest forking it and just remaking what you want in your code style, I think that’s the best method of doing it!
2 Likes
Never really been a fan of big module scripts, especially when I don’t know how the code works.
It’s much easier for me to work with code I am familiarized it, especially considering how this code is object oriented (mine isn’t).
Remaking it would take too long, as I’d also have to re-read through the code several times to understand how it works.
What I would do is use both :GetTouchingParts() and :Touched.
I’ve read in another thread how to get parts with can collide false hitboxes:
So basically you create a touched event and disconnect it after :GetTouchinfParts is called:
local Hitbox = -- the hitbox
local Connection = Hitbox.Touched:Connect(function() end)
local Parts = Hitbox:GetTouchingParts()
Connection:Disconnenct()
Although these are things that you don’t want, it works perfectly fine.
As I said, I am making a sword for PvP, so using the Touched event would just lead to people exploiting it and thus giving themselves god-mode, even if it exists for the briefest moment.
Otherwise this would be a good answer, though.
Very sad that it’s exploitable 
1 Like
This is actually a weird behaviour of how GetTouchingParts work. If there is not a TouchTransmitter within the part, it won’t pick up anchored and non collide parts. A simple solution is to connect an empty .Touched event before calling GetTouchingParts, and then disconnect it later. In the case of a sword it would make sense to hold a global connection and never disconnect until the sword is dequipped. This is more efficient than connecting and disconnecting for each GetTouchingParts call.
Please refer to my thread and the post above; I’ve stated why it’s not a good idea to use it.
I don’t see what you’re referring to. What I described above addresses the issue with non collide parts. Like I said, the reason it doesn’t capture non collide parts is because this behaviour requires a TouchTransmitter to be available in the part. The Touched event itself is only used to create a TouchTransmitter.
1 Like
I clearly stated that exploiters can delete said connection (the TouchTransmitter), which would lead to them not being affected by the .Touched event whatsoever (due to it not even registering them in the first place).
Deleting the TouchTransmitter is the same as stopping the event.
1 Like
Hmm. This is something I didn’t think of. You’re correct that, due to the TouchTransmitter instance existing within the character it can be deleted. In this case, you can actually detect its removal and recreate it. Another solution would be to give the player a hitbox outside of their Character and simply move this on Heartbeat to match their character’s position. You could use a block scaled/moved to their model’s GetBoundingBox. This would solve the other issue, and setting the part to non collide/anchored would ensure a client can’t tamper with it.
Additionally, here’s an experimental idea that may or may not work which could slightly improve performance and network cost: Because Camera instances isolate their children from replicating to the client you could place the hitboxes on the server within a Camera instance per player. Physics would not execute, however, assuming a TouchTransmitter is in existance it would allow GetTouchingParts to work properly despite Touched never ever actually firing.
Believe it or not, but with the stupidity of roblox, deleting touchtransmitters even outside of the character would replicate…
This wouldn’t be as efficient as using rays, they’re made to be lightweight and there is no reason for us not to use them here.
I think what @avozzo said in his fourth post is the best way to approach this, you should totally look at it!
1 Like
Hmm. This is very strange behaviour if this is true. In this case, you might as well attempt the Camera idea. This would prevent the TouchTransmitter from being visible to the client, thus preventing it from being destroyed by the client.
I’d be better of just using the ray idea I posted as BasedFX said above, it’d just be too complex at that point.
Yep, this is definitely true. It’s just up to personal preference I suppose, and there are definitely issues with GetTouchingParts (and apparently even some I was unaware of originally).
I think the ray solution would work best. You may be able to use four rays, one traveling along top to bottom, one traveling bottom to top. You could do this for the left and right side of the part, and this would ensure that the edges of the sword always detect a hit no matter the angle. You’d need to do this on Stepped (or Heartbeat, you’ll still get similar results) to get visually accurate hits (Note: Heartbeat runs immediately before physics are calculated, and Stepped runs after physics are calculated, and before replication)
Also the reason you’d go top to bottom is due to the back side of triangles not being hit by a ray. When a ray is cast it only will hit the outside faces of parts, but if the ray starts within the part you won’t detect a hit (for example if the player’s arm is within the tip, or base of the sword). It’s definitely not necessary, and it’s up to you if you prefer that accuracy over the performance cost it creates.
Just a comment after some testing it appears that if the touchinterest is under your character the other clients are not able to destroy it. However if the part is under workspace and you do not set the network ownership to the server then it the client can destroy it.
It’ll not “replicate”, I believe it’s because of how network ownership behaves, since the client closest the part in this case your client, it’ll be the one emulating the physics for that specific part and therefore it’ll be the one that tells the server that the part is touching/the TouchTransmitter fired.
Hmm. This may be due to Parts within the workspace having Automatic network ownership, so the closest player will automatically request ownership of the part, thus allowing them to control touches. If you want, try calling part:SetNetworkOwner(nil) (to set server ownership) and seeing if the client can then block touches. Additionally, check if GetTouchingParts still works as intended even when the client has deleted it.
It does sound like Rays are still the way to go though, unless you’re really focused on 100% accurate physics for swords, in which case, go for it.
What I just do is use the method that raycast hitbox modules used. I didn’t use the module, it was limiting me kinda (having issues reading others script lol) so i made one using my owner method. It work pretty well especially in sword combat, it feels so accurate. Not even a bit lag. Just make attachments inside your sword and every render step, make ray from previous position to new position for the attachments. Every time it hits to something with humanoid or a wall etc. just save them in ignore table so raycast doesn’t hit it back. Not sure if the way i did is best but it works well at the moment.
You can message me if you like to see the script.