Best way to detect area collisions?

[Dudeguy90539]

After finding that the projectiles in my game are kind of difficult to use in terms of hitting anything, i have decided to give area to them (my original method was to create an arc of Rays to follow its path for collision detection) I first attempted this by trying to make a Region3 and set its CFrame to where my ray would be. After finding that the CFrame property of a Region3 is readonly (it doesnt say it’s readonly on the API reference, i had to find this out from the output window ), i am now having to decide between two alternatives:

1: i can use instead a part who’s size and cframe would emulate that of the rays, and call its GetTouchingParts() method to get parts that are colliding. The problem with this is that this method usually only detects parts if their CanCollide property is set to true, and the part in which the method is called must either have CanCollide set to true (cant do that, my bullets would cause players to fly off the map) or must have something connected to the part’s Touched event (i could make an empty method, but this seems hacky) There is also the issue that the player’s hitbox also has CanCollide set to false, and must have it set this way for the player to move properly. It would be possible to set the projectile and the HitBox to a different CollisionGroup, and this would most likely run without any errors. (assuming the collisionGroup means what i think it means) This method of detecting the collision; however, would consume way more resources due to the instantiation of several parts when a single bullet is fired (there are lots of them in this game)

2: I could keep my raycasting method, and instead increase the size of the player’s hitbox. I do not know if this will have the effect that i was hoping for with the area method above ^^, but this would consume the least resources possible, which should probably be priority concern.

I do not know which i should choose, please help me ;-;
Any feedback is appreciated

[keeptheluck (Duke)]

I don’t really have much experience on the field of projectiles and stuff, but I usually code with performance in mind and I’d really recommend the ray method. Maybe use the built in method Workspace:FindPartOnRay

Again, not much experience, but this might be at least better than creating an empty method which must be connected until all touching parts are put in a table, which is time consuming and honestly, heavy on the server.

[Dudeguy90539]

yeah, thats kinda what i was thinking too. honesly though, i think we should be able to change the size and CFrame of region3s (i know this would make terrain generation kinda wierd, maybe using the ExpandToGrid method would reset the orientation to 0,0,0)

[Reduxity]

For option 1, you should probably refer to this:

Simple trick to make GetTouchingParts work with non-CanCollide parts

NOTE: This is obsolete in favor of better bounding box checking API now: https://devforum.roblox.com/t/introducing-overlapparams-new-spatial-query-api/1435720 Suppose you have PartA and PartB in workspace that intersect, but both are non-CanCollide (or only one of them is non-CanCollide): [image] You might know that the following call will not yield any results in that case: local results = workspace.PartA:GetTouchingParts() print(#results) --> 0 However, if you attach an empty Touched ha…

It’s not really that bad in terms of “hackiness”, just copy the function from the post and call it for your hitboxes. I can’t vouch for its reliability though as I have never used it.

For option 2, if your projectiles aren’t too large, you could use multiple rays instead of one. Have one ray at each corner of the projectile. Any projectile wider than 1 stud will probably need one in the centre as well, or maybe more depending on the size.

As for performance, I’m not sure which one would be better. You could do some experimentation to figure this out. I would assume the ray method would be faster, but I could be wrong.