Improved Hitboxes on FF?

[talcum]

The amount of labor theoretically required to port FF from Source to a Quake engine seems enormous. Suggesting a port right now seems totally unrealistic. However:

Originally Posted by squeek.

Quake engines scare and confuse me. I tried a few times to set up a development environment to mess around with for Quake 4 or Doom 3 or w/e and failed each time. Also, I believe the licensing requires that any derivative mods of the open-sourced Quake engines open-source their code as well. Not sure if that'd be a good or bad thing (maybe good?).

As cake mentioned, if a mod interacts only with the Q3/Q4 virtual machine, then it is not considered derivative. Changes to the engine (e.g. ioquake3) are derivative and GPL'ed.

Originally Posted by the_cake

Certain engines do a better job than others. Source is around the very bottom of the list. goldsrc, every quake engine, warsow, and CoD are examples of good ones.

Vanilla Quake engines have never had server-side lag compensation. They typically had good hit registration under imperceptible LAN latencies, though they included kludges like cl_timenudge, and though their model animations sometimes fell badly out of alignment with their hitboxes. But perceptible latency was always the player's problem. I think Quake Live is in a different category from Q1 through Q4 since, to date, nobody can mod QL or see the source.

Modders and engine maintainers have written lag compensation after id's releases. For instance, Quakeworld's maintainers added a lag compensation system that they call "anti lag", and Neil Toronto wrote a mod called Unlagged for Quake 3.

Even Quake 4 base does not have server-side lag compensation. If you are playing Q4 with 150 ping, you have to lead rails on a moving target by about 150 ms. I put thousands of hours into Quake, but I would trade vanilla Quake netcode on WAN for Source's or GoldSrc's netcode in an instant.

I used the phrase "server-side lag compensation" above. Based on what I've read by Yahn Bernier (Valve, GoldSrc and Source?) and Neil Toronto (Unlagged for Quake 3), here's what I think that phrase means. I first read about this around a decade ago and have only lazily followed new developments, so I may be out of date.

Recall that the server operates in discrete time. Consider tickrate in Source or sv_fps in recent Quake engines: these variables specify how many times per second the server will update the gamestate. As the server advances the gamestate in discrete time, it stores the last roughly 500 ms of gamestate snapshots. This is like the server remembering the exact state of play for the last half second. Whenever a client sends a shoot command, the server checks the client command timestamp, loads the gamestate reflecting that moment in time, and traces the shot against the state of the world as the client observed it. This is sometimes called backwards reconciliation.

Ideally, the server should then fast-forward to the current time to check whether the shot is still legal. This last step prevents the sensation of being "shot around a corner" by a high pinger, or even worse, being shot by a high ping enemy that you have already killed. This is still a real problem in modern games: see PlanetSide 2.

Note that this technique only covers hitscan weapons. There have been attempts to extend the technique to projectiles, but these approaches tend to result in projectiles effectively springing into existence at varying distances out of the barrel, often unacceptably altering game balance. Furthermore, every modern FPS game client does some form of interpolation and/or extrapolation between gamestate snapshots received from the server; fancy lag compensation implementations could potentially simulate the client's interp/extrapolation behavior.

[the_cake]

My opinions were based mostly what would work best for a fortress game in general; I realize it's completely unrealistic to port FF to quake at this point. Ideally you'd start fresh at that point anyway.

