swimming hitboxers are uh... nice... and more extrapolation!

[bani]

hey, give me some credit. i’m not that stupid

all testing was done on a remote server with >100ms ping.

[TwentySeven]

np np - never suggested you were stupid. Stupid people are beyond help

[_RW_FRED]

Hey Bani, since ETPro v 3.0.1, i have some problems of move with ur newest version. I looks like always suck on the ground when i move, not when i sprint. And other players can passthru me… My ping is always less than 30ms on servers that i play and other players have above 50ms of ping. It’s specially lazy, when I respawn with 5 or more players. Each player passing thru me is sticked in my body. These effects don’t occur with schrubet mod and with previous ETpro…

I’d tried many server with a ping less than 50ms and all ETpro 3.01 give me the same… Another effect too occurs when a player strafe and sprint together, the player disappears of the field of view, Grrrrrr

Maybe it’s your new unlagged code?

ISP: cable network 2.5Mb/s, ping average 28-38ms

Regards

[bani]

antilag doesnt affect player movement, only shots.

[Rain]

btw, water etc.

this is one of the clearest examples where server doesnt accurately know what client is displaying, because client plays whatever animations it thinks is best for a situation.

so player might be shown ‘standing’ in the water and server thinks theyre swimming horizontally, and vice versa. so the bb will have little bearing on reality.

its a legacy problem from rtcw and is the direct cause of one of the flamethrower invisible-flames bugs (client thinks muzzlepoint is underwater, server thinks its above water).

These situations aren’t even remotely related. :bash:

The server dictates all player animations* except for the foot shuffle while turning left/right.

• Well, it only dictates the animation number, which the client will then run at a fixed rate. The only case where it’s wrong is if you get a late start on an animation, e.g. you’re spectating, you switch to a new player who’d just killed someone (and the dying player wasn’t in your PVS), so the death animation plays from the start. Of course, the server has no data about the animations themselves, so the bbox is still often incorrect.

The invisible flamethrower bug happens because the client is more or less guessing where to draw the flames (since the removal of flamechunks from network transmission in early RtCW), and it’s not using exactly the same set of data/same code as the server.

[bacon]

Oh trouble in baniland ;o

[bani]

TwentySeven, what’s your average delta between cgame’s origin and the backward reconciled qagame origin in UT?

[TwentySeven]

Hi bani,
Anywhere from 0.01 to 5.0 units, never seen it over 10.

[bani]

yeah thats about what i get with the new code too.

i’m trying to figure out what causes the deltas and how to get them lower

misprediction we can’t do much about, and it’s obvious when it happens

but eg fp precision errors, clock granularity, network jitter, engine/qagame/cgame processing delays, client/server clock drift, etc. might be able to be compensated for.

[TwentySeven]

Yep, we went over to doubles instead of floats in a couple of places to combat level.time/cg.time -> float granularity issues.

The two important ones are for the calculation of cg.frameinterpolate and for the lookup of the antilag.

Floats stop being able to hold an accurate copy of level.time after only 24 hours of the server process being started.

[TwentySeven]

Also, glad that you’re getting sorted out with whatever was messin’ with your antilag.
What was the issue?

[SCDS_reyalP]

bani, I would also be very interested to know what your conclusion was on that strange ‘50 ms’ issue.

[SCDS_reyalP]

yeah.
fixing the unlagged bugs is pretty easy.
store the ent->s.pos.trbase in the lookup, not the ent->origin
store the trails at the very end of clientendframe() not where it is now.
store the current level.time as the timestamp, do not adjust it.
use the cmd->servertime as the lookup time, not the current frame timegettime() cmd lookup thing.

Ok, I’m gonna bump this really old thread, with an offtopic reply

Do you really want to store the ent->s.pos.trbase or actually evaluate ent->s.pos at the level.time when when you store ? Because in ET at least, I find the ent->pos.trTime lags behind the level.time in clientendframe by something over 50ms! The trTime comes from ent->client->ps.commandTime in ClientEndFrame.

This would appear to explain some variation between the backward reconciled pos and client pos (and maybe some other weirdness too). As far as I can tell, the s.pos.trTime on the server only gets set for clients in bg_misc.c:BG_PlayerStateToEntityStateExtraPolate.

This is only used if g_smoothclients is 1 (the default) If g_smoothclients is 0 BG_PlayerStateToEntityState is used instead and trTime never gets set at all (presumably because trType is set to INTERPOLATE, which doesn’t use the time.

I haven’t understood this enough to really get what is going on here, but something seems wack.

edit:
with g_smoothclients 0, this http://www.splashdamage.com/index.php?name=pnPHPbb2&file=viewtopic&t=8189 goes away, and unlagged2 style antilag works much better without any 50ms nudge.

edit #2:
turning smoothclients off also stops other player models from penetrating yours when they run into you. Smoothclients indeed

[bani]

edit #2:
turning smoothclients off also stops other player models from penetrating yours when they run into you. Smoothclients indeed

because g_smoothclients 0 prevents any player extrapolation.

[SCDS_reyalP]

[quote=SCDS_reyalP]edit #2:
turning smoothclients off also stops other player models from penetrating yours when they run into you. Smoothclients indeed

because g_smoothclients 0 prevents any player extrapolation.[/quote]
Yes. It seems to me that with smoothclients on, assuming the client evaluates s.pos created in clientendframe, it will extrapolate all the time, because the trTime is so far back. Hence, runing into walls and players, and generally being well ahead of the server (not to mention being unsmooth).

Am I missing something here ?

[bani]

I guess you could try passing level.time instead of ent->client->ps.commandTime but i suspect much weirdness would ensue.

[SCDS_reyalP]

Actually, I just tried that, and so far (only very brief testing on a LAN connection) the only difference is

• no 50ms wierdness
• no player penetration into other stuff.

Note, BG_PlayerStateToEntityStateExtraPolate is called twice, once in clientthink_real, and once in clientendframe. I only changed the call in clientendframe. Now, I’m not saying this is the right way to fix it (In fact, I’m pretty sure it isn’t), but the current g_smoothclients behavior is clearly broken.

edit:
BTW, neils unlagged2 gets rid of BG_PlayerStateToEntityStateExtraPolate

[bani]

i would expect weirdness on wan connections, not lan.

i know neil’s unlagged2 gets rid of BG_PlayerStateToEntityStateExtraPolate in favor of his own antiwarp code. i dont really like what neil’s antiwarp code does though – it causes big prediction errors when players lag.

[Korollary]

i would expect weirdness on wan connections, not lan.

i know neil’s unlagged2 gets rid of BG_PlayerStateToEntityStateExtraPolate in favor of his own antiwarp code. i dont really like what neil’s antiwarp code does though – it causes big prediction errors when players lag.

Can it be done such that the lagged player is penalized instead of having large prediction errors trying to deal with it ?

[bani]

penalized how?