question about antilag

Yes the ‘anti-BS’ code is BS. In many ways…

		trap_Trace( &tr, start, mins, maxs, other->client->ps.origin, passEntityNum, contentmask );
		res = G_SwitchBodyPartEntity(&g_entities[results->entityNum]);
		POSITION_READJUST

That trace doesn’t put its results into ‘results’, so the SwitchBodyPartEntity is pointless. Res already got set above. POSITION_READJUST is similarly pointless…
GG cut & paste.

Never mind that POSITION_READJUST repeatedly calculates ‘dir’ from fixed inputs…

BTW (for anyone following from the sidelines), all the stuff in this thread except for the backumarker thing exist in RTCW too.

I should add that if you fix backupMarker.serverTime so that the original position is restored, you’ll need to re-antilag the shot for the headshot check, or the head will be attached onto the non-reconciled position. We overlooked this at first.

Aight. We’ve been there, done that with the UrT antilag.
How ET is doing it now, is how UrT was doing it during the 2.x era. Its bad.

Four Things:

1. Get rid of the anti BS code. It creates more problems then it fixes.
2. Store the client markers in ClientEndFrame() - this is their position right before the snapshot is generated, therefore it is where the clients are seeing players.
3. Store the client markers with level.time as the timestamp. NOT some weird gettime timer thingy. Level.time is the time of the position in the snapshot. which is what we want.
4. use cmd.servertime for the lookup of the shots (probably already is)

there are no +50ms -50ms tweaks needed.
Anyway, storing the position each client cmd is about the worst thing you can do. it makes hitting hpb’s harder, and it makes hitting people with differeing ping a different experience.

IF you want any more info on this I can be contacted at TwentySeven@urbanterror.net or just post your questions here.

I might even cough up how to do antiwarp. (and no, not that insanely complex stuff in neils unlagged mod, either)

zinx already worked out antiwarp for etpro… curious to know how you implemented it though.

this is basically a 1:1 description of neil’s original unlagged1.0 / 1.1 code from way back when (and what I used in banimod wayyyy before it was ever introduced into rtcw).

has UrT diverged from neil’s unlagged code in any significant way?

i’ve got unreleased unlagged2 code from neil i should dust off and look at putting in ET…

Neils code in unlagged 1 worked the same way as ET’s does. Stores it on the incoming cmd’s.

I think neil might have fixed it for unlagged 2 but we went over to a fresh implementation.

As for it being different… I’d have to check. The biggest fixes from unlagged 1.1 is using level.time as the marker, and storing only at the EndFrame.

Our antiwarp works differently, yes.

How ours works is each server think, if a client is “late” with cmd’s, we generate an empty one (sans buttons that need holding down like priming a grenade or climbing a ledge), and feed the cmd in with a timestamp that’d keep things reasonable. So clients are forced to run at least one cmd per snapshot, thus, the warping client will feel a tiny bit of “ropeyness” as the difference in prediction kicks in, but to everyone else he doesn’t warp.

Its benefits are that
A) it moves the onus of a client warping to the warping client’s side of the connection- it doesnt affect other users.
B) there is never a “pause” like in the etpro stuff, a client can’t just freeze in mid-air waiting for new cmd’s.
C) it has no “ping buildup” like the current etpro stuff describes.

Also, just a quick bit of history

UrT had its own unlagged stuff written by apoxol in beta 2.0, predating neils work by almost a year.
during 2.4, dok8 switched out the urt stuff for a version of neils 1.1 code, which worked better for hpbs but was broken for lpb’s shooting hpbs and lots of other issues that plagued us all the way through 2.4 through to 2.6a.

During 3.0 dev I tossed the whole lot and wrote a fresh implementation, also implementing a debugger (g_antilagvis 1) - it places a marker clientside every time you fire a shot for rendered clients, and then sends down an ent of the history lookup during the shot check on the server.

It’s never off by more then a couple of game units, even at our zippy player speeds/model sizes.

FWIW, the unlagged 2.x source is available from http://www.planetquake.com/alternatefire/

Although I have not gone through it in detail, it seems a lot more solid than the ET/RTCW code, and includes various debugging stuff as well.

It also has some documentation which I highly recommend any would be ET modder read.

we tried this approach the first time around and it didn’t work very well at all. too many clients are too often late with cmds and find it too difficult to play with all the prediction error. most people have crappier connections than you would think. basically forced server thinks made the game completely unplayable for an entire class of players. we couldnt simply tell them to go away.

zinx came up with the current alternative when it became obvious the forcing server thinks didn’t work so well.

i had a look at the antiwarp in unlagged2 and it didnt look all that complex to me? :???: :???:

I think what I should have written was “needlessly complex”. My appologies.

I don’t think I’ll get into an argument about this.

You appear to be happy with your implementations of both antiwarp and antilag, so I’ll just leave it at that.

Hell, everyone knows the UrT hit detection is crap anyway.

Not completely bug free, however…

