os.clock() will keep bringing newer and newer times, eventually surpassing the first benchmark.
1 Like
Oh, thank you, I see! I got time to test and tested using this code to understand it better.
local StartTime = os.clock()
while (StartTime + 5 > os.clock()) do
task.wait(0.05)
end
print("finished in", os.clock() - StartTime)
DetectionInfo.Time is how long the attack/hitbox lasts, correct?
That’s correct.
keystrokes keystrokes
1 Like
wouldn’t you want to update the attachment every 0.1 (checkInterval) seconds rather than everytime it recieves a result? Pardon if I’m wrong here.
Hi, you said in your post that we should check the distance of the players hit on the server to prevent cheaters from passing wrong info on the server. But the problem is there’s a difference between what the player sees and what the server sees due to latency so even if the player was close enough to hit the player on his view the server would still ignore the request. One partial solution is to have a big margin of the minimum distance that the player should be in range but if we had a game where different player have different speeds then this approach is also flawed since a very fast player will have bigger delay than a slow player. Any solution to this problem ?
Woops, that should be outside of the hit detection. I’ll correct that.
1 Like
You’d only have to worry about that in games where characters go at speeds higher than 40 studs /per second, but even then, you can just increase the leniency for and against the player moving at a high speed, and set it back to normal when they aren’t moving quickly.
Here after firing the client, there should be a task.wait(DelayTime) OR add a + DelayTime to the while loop pre disconneection so it doesn’t disconnect the function before the hitbox has a chance to be made (I BELIEVE)
This < should be an >
Also some variables are global, when they should be local, i know it’s just an example and it doesn’t matter but it still triggers me for some reason, no hate, just some mistakes I found
1 Like
A bit late but magnitude would probably still be more performant effective for ground-level attacks and what not. You just need to specify the studs.
:GetPartsBoundsInBox might be easier to use, but…
performance > ease
Doesn’t magnitude detecct in like a sphere-type radius around the origin?
It can just be used to check the distance between two objects, disregarding any sort of particular shape or direction.
Which can be quite useful for like you know, attacks that get alot of people in a radius. For a regular punch though raycasting may be a better solution because you can take into account direction (e.g. starting the raycsat from the HRP and then 2 studs infront of the HRP’s lookvector to make sure the player is actually facing the target).
1 Like
So you’d use magnitude then Raycasting? Is that more performant than using Dot? Is magnitude more performant than getboundsinradius for aoe?
Magnitude is more performant than both raycasting and getboundsinradius, but raycasting is sometimes necessary when u need to take into account direction. Because let’s say you have that punching thing, it can also hurt a player who is not the actual target as long as they’re in the distance.
I’ve only ever need getpartsinpart and getpartsboundsinbox, every other method is sorta weird and kinda useless but who knows maybe you need it.
getpartsboundsinbox still has its uses though, for like a safety area for example.
1 Like
I doubt you’d even need performance for safety areas/zones so I just use the zone module for those types of things.
Would dot product not be better here? Unless raycasting is more performant I don’t see how it wouldn’t be better here ngl.
I have no idea how to use dot to be honest and it’s so weird, but both dot and mag would work and they probably use around same performance.
Dot might be more performant than a raycast so go ahead.
I just use raycasting cuz imo its easier to use for directional stuff.
For safety areas it dpeneds on what type of detection you want, some people might not care of it’s slow detection so they’ll just use .Touched, but if it’s really important then you might wanna use a spatial query of some sorts.
1 Like
What if the hitbox is in the shape of a box? Or any shape that isn’t a circle? You could still try using some complicated math to try roughly get those shapes, but at a certain point the time investment isn’t worth it.
Given that the client already has plenty of processing power to use, it’s not going to have a massive preformance impact unless we’re casting spatial queries every frame.
1 Like
Well, in my opinion it’s not much complicated.
The only time you may need it is for like you said, if you want a player to actually VISUALISE the hitbox. Other than that? Nah not really.
2 Likes
Update: Fixed the raycast code segment to actually use distance. Oops.
1 Like
Why not have
client input , client hitbox → server sanitization
Only 1 delay, same smoothness.
Really comes down to the developer’s preference. Client-side stuff is far easier to exploit, and what’s often overlooked, very easy to steal. Especially for PVP fighting games, since the attack logic is the most critical thing.
It just sort of depends on what you think the average user will have for their latency. 30 ms is roughly a 0.06s delay to go client → server → client. I think it’d be better to do this in big games where there’s plenty of servers and you’re concerned about people trying to rip off your game.
Smaller games with less players will often have players at higher latency as there are less servers and therefore less likely to have nearby servers.
1 Like