Another snippet lovingly thrown at my door by coder guru arQon from the Promode team, this time regarding cl_maxpackets and com_maxfps settings. Now I've been using the settings he hints at, 100/100, along with 0 timenudge for between six months and a year now, and the difference was quite marked at first and has certainly improved my consistancy over time. It's very noticeable with rail, but then coming from a Quake 2 background I'm the type of player so rail dependant that I'd notice it quicker.

Either way, here's the mail in full, enjoy.

> and cl_maxpackets give you the ability to send an update every frame or
> every 2 frames, 3 frames, or 4 frames (and so-on) which means that the
> amount of packets you send is still roughly connected to your frames per
> second.

Yeah, pretty much.

> If this is correct, someone receiving (and capping) at a constant 125 fps
> (com_maxfps 125), with maxpackets 100, is sending 1 update to the server
> every 2 client frames - i.e. they receive no difference in connection as
> someone with settings between cl_maxpackets 63 and 100 (inclusive) so long
> as their FPS remains constant - they will always send 63 updates to the
> server a second. IOW, for com_maxfps 125, cl_maxpackets 63 = cl_maxpackets 100

FAIK, yeah. Conceivably, it could slice them as half 1-move (see below) and half 2-move, but I've never really looked into it.

>My OSP
> servers set the lower limit on maxpackets @ 30 and I'm wondering whether it
> would make sense to change that to 35.

Maybe, but I doubt it. Mini-explanation to follow...

> I know that you roughly follow the European Quake scene and you'll probably
> know that one of the biggest problems we're facing atm is "le warp". I'm
> told that this warping is unintentional and most likely their ISP's fault

Usually.

> but it's a popular opinion that players can cause themselves to warp or
> become harder to hit by using poor network settings

Up to a point, yeah, but as long as it's over about 25 it shouldn't be much of an issue, if at all.

Here's the deal: what you send IN those packets are your moves. What maxpackets does is divvy up those moves into chunks. So at MP 60ish, you get two moves into each packet; at 40ish it's 3, and so on, but *you always send the same number of total moves regardless*. Higher MP "feels better" (especially for LPBs) because it means the *server's* getting updated more frequently, so you and it have views "closer" to each other, which is always a good thing: it's analogous to the improvement that higher sv_fps from the server to you brings.

It's all about the MOVES, and those are 8ms apart, so even at MP 25 you're only getting 3 per packet. In VQ3, a 320ups snail is going to move a whopping 13 units in that time, which isn't even half a player width.

The only advantage to low MP is that you save the UDP framing overhead of the extra packets. Frankly, that overhead is absolutely tiny, and given how much of the *upstream* Q3 conn is empty, nobody should be using 30 except for the most horrifically bandwidth-challenged.

IIRC, the upper limit of 100 rather than 125 is id-enforced by the exe itself. Interestingly enough (and I can't believe nobody's tried this yet)that may well mean that maxfps 100 would actually provide the optimal c/s sync.
It would take someone with iX-class skills to tell if it had any real impact on pmove_fixed movement or not: there'd definitely be SOME differences, but 125fps has been damn close to redundant for CPMA/OSP since January.
The best people to see if it makes a difference to the sync are the LG gods, in the same way that going from MP 30 to 60 affected the LG most.
/me cc's four more people... Daveleon is the ideal guinea pig for both. :P

Where low MP makes people skippy is basically just "unlucky" timing between the most recent moves arriving from the player and the server's most recent snapshot to the other players. Player movement is OOB - it's dealt with as soon as it arrives; it's only that it doesn't *update* back out to everyone until the next snap. So if you have one of those packets delayed by even 25ms (pretty common - my SHIT conn has a flux of about 60ms even to servers I ping <30 to) then you'll get a server frame at t then 6 moves applied to it at t+5, which is the reality. So if you use smoothclients and/or -ve TN on YOUR client, you'll have them pseudo-predicted quite a long way off in one direction which may well not be the right one: if they're dodging around, there'll be a noticeable amount of correction when you get the next snap.
In case it isn't obvious, this is something else that higher sv_fps improves (though only up to a point).

> I don't have an opinion on this myself - I accept that when I miss it's
> because I missed (or I blame my ISDN connection instead :oP) but I've had
>one or 2 causes to think about this. I've recently persuaded a modemer
> friend of mine to try CPMA (he still plays Q2) and I got him to use ix's
> settings - rate 3000, cl_maxpackets 30, etc. and unsurprisingly, he really
> warped quite badly until he raised his rate to 4300ish. Modemer's settings
> = modemer's warp ?

Yes.

If you tell Q3 to treat your conn like it was dialup, then (duh) you get the equivalent of a low-pinging modem. That's why we HAVE things like maxpackets_min in the first place (and CPMA has had min rate enforcement as well for at least a year - can't remember if we ever ported it to OSP).

What it boils down to is this: Carla's favourite rant. That *competition* servers are still running with modem settings is ridiculous. Unless you're Blokey or iX, you've got NO CHANCE of being able to compete on dialup anyway, and you can forget about team games completely.
(Exceptions apply for skill games like CPMA DM; or if you're iX and it's CTF, in which case you can warp at 900ups and be completely unstoppable as a flag runner. :P)
We generally don't need to enforce client settings too much because deliberately gaying your conn generally hurts YOU even more than it does everyone else, but if you've got people who have a "make me unhittable" bind (not uncommon for RA3 snipefests here) then yes, there are ways to block some of those. For the truly determined though there are plenty more ways to crap out your conn if you really want to, so it seems rather pointless.

99 times out of 100 though, it's just a shitty conn/ISP. If there's a router between the player and the server that's overloaded; or prioritising TCP over UDP because some newb netadmin reckoned it would make web pages load 20ms faster, then you're shafted.

> I want people to enjoy playing in my TDM league (without making it UK only)
> so... what timenudge/maxpackets settings do you recommend I enforce?

Whatever CPMA sets as the default, except for maxrate which id have hardcoded as something stupid and is covered in the last Carla update.