-- [ Picked text/plain from multipart/alternative ] The things you're nothing are not issues, they're by design. Or atleast, they should be by design. It may indeed not be perfect that the last few actions you performed before being killed are not being processed, however it would be significantly more "annoying" if kills you make are later undone due to players with high latency and/or interpolation delay.
Also when you say "max interp", make sure to keep it below sv_maxunlag. The issues that currently do exist in the netcode are that the interpolation delay imposed on clients is ~66ms on top of the cl_interp value (when cl_interpolate is 1) And that with interpolation disabled, bullets are registered to the wrong history "tick". See the following link for further reference: http://forums.steampowered.com/forums/showthread.php?t=420665&highlight=final+quirks%22 On 11/28/06, James Tucker <[EMAIL PROTECTED]> wrote: > > 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 > -- ___________________________ Wim 'TheUnknownFactor' Barelds [EMAIL PROTECTED] -- _______________________________________________ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlds
