artiecs wrote:
That article is definately a good start.
Alfred, one other tremendously important cvar that needs to be addressed is
cl_interp. The default value of 0.1 for cl_interp causes hitboxes to 'lag'
behind player models a significant amount.
If one also adjusts cl_interpolate 0 only. If not, the hitboxes viewed
on the client do in fact lie in the correct place with respect to all of
the other network subroutines, and indeed where the texture will be seen.
This is why players who run
around corners can still be hit by other players, even though they have been
out of that other players view long enough that they shouldn't be hit.
No, this is because cl_interp, as you know is a delay. With a higher
value of cl_interp, when that player hit's you in the past, you will
only 'see' the effects once his data has been processed by the server
(on some servers, 60-100fps this could be almost 0.2s) and sent back
(ping/2) having been through your cl_interp - with the exception of the
caveat I speak about below.
When
cl_interp is lowered, it keeps the hitboxes more closely alligned to the
player models. When it is raised, it makes the hitboxes lag even further
behind the models (which is how some of the rediculous "Bash Valve about the
hitboxes" videos on the web made the hitboxes lag 10-20 feet behind the
models).
Indeed the videos you speak of were made with cl_interpolate 0 and
cl_interp 0.1 or higher.
We've seen players actually have this cvar set to 0.2 and higher,
which allows them to shoot the hitboxes of players a significant time after
that player hs run behind cover or around a corner, this should not be
allowed in any situation. Even the default of 0.1 allows this, tho not as
bad as higher settings.
Indeed it should be restricted in a way which resembles some kind of
judgement of players ping times and server performance. This could be
suitably handled by server operators, although as has been discussed
many times on this list - it should be possible to create 'optimal'
values server side and push them to clients in order to optimise a fair
timeline delta for all players.
Most of the regulars on our server run cl_interp between 0.02 and 0.04. This
keeps the hitboxes closely aligned with the actual player models (ideal case
would be that they're Exactly aligned 100% of the time) which results in
great shot registration when a player accurately shoots at a model he sees.
If what you claim was true, that the hitboxes (server's view of the
model) lag behind the model (your view of the model) then there should
be some mathematical relationship for this deviation. Indeed you suggest
it is linear (as many have), I ask why this does not suggest that in
fact 0.01 (the minimum setting) would not produce the least deviation?
On a server which is performing well (at least a few hundred fps
sustained) you will generally see a marked impovement in 'accuracy', and
again you will see improvements when you increase the tickrate of the
server (provided the prior doesn't drop significantly). The reason for
this is the age and accuracy of the data you are viewing.
There is indeed one side effect of cl_interpolate 1 and cl_interp values
above the minimum value which is a very very important effect.
Put very succinctly, players which have died on the server timeline,
which are not yet dead on the client timeline can no longer make
gameworld interactions.
There is a simple test for this:
1. Load up a map, set no target and add a high skill bot with bot
lagging on.
2. Hand the bot an awp and stand in plain vision.
3. Aim at the bot and pause the game
4. bind unpause
5. reset bot target
6. set cl_interp to max
7. unpause and commence fire
Observe no registered hits for the client.
Second test:
Two models, one stationary, one sidestepping into view. Sidestepping
model on a minimum cl_interp, attacks for a kill (deagle). Second,
stationary model takes accurate shot after the sidestepping model has
stopped, but not before cl_interp of the stationary model has expired.
Again, this shot will not be processed as the player is already
registered as dead on the server timeline.
I know that back on the HLDS CS there's an equivelent cvar, and that you
were never supposed to set it below (1/cl_updaterate), or more specifically
(1/# of incoming packets/second), since clients can often recieve fewer
packets/sec than cl_updaterate is set for, for a variety of reasons. Even if
that 'rule' is still true for SRCDS, the default of 0.1 for cl_interp it
much too high. That would assume recieving 10 packets/second (1/10 = 0.1).
Since most all servers run tickrate 33 or greater, and especially if Valve
ups the default cl_updaterate to 33 or higher, as suggested in the article
that the OP linked to, then cl_interp should be set by default at least down
to 0.05 (which requires only 20 packets/sec and would be fine even for the
current default value of cl_updaterate) or 0.04 (which requires only 25
packets/sec). Additionally, cl_interp should have a hard coded maximum limit
of 0.05, so that players can't just turn it up, allowing them to shoot
people's hitboxes after that person has ducked behind cover that can't be
penetrated by shots, or around corners.
A few of us have messed around with this extensively, and it's easily
reproducable by 2 people. Player 1 adjusts cl_interp and shoots at player 2.
Player 2 strafes back and forth being a test target. The higher player 1
adjust's cl_interp, the further behind the model of player 2 he must shoot
to hit. At high values of cl_interp (0.1 and especially higher) shooting the
model accurately results in no hits cause while player 2 is strafing his hit
boxed and 'lagging' x-feet behind hit. When Player 1 sets cl_interp around
0.02 to 0.03, the hitboxes for Player 2 stay almost perfectly aligned to the
model, so shooting the model (while Player 2 is still strafing)results in
hits, and shooting behind the model no longer results in hits (as it does
with the default cl_interp setting). This also makes Player 2 impossible to
hit the intsant he ducks behind solid cover, or disappears around a corner,
as should be the case.
So if Valve is going to take steps to inprove the whole 'rates' situation,
addressing cl_interp is essential, otherwise at least half of the problem is
going to be overlooked, and still exist in the game even after it has been
'fixed'. If you're not already very familiar with this cl_interp behaviour,
please have a couple of your people mess around with it as I described in
the previous paragraph, just to see how much effect this setting has on shot
registration location for moving targets, how far off the shot registration
is for moving targets at the default setting (particularly in the case of
the target moving perpendicular to the shooter), how it can be abused by
setting it even higher, and how simply it can be fixed (and shot
registration Greatly improved) by lowering the default and capping the value
it can be set to.
You can actually view the position of the current packet data hitboxes -
this is available through the sv_showhitboxes cvar. It is entirely
possible to hit a players model at cl_interp 0.1 if cl_interpolate is 1.
It is not possible to interact with the gameworld after you are dead on
the server timeline. It is not clear if this is a server or a client
issue, as the client will have updated information prior to displaying
it on the model view. If I remember correctly, it does however display
it upon reciept on the HUD kill area (and not after cl_interp delay, as
per the correct behaviour).
This is my understanding of the current functioning of the engine to
date. It is both consistent with specification and observation, and it
is entirely possible that the interaction of the server timeline and
cl_interp view was not correctly specified to begin with. It may even
have been considered a minor race case condition, but it should be
easily solved.
Regards,
J.
Thanks
Artie
----- Original Message -----
From: "Gamer" <[EMAIL PROTECTED]>
To: <[email protected]>
Sent: Thursday, November 23, 2006 12:41 PM
Subject: [hlds] Alfred PTBx considerations?
This is a multi-part message in MIME format.
--
[ Picked text/plain from multipart/alternative ]
This was so great to see, everyone take a look.
http://www.tcmagazine.com/comments.php?id=12979&catid=12
Alfred I am very encouraged seeing that correspondence, the last week has
been very discouraging from both the players and admins point of view.
Unfortunately XAD has left the Steam game community so there is nobody to
stick up for PTBx
Alfred if you can also look into to allow plugins and server to better deal
with team balancing on public servers.
PTBx was also crippled with this new cvar, it would be great to have a
sv_autojoin
sv_autojoin would have players randomly assigned to a team as they join the
server.
If sv_autojoin 1 players switch team menu would only give them the change
skin option and not team.
This would allow a plugin designed for balance to handle moving players with
out force killing them and losing weapons. providing a plugin access to a
function that allows the team switch at end of round so it does not
interfere with on going game play.
The default team balance that was changed a while back now moves the newest
player to the weakest team, he has not the money nor in many cases warmed up
enough to be of the kind of help the weaker team was in need of. Additional
support to balance on public server would extend the enjoyment players get
and help with the large problem of join the winning, team team staking and
so on.
Players looking for a fair and balanced game should not have to open
themselves up to the problems that can arise from changing this cvar's
default value. As it stands now we have been on a education campaign with
our players educating them about autoexec.cfgs and how to turn this off so
they can get on our servers that are running zBlock and PTBx.
Happy Thanksgiving and thank you for you time,
gamersfun
--
_______________________________________________
To unsubscribe, edit your list preferences, or view the list archives,
please visit:
http://list.valvesoftware.com/mailman/listinfo/hlds
_______________________________________________
To unsubscribe, edit your list preferences, or view the list archives, please
visit:
http://list.valvesoftware.com/mailman/listinfo/hlds
_______________________________________________
To unsubscribe, edit your list preferences, or view the list archives, please
visit:
http://list.valvesoftware.com/mailman/listinfo/hlds
