After some more thought I think that the introduced lag perhaps should be varying over time between 0-50 ms to best simulate the build-in lag from the original game.
Yes , I think that an adaptative value ( ping and/or snaps based ) could be a solution but I think that also prediction code should be tuned to have benefits also for all weapons and for a more accurate game-world coherence.
In CPMA there are 2 options for cg_predict cvar : 1 -> based on the old q3 code , 2 -> the new code .
...
cg_predict <0|1|2> (default = 1)
Replaces cg_nopredict.
0 - off
1 - normal
2 - optimised
The normal prediction path is extremely slow at times (notably around
curves) and can cost you 100fps on a GHz machine. This new scheme is
MUCH faster, but slightly more prone to errors. Oddly enough, it's still
more accurate than the original id prediction code (i.e. before the CPMA
fixes). If you have a slow machine, it's definitely worth trying. Note
that cg_predict 2 was introduced 9 Sep 2002, the definition of a "slow
machine" has changed since then. Today's computers will not notice any
difference at all.
Note: Do not use cg_predictItems 1 with cg_predict 2.
...
Anyway I feel the game better while using cg_predict 2 even if in theory there should be no differences.
BTW , for a general look to the engine preformances , I found the work of a UrT player/developer interesting about real ping and snaps analysis in realtime , the calculation of standard deviations and the conclusions to which he came :
he also made an experimental engine for UrT ( get a look to the autotimenudge feature ) :
BTW , there are also other CPMA cvars for tuning client settings ( no code but a good description at least to imagine how they should work ) and snaps is not managed by the client anymore :
cg_lagHax <-1|0> (default = -1)
A combination of adaptive prediction and an updated version of the
famous "50ms hack" we introduced way back in 99v6 that also does small
amounts of lag compensation. Capped at 100ms no matter what: this is
intended solely to make European / EastUS v WestUS / etc games a bit
less of a hassle, not to hack dialup players into aimgods at the expense
of everyone else. 0 disables it, -1 means "as much as I'm allowed": it's
naturally adaptive. You'll lose some of your "feel" for lag, which
messes up your RL aim, etc. This doesn't suffer from the CS/etc problems
of "total BS" shots that piss everyone off; it's not trying to be some
panacea for modemers; and I'm honest enough to call it the hack that it
is instead of pretending that it magically makes lag suddenly not exist,
but all in all it's a pretty nice end result. If you use this, any form
of nudging will generally make you LESS accurate if your ping's under
100ms, because it'll screw up the adaptive calculations.
cg_nudge <value> (default = 0)
An updated and much improved version of
id's crippled cl_timenudge. Allows you to use nudges beyond -25, and
automatically adjusts them to your ping: if you use -50 with a 20 ping,
you get -20. If you spike to 40ms for a few seconds, you get -40 during
the spike. This give you a "consistent worldview" that cl_timenudge
can't, and generally helps regardless of your connection.
cg_optimiseBW <bitmask> (default = 0)
1 - Significantly reduces the amount of non-critical data sent to you.
Regrettably, this also makes you unable to see players through portals,
thanks to a bug in the Q3 engine. Small price to pay though for the HUGE
difference it makes to team games. Servers can, and by default do, force
this on for all clients. It's probably worth setting it to 1 anyway
though, just in case you end up on a server that's changed it to 0.
2 - Use this if your connection is UTTERLY starved for upstream bandwidth
(i.e. from you TO the server). Essentially, if you're on dialup or one
of those Belgian Warp connections. Understand that if you're warpy and
you choose to NOT set this because you like the advantage you get from
warping, you're screwing YOURSELF. Your shots will end up with
potentially huge random delays on them, so even if you're LPB the server
may not see that you fired until up to 100ms after the fact, effectively
making your weapons act like you have an unstable and much laggier
connection, and without cg_nudge's ability to smooth it out.
...
cg_smoothClients
Does not exist in CPMA - see cg_xerpClients instead.
cg_xerpClients <-1|0|1> (default = 0)
A replacement for id's cg_smoothclients that does something useful.
1 - Hacked extrapolation: intended for HPBs
This smooths players out when you use high timenudges, at the cost of
some accuracy. It's typically easier to hit a smooth target that's a few
pixels misplaced than it is to hit one that looks like it's teleporting
all over the map, so this combined with cg_nudge is the best option for
HPBs.
0 - No extrapolation. Fine you're LPB.
1 - id's smoothclients: fine if you have cg_nudge 0, worthless otherwise.
Note that prediction errors, such as players in walls, are likely to
occur. Tends to increase how much other players warp to you.
Use at your own risk.
...
snaps
snaps should NOT be set in your config. CPMA adjusts snaps value
according to the server's sv_fps value. If you join a sv_fps 20 server
your snaps get set to 20, if you join a sv_fps 30 server your snaps get
set to 30 etc...