Your interpretation of lag compensation is pretty much correct. The interpolation latencies are included in the calculation. Quake never came stock with lag compensation (other than ql), but most servers since q3 ran unlagged. It worked pretty well. Also, if you have a really consistent connection, fixed time nudging actually works great (it's still present in quake 1/2).

Where server side lag comp tends to break down is when player latencies and update rates are inconsistent (ping jumping). Like you said the server tries to "rewind" the game state by whatever the player's latency is from the mouse click to the server message (ping + interp + whatever other internal latencies). The latency is where the guess work is. If everyone's ping was perfectly stable all the time this system would be perfect. Even with a good connection this isn't true; the server has no way to guess when player latency will change, instead it just makes the assumption that it never does. If the server can't get an accurate idea of where the player is aiming and where the target is located, the system breaks down. The negative impact of guess work is proportional to the target speed, hitbox size, and bullet size; which is why fast pace games have a harder time. This is why I support a system using client side in some way; the client doesn't need to guess. It knows where the player is aiming because the player is sitting right there, not 800 miles away.

In terms of what source does, no one really knows except the source devs as no one has access to the code. Almost everyone agrees something is broken though. This was one of the motivations for making the head hitbox massive in CSS; headshots were mostly random. Now they're consistent but tack on a million accidental headshots that shouldn't be headshots; this is why spray works so well.

[Dexter]

what do you mean no one knows what it does? it interps the best it can

[talcum]

Originally Posted by the_cake

Quake never came stock with lag compensation (other than ql), but most servers since q3 ran unlagged.

Most Q3 servers when I played ran OSP, CPMA, or RA3. Each of these had their own weird netcode-related tweaks, though CPMA's were probably the most mature of the three. No league or pickup channel I ever found used Unlagged, though there were such communities for CPMA and OSP.

Originally Posted by the_cake

Where server side lag comp tends to break down is when player latencies and update rates are inconsistent (ping jumping). Like you said the server tries to "rewind" the game state by whatever the player's latency is from the mouse click to the server message (ping + interp + whatever other internal latencies). The latency is where the guess work is.

I think this is true of GoldSrc since the client commands didn't include timestamps. Unlagged didn't need to estimate client latency because Q3 client commands included usable timestamps.

[the_cake]

All I did was pub q3, and most had unlagged. As far as OSP/CPMA goes, those had full on lag compensation right?

Timestamps don't help anyone much as the server still has to determine where in time your game state is relative to the servers. This changes every time your ping changes, even if only by a couple ms and even if interp is hiding most of it. If everyone's ping was perfectly consistent this wouldn't be an issue. Aside from seeing into the future there really isn't any way to know when someone's ping will change.

[Sabbath]

cakefixyourffthanks

[FDA_Approved]

ya

[talcum]

Originally Posted by the_cake

All I did was pub q3, and most had unlagged. As far as OSP/CPMA goes, those had full on lag compensation right?

None of OSP, CPMA, or RA3 used Unlagged. OSP and CPMA had some hacks related to client-side interpolation (sometimes called the "50 ms lag").

Originally Posted by the_cake

Timestamps don't help anyone much as the server still has to determine where in time your game state is relative to the servers. This changes every time your ping changes, even if only by a couple ms and even if interp is hiding most of it. If everyone's ping was perfectly consistent this wouldn't be an issue. Aside from seeing into the future there really isn't any way to know when someone's ping will change.

Not true. Q3 client command timestamps are synchronized to the server. Furthermore, they contain sufficient information for the server to tell how far the client had interpolated between two gamestate snapshots, regardless of the client's cl_timenudge value. If I recall correctly, these timestamps have 1 ms resolution. Unlagged's implementation actually copies the client-side interpolation code exactly so that the server can figure out just what the client saw when it generated the command. This approach is not affected by ping fluctuation. The only condition is that client ping stay within the bounds of history kept by the server (like 500 ms or 1 s or whatever). Client ping is free to vary under that limit without damaging Unlagged's fidelity.

With GoldSrc, I think timestamps were missing from the protocol. So I think GoldSrc used latency estimation instead.

[the_cake]

So lets say this happens:

1. Server updates me, everything is in sync
2. my ping jumps by 50
3. Server updates me again, but it arrives 50 ms late. I'm now 50 ms out of sync with the server time. Since there are no latency based calculations in this scheme, neither the server or client have any idea I've gone out of sync until the next client message.
4. I shoot something, sending a time stamped message, but message is 50ms late because of lag spike
5. Client updates server, back in sync, hit gets calculated. But now server has to interpolate between my gametime at 1 and my gametime at 4; in other words guess. We're just using gametime instead of ms; and now the server has to wait for a client update to have any idea what's going on.

This gets more complicated during short spikes where latency changes more than once between client and server updates. A 66 tick server updates once every 15ms. It's very realistic to have a 50 ms spike in there that disappears between client updates. So the server will basically have no idea. I know some engines can log updates between ticks which helps, no idea which game engines can; though I'm pretty sure goldsrc does as high fps servers seem to make a difference.

[talcum]

Originally Posted by the_cake

So lets say this happens:

1. Server updates me, everything is in sync
2. my ping jumps by 50
3. Server updates me again, but it arrives 50 ms late. I'm now 50 ms out of sync with the server time. Since there are no latency based calculations in this scheme, neither the server or client have any idea I've gone out of sync until the next client message.
4. I shoot something, sending a time stamped message, but message is 50ms late because of lag spike
5. Client updates server, back in sync, hit gets calculated. But now server has to interpolate between my gametime at 1 and my gametime at 4; in other words guess. We're just using gametime instead of ms; and now the server has to wait for a client update to have any idea what's going on.

This gets more complicated during short spikes where latency changes more than once between client and server updates. A 66 tick server updates once every 15ms. It's very realistic to have a 50 ms spike in there that disappears between client updates. So the server will basically have no idea. I know some engines can log updates between ticks which helps, no idea which game engines can; though I'm pretty sure goldsrc does as high fps servers seem to make a difference.

Your timeline is ambiguous and seems slightly confused. It starts with an impossible premise in #1: the client and server are never "in sync" in scenarios where Unlagged matters. In #3, you write that "neither the client or server have any idea I've gone out of sync". This is untrue. A Q3 client knows exactly how often to expect snapshots from the server, how long ago it last received one, and therefore how "early" or "late" an incoming gamestate snap is. The Q3 server also tracks, for each client, the last acknowledged snapshot from that client. Unlagged goes a step further to track the last frame during which a command was received from any given client (for skip correction).

You also seem to be writing about having a 50 ms "spike in there", where "in there" is a 15 ms interval. I think? It's not exactly clear how you want this to be interpreted. I think you're talking about a client receiving snapshots out of order. It's either that or the "spike" would be unobservable. Keep in mind that the Q3 server delta-compresses client snapshots versus the last snapshot acknowledged by each client. Out-of-order receipt of gamestate snapshots is handled on the client in much the same way as a dropped gamestate snapshot.

Unlagged's timestamping approach really does work. You may want a look at a mirror of Neil Toronto's documentation at www.ra.is/unlagged/ (the "Code Walkthroughs" and FAQ are particularly good). There is also a nice commentary on the Q3 network code at http://fabiensanglard.net/quake3/network.php, but it is not exhaustive and doesn't cover Unlagged. The best way to investigate this is through the Unlagged code at http://games.mirrors.tds.net/pub/pla...%5d.01-src.zip and a copy of ioquake3's source; if you are determined to see how this works, you can do so with those two source trees.

[XPelargos]

slow clap for talcum. Dayummm son!

[Dexter]

lame pissing contest about unrelated games netcode here

[the_cake]

Didn't mean for it to seem like a pissing contest and I don't think talcum did either, we were just discussing netcode in general as these principals apply to almost all engines. Unlagged is one of the better lag comp systems but my only point was it has it's flaws and could be better. Though this is obviously starting to head south so I'll let it be and you guys can have your thread back.

[KubeDawg]

It would be kinda cool to see a Quake style Fortress Forever as long as it's not super fucking fast gameplay like some of today's quake games. I certainly wouldn't mind seeing the Medic with a fucking battle axe, that's for sure.

[squeek.]

There are plenty of Quake Fortress mods.

Quake 3 Fortress (apparently died after beta2)
Enemy Territory Fortress (port/improvement of q3f on a different engine but still extremely Quake-ish; I know there's an active community for this as NeoNL plays it)
Quake 4 Fortress (never got totally finished?)

[KubeDawg]

Sorry, I mean a new game with amazing gfx and gameplay.

[FDA_Approved]

Originally Posted by KubeDawg

It would be kinda cool to see a Quake style Fortress Forever as long as it's not super fucking fast gameplay like some of today's quake games. I certainly wouldn't mind seeing the Medic with a fucking battle axe, that's for sure.

I mean FF is kind of already a healthy tfc/quake combo. And in terms of "todays quake" FF is already just as fast. Compared to stock q4 and ql anyways. In cpma at least the DM can get very fast with fast weapon switch, but that also has a lot to do with weapon/armor balance as well as map control. I believe movement is uncapped in cpma (no idea really, just assuming) But even then, with the way some maps are it's not very likely for you to be faster than FF standards

Tbh ETF is slow as piss nuggets. The acceleration at least. You can get up to a good pace, but quick acceleration via bhoping alone isn't viable. You need to rocket jump or nade boost. Or drop conc, because there's no HH.

I hate to say it but I don't really like "quake" styled fortress. It usually implies no HH concing, and that old QWTF style reload, where you have to reload every shot fired from a clip before being able to shoot OR switch weapons. (aka 1 rocket in rpg, can't just reload 2 and shoot 1, reload 2 and switch to shotty)

I've played around on listen servers with Q4F and it's certainly interesting. But it has the above mechanics, and there's no ramp sliding which is odd. But on the other hand you don't loose speed trimping, so you can bhop any ramp without loosing speed. It has the potential to play out fairly close to FF, but that reload style and no HH concs really turns me off.

[KubeDawg]

So going forward, what do you think would be a good new fortress game for the future, assuming it would be on the new SDK that is being developed right now?

[FDA_Approved]

FF with a few adjustments here and there. FF is close to my idea of a perfect fortress game. At least in terms of physics and some of the mechanics. Could maybe use some rebalancing of weapons, I certainly wouldn't be sad to see over pressure go. And while I like jump pads, I wouldn't mind nixing those if it was generally agreed for a better fortress. Maybe the spy could have a new toy, maybe...something based around movement. Something fun and different that plenty of new players could enjoy.

I would certainly love to see the sniper and pyro reworked. After burn as a mechanic needs to be dropped completely and forgoten about for ever. And the sniper needs to be reworked into a class that doesn't sit in spot away from the action. Because lets face it, sniping is the entire fucking problem with the sniper.

And yes I really do like FF. But I still strongly feel that the next logical step that has any hope of attracting any kind of crowd is a new game.

[Dexter]

Originally Posted by the_cake

Didn't mean for it to seem like a pissing contest and I don't think talcum did either, we were just discussing netcode in general as these principals apply to almost all engines. Unlagged is one of the better lag comp systems but my only point was it has it's flaws and could be better. Though this is obviously starting to head south so I'll let it be and you guys can have your thread back.

no worries, just poking fun and came off a little too serious..


anyway, with the way SDK updates are a ghost town, I hope valve pulls something outta their but for source 2 but am certainly not betting the house on it