We will be addressing the range of network configuration variables so servers can define the valid range they wish.
- Alfred 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. 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. 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). 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. > > 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. > > 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. > > Thanks > Artie > > > ----- Original Message ----- > From: "Gamer" <[EMAIL PROTECTED]> > To: <hlds@list.valvesoftware.com> > 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
