ET clients extrapolate even when they shouldn't be ?!?

(SCDS_reyalP) #1

In etmain, if you run into a wall, the client bounding box actually penetrates the wall by quite a bit (up to 1/3 a bbox width):

This on a dedicated server, both clients on LAN, top of lagometer blue. It is very reproducable. Of course, a moment later, the model snaps out of the wall. This is not too obvious in gameplay, since the snap out is pretty quick. However, if you watch it in a demo with timescale .1, it is very, very obvious.

I’m pretty sure this explains why my efforts to debug hit detection showed clients using positions ahead of the most recent avialable on the server. I suspect this is the same problem bani saw with antilag. The client, even when it thinks it is interpolating between to valid snapshots, is actually extrapolating ahead. Why, I have no idea.

:moo:
Or am I smoking crack ?

(Rain) #2

A couple of thoughts:
The entity positions sent for other players are snapped.
While the player positions are lerped, the bbox trails aren’t–I think it’s possible that you’d see a player halfway to the point in cg.nextSnap while you still only see the rail trails from cg.snap.

(SCDS_reyalP) #3

that’s not a rail trail. It is just some polygons added in CG_Player, using cent->lerpOrigin as its origin. In other words, it’s as if I just made a player model the size of the players bbox.

(bani) #4

this wasnt the problem i was having with antilag. my issue was something different totally – my debugging code was grabbing the cgame player lerporigin too late (hint: cg_fireweapon() is too late) when comparing to the backward reconciled server position. once i got everything sorted out i was able to get cgame-qagame deltas down to the same accuracy as UrbanTerror’s antilag.

you might want to add debugging to see if cgame thinks it’s having to extrapolate. it wouldnt suprise me.

(SCDS_reyalP) #5

Ok, that make’s some sense. I put my hit debug code in the same place, since neils unlagged 2 has something similar there.

So that means that the 50ms shift we played with in testing was wrong ? It certainly seemed to work better.

once i got everything sorted out i was able to get cgame-qagame deltas down to the same accuracy as UrbanTerror’s antilag.

you might want to add debugging to see if cgame thinks it’s having to extrapolate. it wouldnt suprise me.

I’ll look into that.

(bani) #6

Ok, that make’s some sense. I put my hit debug code in the same place, since neils unlagged 2 has something similar there.

So that means that the 50ms shift we played with in testing was wrong ? It certainly seemed to work better.[/quote]

the 50ms shift is still required for reasons which still arent entirely clear.

the real problem when debugging antilag/unlagged is grabbing the lerporigin at the proper time. grabbing it at the proper time gives reasonable deltas vs server reconciled positions (average 0.10 - 5) instead of the unreasonable crap you get from cg_fireweapon (average 15-30).

if you print the client time when you grab the lerporigin in cgame and print what time the server receives in the usercommand, it becomes pretty obvious what the problem is.

(mod3m) #7

my problem was with the bounding box/player actually going through the ceiling. this also happened on the walls too. some weird in water things happened too. i finally just added code to the check/jump code to make sure there’s no wall, if there is, stop. i don’t understand why it wasn’t already in though :confused:

my friend plexi actually wrote this up. it clears alot of errors in the jump code.
after pm->ps->groundEntityNum = ENTITYNUM_NONE; in PM_CheckJump in bg_pmove.c,


if (pm->ps->velocity[2] < 0 && 
	DotProduct(pm->ps->velocity, pml.groundTrace.plane.normal) < -0.1)
{
	// pmove.velocity is pointing into the ground, clip it
	PM_ClipVelocity (pm->ps->velocity, pml.groundTrace.plane.normal, pm->ps->velocity, 1);
}