question about antilag

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

First off I like ETPro, I use it for my ET pub server. But why should a mod whose purpose is to cater to the competative community (of which I’m not a member of for ET) strive to support a small class of gamer amongst its ranks. My clan competes in Urban Terror and I can’t remember seeing a modem gamer in a scrim or match ever. Urban competition was seeing a number of players lagging (whether purposefully or not) making them hard to hit. SID stepped up to the plate and made the game better for competition. (thanks.)

I can think of one guy that I haven’t seen play since the changes, he had a crappy connection giving him lots of packetloss. He was a cool guy too. Now it sucks for him that he can’t play the game, but it sucked for everyone in the community when he would strafe-jump out of someone’s base with the flag and nobody couldn’t hit him because he was litterally warping across the map. poof, poof, poof. It was also fairly easy to artificially create this condition for yourself.

This isn’t to say Antiwarp is perfect, there are still some issues from my understanding. I’d also love to see Anti-BS code if the complexities could be worked through. All-in-all Urban antilag, antiwarp, and hit-detection has made some huge strides with the 3.x series.

–
[e]Xamot: Just a gamer, but a professional software developer so I like to read this stuff.

Because elitism and exclusion sucks?

Because it’s possible to support everyone with a little effort?

Its not just modem players. Anyone with packet loss – even intermittent – will have problems. You can see this often on broadband connections, especially those like cable modems where you share your bandwidth with everyone in the same metro area.

By solving the warping problem, you make the game playable for everyone, instead of restricting the game purely to the domain of the 31337 LPB with the perfect connection. Antiwarp accomodates LPB with slightly-less-than-perfect-connection as well. And HPB with really crappy connection.

Why not support everyone when it’s possible to do so? To do otherwise is laziness.

Not trying to be elitist. If you do what you say you can do, supporting people with high lag, packet loss, and flux without them adversely effecting the game. Kudos! I’m not a game/mod developer I can’t argue the implementation, only that it sounded like ETPro would still suffer from some warping problems. If that were so and I was a person competing on ETPro I’d probably ask that it be changed. But if you have solved the problem so everyone can play and people can’t exploit the system, Great!

I can’t find in your web pages when you reimplemented antilag vs the etmain version (or has it always been there?). I’ll have to do some testing to see it in action and how it feels compared to 27’s approach to antiwarp. Up till now I haven’t paid much attention to whether ETPro servers had it on or not. The example server config I got from ND80 recommended turning it off.

Re-read 27’s post

Warpers used to get “frozen” and be “unhittable” then warp ahead and then stick again. Making the only chance you had to hit them only during their “warp”. Which everyone agrees is bad. Right? And why Antiwarp is needed.

If I understand the above statement by 27 and some of the rest of the posts. In both implementations they are now not frozen nor unhittable. But, the UrT player won’t teleport when a bunch of their packets flood the server and ETPro’s will. The trade off between these two implementations is that either the player warps to all the rest of the players or lags to himself. Correct?

Which is nice.

Nope. Dont know where you got that idea from.

Nope. No warping problems in ETPro.

Xamot, think of it this way, would you consider it OK if the software you developed crashed on certain PC hardware? Hey, only a small proportion of users would have that problem, who cares… Or maybe wheelchair access to public buildings isnt something worth bothering with even if the building is suitable for it, because hey only a small proportion of people are disabled.

Simply ditching people with non-excellent connections would be such an inelegant, unprofessional, arrogant and lazy response to the problem. Basically, thats just wank, and my impression of UrT has just nosedived somewhat simply for finding out the team would choose to do this. Even still, UrT can get away with it a little more easily, since its a TC, but ETPro simply being the way ET is played competitively, they have a responsibility for it to be OK for anyone who plays ET.

Have to allow for poor connections because of the same reason you have to provide for linux players, only much moreso.

Firstly, the UrT stuff doesnt “exclude” anybody.

It’s off by default, and it has a partner variable that allows a certain tolerance before it’ll even do mild (1 snapshot) extrapolations. Someone with intermittent fluxuating upstream or packet loss can just play on servers with it disabled, or play on servers with a higher tolerance set.

If it was only packet loss as Bani suggests, set cl_packdup 2 maybe even 3. Though it’s almost never packet loss, and players with True PL (red on the netgraph alot) can barely play Q3 based games anyhow - snazzy code fixes or not. Moot Point.

I play on USA servers in competion with a crappy 260 ping from australia, antiwarp enabled. I get stung while PB does the initial 5 minute scan, which is a q3 pb issue, not something in our software, and thats it.

For the rest of the play session the default antiwarp settings don’t even affect me. And I can tell because we mark when we do in the net graph with big black lines.

Neils implementation of antiwarp fixes the sticking not the zooming, but with no penalties to clients.
ETPRO’s fixes the zooming, not the sticking, and the clients ping “builds up” if things are bad.
The UrT stuff fixes both issues with antiwarp, the sticking, and the zooming. And players feel a slight “ropeyness” in their movements when they’re warping.

In extreme cases it becomes unplayable in UrT, BUT, in the same extreme cases I bet playing with a 999 ping and timing out is pretty unplayable in ETPRO.

I wouldn’t bash UrT too hard - we provided a requested feature for what UrT has become, a competition mod - for ideal match conditions for MOST of the people on the server, not just pandering to the one dude with a flakey connection.

And its certainly stopped people from uploading to “Fake” it.

Cheers guys

FYI: I’m not trying to bash ETPro only understand how it works with relationship to antilag/warp. ETPro rocks my socks and I do apreciate the hard work.

This is what I’m getting at. Why not provide these as server cvars and let the admins and Leagues decide? As UrT has done. The things are optional. Coincodently all three US UrT Leagues have decided to use the antiwarp code. I don’t think it is unreasonable to attempt to level the playing field for competition. More importantly I do think a reasonable effort should be made to prevent exploits of the game.

I confused Neils unlagged2 and the ETPro implementation. By sticking you mean when a person lags and freazes “mid-air”? By zooming you mean after sticking the person jumps ahead to where they would be without having been stuck? So in ETPro the person will appear stuck/frozen to both themselves and other clients? If so are they still hitable when frozen? Yes or no it does sound that bad, better than people being able to “create” packetloss so they move in spurts across a map.

But what does “and the clients ping ‘builds up’ if things are bad.” mean?

Again, I’m just being curious. I wish I had the time to mod myself and learn personally what these things mean. If these are “trade secrets” or you simply don’t want to spend the time explaining it to joe shmoe for the umpteenth time, I’m cool with that. I’ll still continue to use, play, and promote both ETPro and UrT to other people. Also I ask these questions not just for my own curiosity, but hopefully to benefit any would-be modders that read these forums.