-- [ Picked text/plain from multipart/alternative ] Hey I agree with you James. My stupidity allowed me to get sucked in to Claytons baiting tactics.
On 7/25/05, James Tucker <[EMAIL PROTECTED]> wrote: > > [rant] > My god, two days after a message - how pathetic. > > Yes, client interpolation DOES have to do with netcode, and here is > the REASON that neither of you seem to have the decency to produce for > each other. > [/rant] > > Interpolation does several things which effect netcode, these will be > summarised here: > - Sets the data drop time for incoming packets. - derived > - Sets the data collision resolution time. - derived > - Sets time to extrapolation on the client. -derived > - Sets minimum time to client view regulation. -derived > - Sets delay on gameworld data rendering. > - Generates intermediary data using _known_ data, _if_available_. > > What it does not do: > - change packetrates > - alter the rate of incoming data from other clients > - "generate" new data for clients with low packetrates > > When you see another client lagging, most peoples reaction seems to be > a kick. If you turn up your cl_interp value, your client will have > more time to wait until the next update arrives for the "laggy" > player. At 30 packets per second you would get away (on an ideal > network) with cl_interp 0.033. If a client is only capable of sending > 10 packets per second however you will need cl_interp 0.1, again on an > ideal network. Data rates can also be important, particularly on slow > speed connections - latency for packets is one thing, but they take > time to transmit as well, and the larger they are... > > Remember your time frames too. Client A with 100ms of latency plays > game data on defaults, 100ms of interpolation and a packetrate of 20 > packets per second. Client B has 'optimised' and is running with a > client packetrate of 60 packets per second and 40ms of interpolation > with a latency of 30ms. Client A attacks B and the packet arrives at > the server 100ms later (neglecting to take into account the potential > 50ms wait until the next packet is due for sending). The server rolls > back 200ms and generates data. The server is trying to send 60 packets > per second, the next packet will be sent within 16ms. Client B > receives the update at 230ms to 296ms. Clearly this is well outside of > client B's interpolation time, and is not a 'problem' with the > 'netcode' settings but will give that appearance on the client. > > I have come to the conclusion that SRCDS is not affected with it's > latency compensation by false pings generated through improper rate > settings. I am not sure about HLDS. I have not built any system to > test this however, but am merely aware that the scoreboard ping is not > what is examined by high ping kicker tools. > > No, interpolation does not directly change the netcode, it is > calculated on the server to regulate client view to server view - and > in this regard it is significant in netcode also as it is responsible > for the variables of the system stated above. There is no reason to > deny it's significance in this discussion as proper cl_interp values > can be used to compensate all clients for poor network performance - > this is entirely what it was designed for. If client variables are > mis-adjusted (VERY VERY COMMON) then you cannot make judgements about > the functionality of the systems which they effect. > > Sorry if I missed anything, but hopefully this will get the discussion > back on to something that matters, and exists. > > > On 7/25/05, Whisper <[EMAIL PROTECTED]> wrote: > > -- > > [ Picked text/plain from multipart/alternative ] > [snip-unnecessary-crap] > > > http://developer.valvesoftware.com/wiki/Source_Multiplayer_Networking#Lag_Compensation > > > > > The lag compensation system keeps a history of all recent player > > > positions for a time span of about one second (can be changed with > > > sv_maxunlag). If a user command is executed, the server estimates at > what > > > time the command was created. This command execution time is > calculated as > > > followed: > > > > > > *Command Execution Time* = Current Server Time - Client Latency - > *Client View Interpolation* > > > > > > Then the server moves all other players back to where they were at the > > > command execution time. The user command is executed and the hit is > detected > > > correctly. After the user command has been processed, the players are > moved > > > back to their original position. On a listen server you can enable > sv_showimpacts > > > 1 to see the different server and client hitboxes: > > > > > Since the server is the final arbiter of what happen excluding Cheats or > > Client Side exploits, it is quite clear from that explanation, the > server > > takes into consideration the clients interpolation. > > This means each and every clients interpolation settings has an effect > on > > when the server decides an action takes place and is a core component of > the > > of the Source netcode. > > _______________________________________________ > 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