code/cgame/cg_unlagged.c: around line 86

						c->currentState.pos.trTime = TR_LINEAR_STOP;
						c->currentState.pos.trTime = cg.snap->serverTime;

I suppose the first is meant to be trType

i’m not happy with antilag, in fact i just put the unlagged2 code in

just curious how you deal with the client prediction error from antiwarp, since by forcing clientthinks on a server for missed commands, you’ll get that. clients with genuine packet loss will find it very hard to move around.

neil’s antiwarp is rather interesting, if you’ve looked at the code. it appears to deal with antiwarp in a way that doesnt have any client prediction error at all.

wahaha, nice. probably harmless if trType is already TR_LINEAR_STOP as I suspect it would be…

I’ve gone and had a rummage around neils stuff from unlagged 2.01. I was completely wrong about the “complicated” part, the source I checked ages ago was a mixed client/server hybrid thingy that made my flesh creep. Its fortunately not like that anymore (Sorry Neil!)

Since then, he’s moved it serverside and does a check for late cmd’s as well (good!), as opposed to only acting when cmds finally arrive (bad)

Nice things:

• A late client gets ent->s.pos.trbase “predicted” each snapshot they are late for. So, he extrapolates their physics but not their cmds - it’s like they let their hand off the keyboard to other players. He leaves the ent->s.origin alone though, so the “bad” client doesn’t get a prediction error.
• He stores the antilag trail after this prediction, so that when the history lookup is done its done against what was sent in the snapshot. So provided that antilag looks up the correct client view time (he doesn’t… but I mentioned the fix earlier - use the actual cmd.servertime not the msec thingy ), you should be able to “hit what you see”, new extrapolations and all.

Bad Things:

• Warpers due to things like flooding their upstream (kazza) often go for 200-500ms+ periods with no cmds. While they’re not sending cmds, they’re still moving and hittable - yes. Unfortunately, processing the torrent of cmds that arrive after the “warp period” still causes the player to teleport, and that can be a fairly significant error. Take the case of someone running on an arc near a large drop… and continually being “predicted” of having slipped off the edge…

So… The “stop” part of the warping is gone, but the “speedup” at the end isn’t. Upstream flooding is still a viable way to make yourself hard to hit, which is the really ugly side of gamers, not just poor dudes with bad connections.

Anyway, the only real difference between Neils and my own is that our physics extrapolation is authorative (predict errrors for the warper, no errors for the other players), and we provide an adjustable tolerance serverside before a prediction is done.

Most of the time a causally “bad” connection - like when PB is scanning, can cause about one maybe two “one cmd” corrections per second. Generally once play settles down though most people do not trigger the UrT antiwarp code at all (I imagine the same is true for Neils).
Antiwarps there to stop people abusing q3’s good hospitality in accepting incoming client cmd’s to make themselves unhittable, so its worth it imho to go the “whole hog” and put the effects of an unstable connection completely on the clients shoulders.

i like our approach better as it doesn’t exclude an entire class of players from the game

lagged players are still at a disadvantage (‘ping buildup’) when they drop too many commands (bad) but they dont get the prediction error that causes them to run off ledges and run into walls when you run forced client commands (even worse)

players freezing isnt really an issue – its the warping off at mach 25 when their commands come flooding in :moo:

I’ve been adding some debug code the client (using the unlagged 2 stuff mentioned above as an example). In addition to printing various information, I added code to draw the bbox of the player where they were when the client fired. That seems to be working fine for the body. Now I’m trying figure out how to do the head + legs, and I’m not sure how to do it. I can reconstruct the mins,maxs, and position, but how would I make a client trace see them ? This is my first time really digging in the client code, so apologies if there is an obvious way to do it.

the simplest way to get unlagged2 working in ET is to just use the unlagged2 functions for backward reconciliation, and plug them into G_HistoricalTrace. That way you are able to use the existing code which builds the head and feet and does the traces.

it also gives you an easy way to switch between etmain antilag and unlagged2 on the fly so you can do comparisons – you can use a cvar to control which backward reconciliation functions are called.

Eh, while true, that wasn’t really what I was asking.

The code I’m talking about is the debugging stuff in cgame/cg_unlagged.c:CG_PredictWeaponEffects. Essentially it does a trace on the client, so you can compare the results of that with what the server got. With the boxes drawn in different colors on both, you get an easy visual indication of how far off the two are. The problem is that trace doesn’t know anything about heads and legs…

I think I can draw the head/leg box in pretty much the right place (since the view angles and crouch/prone state are known), but don’t see a simple way to predict hits that would only hit a head/leg box. Not a big deal, just wondering if there is a simple way to do it.

Interesting stuff chaps

I wonder if we should bring Rince from the urbersoldat bot mod into this discussion (they are making a open source bot mod for RtCW)
He has implemented unlagged into their mod (I don’t know if its based on the unlagged2 code though)
http://66.90.73.208/~flagman/phpBB2/viewtopic.php?t=33

I’ll make a post there and ask.

Hewster