Optimal method for client hitbox validation

[idle nymph]

I have a client sided hitbox that fires a remote to the server when the hitbox detects an enemy player. As commonly used, I do a magnitude check between the player and position of the target. However, I’ve noticed that the distance check between the player and target is much larger than what the client claims. Naturally, this is expected because the client and server will almost always have some sort of network desync. Yet, when I test in studio the distance between the player and target is still significantly larger than what the client sees. This discrepancy is even larger when the player moves at higher velocities. Unfortunately, I don’t think this is a lag compensation issue so I am confused about what methods I should put forth to validate these large discrepancies. Additionally, I should mention that I tested this on a still target.

[junior fjord]

ur latency must be buttcheeks

[idle nymph]

lf assistance 💔

[minor fossil]

wdym almost always?
fixed: almost Always

it is very much lag compensation

[minor fossil]

Yet, when I test in studio the distance between the player and target is still significantly larger than what the client sees.
this is a good observation.
Essentially, roblox has a physics replication delay separate from latency. it serves a bunch of purposes, but main thing to keep in mind is that remotes will always be 'faster' than physics replication.
In this recording, the blue trail is created by the server based on physical location (and keeps some history behind it), meanwhile the purple part is set via firing a remote with the localplayer's current location. As you can see, I am controlling player2 on the right, and player1 is in the center, and server on the left. The server always sees player2's character exactly where it physically thinks it is, but the purple block is in front of the physical location. Player1's perspect is a bit more interesting because the character is often slightly behind the server's physical representation, while also the purple block is in front of the physical character. and for the player actually in control, all parts are always behind the characters physical location as expected but the purple block is in front of the trail.

so from this you can draw the conclusion that physics replication has an internal delay regardless of network latency, and remotes are not subject to this delay

certainly makes things interesting, doesn't it?

and what's even more interesting is the reverse can happen too - where the server thinks the player is in front of where they actually are based on external factors, like parts which are moving on the server and interacting with the player

so for your main question: "What is the optimal method to deal with these latencies?" and the answer is there isn't any one optimal method

latency is always a bitch no matter what you're making. you can move the latency, you can hide it, but you can never eliminate it outright.

Server Authority attempts to address these problems by using rollback netcode, server authoritative movement, and clientside prediction.

these help to hide and move the latency, but the latency will always still be there - think getting shot in csgo. occasionally you can still be hit for a short duration after ducking behind cover. this is lag compensation in action where higher ping players shot at you in your past, but in their present, and this short delay ends up with you taking damage behind cover.

if you want more information on this, google for lag compensation, roblox's server authority, and clientside prediction 👍

oh and one more of those physics latency tests just for fun.
If you haven't built these for yourself, you are not at all ready to attempt any kind of "optimal method" for lag compensation when you don't know how to visually demonstrate said lag in the first place.
Like jumping off a cliff and expecting to learn how to fly on the way down, you need to conduct your own studies and research like I have, and develop your own understanding of how things work instead of relying on another's "trust me bro".

i have more but i think that's enough

[idle nymph]

Unfortunately, I have been testing this issue for a long time. Something I've noticed is that the internal delay decreases as ping increases. I have made a somewhat reasonable server side validation but it is not without its own faults.

[idle nymph]

It definitely seems like the best option here. Im currently in the process of implementing custom replication by modifying the popular Chrono resource, but it also falls behind the player at certain velocities. This is to be expected of course because you cannot accurately poll positions and expect them to align with the time of the hitbox detection.

[jovial pebble]

on player 1's screen player 2 is slightly behind the servers position but why wouldnt the server replicate the trail and the character at the same time? Does the server do some extra steps for the characters?

[minor fossil]

that's an exercise left to the reader

[jovial pebble]

oh

ok ill think about for a little while longer

[minor fossil]

build these tests yourself, they're very simple

if you don't know how to build them, well maybe good practice to start learning how to code things

[jovial pebble]

yea ill give it a go thanks

[jovial pebble]

yea I just had a go and the block is slightly infront of the character could it be that when the server replicates the part and the character the client maybe interpolates the characters positions so its a bit more smooth maybe thats why theres a slight delay?

[minor fossil]

it could be, may be 🤷

[jovial pebble]

hmmm okkkkk

[shell forum]

One thing i tried when hitboxing is taking the HRPs velocity and minusing it from the hitbox position, maybe u can try that

Basically by predicting the latency

[idle nymph]

Ah you mean like predicting forward? How accurate can you say this method is?

[shell forum]

If you do it right, it's what most games do

[shell forum]

Its honestly simple to do

And nice

Im sure a library would help a lot of people

[idle nymph]

That would be awesome to check out, please let me know!

I assume this is done with raycast

I forsee difficulty with integrating this along with lag compensation

