Two questions, one belongs in client talk, but two posts for this is a bit overkill:

1) Client side lag has been forbidden by the default KTX settings for quite some time now. What is the reason for this?

2) Why doesn't Ezquake honour the client side lag disable fpd bit?

In response to 1) I *think* its because clientside lag gives a more stable connection than real lag would, and thus faking a high ping does not give the same range of issues that an actual high ping has (ie: inconsistant arrival times). That, and that its indistinguishable.
Also, if it was lagged by half a frame, you could potentially get a smoother game where compensating for lag is less awkward than compensating for inconsistant packet timings. Actually, this is more in favour. Hrmph.
The other issue is that you can connect with a high ping, and reduce it once the game has begun, thus bypassing any fairness checks with regard to ping (eg: only when actually shooting the LG). Serverside min ping cannot be changed on a whim for a single client, so does not have this issue.

In summary...
because that's what kteams/ktpro used.

But the whole problem is that Ezquake completely disregards the client side lag disable bit, thus allowing users of Ezquake to enable client side lag whether the server allows it or not.


But they didn't. At least I've never been on a KTPro server where client side lag was forbidden. It's a (relatively) recent change done to KTX.

It's controlled by different (in my opinion more comfortable) means - each change is announced in the chat in prewar and changing during game is disallowed.

Another question: Is it neccessary to create a problem out of something that ain't a problem for like all qw-players except you?

(bigfoot wrote: But the whole problem is ...)

That is true. But as I got it, bigger problem was the ability to silently change the lag during the game. So disabling /qlag and control ezQuake's cl_delay_packet by the means described above seems as a way out.

There's no reliable way to tell whether user is using cl_delay_packet or not at the moment. If players think it should be possible, it can be done. But respecting qlag FPD doesn't seem as a good idea to me for apparent reasons. I can think of f_ruleset reply flag addition. But when we introduced cl_delay_packet I think I asked several players and admins whether they want to have such check and noone seemed to be interested.

#5 $$$

:d

imo real lag and client generated lag are much closer to each other than server side minping which always felt a million times more horrible than just normal higher ping.

mvdsv server side minping is "broken", don't use it. cl_delay_packet suits all you need rather better.

regarding topic 1) I don't know, think it derived from some configs, also I think it probably set because qizmo lag can be abused/faked/changed too ez. But it all about qizmo...

So a slight difference in how it is enabled means it should disregard that the server asks for it to be disabled?


It is in for example Qizmo too if you ask it to. The documentation has even been copied into the default KTX config.

Didn't take long for the smear campaign to start again.

There's an FPD bit to make clients announce lag changes.


The apparent reason being that the default KTX config forbids client side lag?

As far as I know there is no mod command to toggle FPD bit 4 (value 16) and during my last research most servers had that bit disabled in their FPD.

NFProxy documentation (value, not bit):
8 : report changes in lag settings (.dcp)

16 wasn't documented (presumably nfproxy doesn't check this bit, it does document most of the others though, at least)
I failed to find qizmo or cheapo docs. :s

So I guess ezquake isn't the only one to have this more 'liberal' interpretation of the FPD.

But... someone ought to fix http://wiki.quakeworld.nu/FPD to say 'permit' and 'ignore' instead of 'not impl.', at least if ezquake is the measure of required conformance among clients.

Shouldn't the description be changed first? Right now it says "Make Qizmo report any changes in lag settins". ezQuake doesn't change that anyhow (and I don't mean to play with words here).
I mean yeah it's copied from Qizmo's readme (I created the wiki page), but was it ever intended to be a general rule? Or is it only your assumption?
Even the command to toggle it is called "qlag". Not "fpdlag" or anything trying to be not related to Qizmo.

qizmo, as the progenitor of the fpd key, should be the reference implementation for the fpd flags that it supports. Any other project that documents fpd flags should document how they differ from the reference implementation, rather than copy+pasting the documentation and implying that it matches.

'ignore' is relevent whether it says 'qizmo' or 'client or any proxy', as ezquake presently ignores that bit regardless of the expected or documented attributes of that bit. If you really care about wording, word it as 'not applicable' instead. But either way, 'not implemented' is hardly a relevent status.

Geez, I'm not arguing against ezquake's behaviour here, for once, I mean, even if you could somehow manage to get commit access to ktx and change the default, or somehow manage to track down someone elusive like qqshka and ask him to change the default for you, you would still have lots of ktx servers out there that are happier running old versions than upgrading, but more seriously you'd have proxies that didn't even warn (in the form of nfproxy, qizmo would at least work properly). All I'm saying is that ezquake and ktx's documentation is outdated and thus misleading or dishonest.

Yes, I think by now we have established that KTX's default configuration is a bit weird. May I suggest that the default KTX configuration gets changed so lag is allowed and lag change reporting is enabled?

You do realise that Ezquake, due to its Fuhquake and Zquake heritage, respects the FPD bits for other things, right?

Ok, submitted this feature request (not going to request change of default in the other FPD bit, anyone else can do so).
Edited the wiki page a bit too.