[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
