Raycast-based (ClientCast) hitboxes (currently using this one) or part-based hitboxes?
3 Likes
Depends entirely on your use case. That being said, almost every use case that isn’t a melee-weapon would probably be better with a Part-based hitbox.
I’ve noticed that a lot of developers use part-based hitboxes for melee combat (like martial arts or sword fighting), and raycasts for ranged attacks such as Bezier curve projectiles. I’m currently working on a sword combat system. Do you think I should continue using a raycast-based system? It has good hit detection but less optimized i think, well i didn’t tried really good part based hitboxes, my experience is hitboxes with .Touched function, that enables on attack, hitbox was on sword itself, it was awful experience
I haven’t tested it, but an event based system like what you’ll get from using .Touched will likely be far more costly and it will be deferred, so you’ll have delay in your attack, if even only for about a frame.
It is far better to use a raycast based system for most any active collision checks, .Touched would really only be useful for passive situations. Because raycasts are instant it’ll be faster and you’ll get way more information to use related to the collision for use in determining the result of a collision as well.
What’s with the “Touched events are bad” stigma on here?
Touch event performance is pretty good, it’s something the engine already computes, and at most it’s behind by one frame from spatial queries at detection. Sometimes it’s even a frame ahead as it detects collisions that other methods would not be able to, as the part might be not visibly overlapping.
Of course, if you’re doing some instant hit checking where you’d want to be able to query hits immediately, spatial queries/raycasts would be better.
But for general melee weapon hitboxes, Touched will work just fine and be more performant (as you’re not constantly querying hits).
1 Like
It isn’t better to use :GetPartBoundsInBox instead of .Touched event?
Depends on your use case, if it’s for something like an AoE attack that just needs to query once immediately, then yes.
Otherwise, no. It’ll be more expensive for practically no benefit in most circumstances.
1 Like
Sorry that the question is off topic, but since you are an experienced developer, I would like to know if you know how to fix the problem that changing Mesh textures on mobile devices is displayed with a bug that the Part itself becomes visible for a couple of seconds without Mesh, on PC devices everything is OK
So for example we have mesh textures
local textures = { -- Slash
'rbxassetid://8821193347', --1
'rbxassetid://8821230983', --2
'rbxassetid://8821246947', --3
'rbxassetid://8821254467', --4
'rbxassetid://8821272181', --5
'rbxassetid://8821280832', --6
'rbxassetid://8821300395', --7
'rbxassetid://8821311218', --8
'rbxassetid://8896641723', --9
}
and here is the code that changes it on slash mesh
local count = 1
local connection
connection = game["Run Service"].RenderStepped:Connect(function()
m.Mesh.TextureId = textures[count]
count = count + 1
if count > #textures then
count = 1
connection:Disconnect()
end
end)
If you want i can show you the issue on video if you can try to help me with it
You might want to preload the textures using ContentProvider:PreloadAsync().
If that doesn’t fix your issue, you should create a new topic, and we can continue from there.
Sadly it didn’t help, here’s a new topic
In fairness, I didn’t say they were bad. I just don’t like them for the use case asked due to the drawbacks. The delay from being deferred being a big issue for me, but I also just don’t like managing a connection to an event just for melee combat.
If I trigger an event via input like a mouse click, I expect to run the check in that thread and return a result, at most keeping that thread alive for a few frames to run a sweep check with the animation, but at the end I would expect a result.
I don’t really get that with a .Touched event, as I either need to set it up inside the input event to then keep alive for X time and disconnect (unnecessary overhead in memory and set up cost) or I set up once and keep a constant track of the connection (this forces unnecessary state management) and flag when the .Touched event should react to hits with a boolean lock, which would also require state management.
Unless you really need it, it’s just a less ideal solution, but that doesn’t mean it’s bad.
This topic was automatically closed 14 days after the last reply. New replies are no longer allowed.