[minor fossil]

this is not good advice

[minor fossil]

they do not.

[minor fossil]

it is extremely inaccurate because player inputs are chaotic. velocity prediction never works well.

[shell forum]

What do you recommend then

[shell forum]

Just predict the velocity on the SERVER

[minor fossil]

what rabbt said is fairly on point

[minor fossil]

ya you can't use velocity for prediction

at all

[shell forum]

Ian even said prediction

Im talking about js subtracting the velocity itself

[minor fossil]

you cannot use velocity for prediction

[shell forum]

If someone is going straight how do you do the hitbox if they punch

[minor fossil]

no you don't get it

players aren't always moving straight

if someone is tapping a and d quickly, your velocity prediction? completely wrong.

[minor fossil]

i realize you don't know what you don't know, but i assure you, you cannot use velocity for prediction.

[minor fossil]

i suggest doing some research of your own if you want to properly understand why

[idle nymph]

I think its a good diea but will it work well for melee combat

[minor fossil]

yes, they described a form of rollback netcode

roblox does something similar in their fps template game. instead of doing full rollback netcode, they let the client decide when and what they hit and the server does some very rudimentary checks to validate the hit, but is still exploitable.

e.g were you aiming roughly in the direction of the other player

it's not the best but nothing ever really is when it comes to lag compensation

[shell forum]

It isnt the worst thing

[minor fossil]

but yeah, definitely do not even bother with velocity prediction

[shell forum]

I used it for the punching thing

It works fairly well

[minor fossil]

it's just too wildly inaccurate to be useful for anything outside of 10ms ping or less

[shell forum]

Topped with distance checks and other things its hard to exploit

[minor fossil]

which is almost never going to happen on live servers

it gets more inaccurate the higher the player's movespeed is

so uh

[idle nymph]

How about intead of velocity predicting a cframe forward we just increase the window of leniency based off velocity?

[minor fossil]

idk you can chase this guys dream of velocity prediction being enough when it never will be, or you can build something proper 🤷 up to you

[shell forum]

How? Just track their velocity on the server and add a decently big hitbox

[idle nymph]

I really do want to build something proper but it's geniunely difficult to gauge what distance of stud error we're allowed to use because of roblox replication

[shell forum]

I do something in between those

[idle nymph]

I see the value of Rabbt's form of server validations for an fps game for sure

[minor fossil]

i mean bro if you want to use velocity prediction in your game despite now being fully informed that it doesn't work, you do you bro

[idle nymph]

but for fast paced combat i feel like it will miss a lot more often

because casting a ray from rewinded positions works if the server is accurately recieving those positions

pyro as you've said roblox has an internal delay for positions replication

[shell forum]

Im just saying it seems to work well many people told me to do it when I asked 6 months ago before i was banned

Take the velocity add it onto the hitbox

[minor fossil]

the people who told you to do it had no idea what they were talking about

[shell forum]

Ez pz

[shell forum]

So its absolutely hectic and inaccurate

What do you suggest?

[minor fossil]

yes

player inputs are chaotic, that's what i mean when i say that

e.g if player is holding w, throws a punch then immediately stops moving on the next frame, the hitbox from velocity prediction will be far in front of the character, much further than they will ever actually move to.

it's just plain and simply not good enough to be useful for anything

i've told you this like 5 times now. it doesn't work because player inputs are chaotic.

idk how else to make this easier for you to understand 😐

[shell forum]

I understand but you cant just have the hitbox last a little longer AFTER player movements?

If you make them happen after the player stops?

[minor fossil]

no

for the 6th time, velocity prediction doesn't work because player inputs are chaotic

[minor fossil]

im not saying it a 7th time, do your own research

[digital ember]

** You are now Level 9! **

[shell forum]

Spatial queries are not efficient wtf

Direct query is better

Only reason ive found to use spatial query over direct query is im too lazy to code a direct query

Like 5x5x5

I use spatial queries when hitboxes dont need to be accurate

I use direct query when they need to be accurate

I have only needed to predict velocity with spatiak query

Thats just stupid

Just get the bullets position with its last position realistic and less load

Thats what people do tho?

How does that have overhead raycasts are efficient as fuck

Theyre so incredibly efficient

No

If youre gonna have bullets use object pooling

Then u can raycast every bullet ultimately lag will happen in an fps game you just need to prevent it

Nonono

Also do it all on the client

Bulets can exist on the derver cuz objecg pooling makes it efficient

But the hit detection itself obviously do it kn the client

Thats basic knowledge ofc

Nah use both

Hit detection on client then verify it on the server

The entire bullet everything shouldnt be donr on the server it should be done on the client then validatedby the server

Yeah everyone does that

Same thing with melee

Any hitbox in general