I am interested to hear opinions over the viability of client rate regulation at the server side by means of server regulated client view extrapolation. Would this be a better solution?, or does it simply produce too much regulation on the low rate client?
On 7/25/05, Whisper <[EMAIL PROTECTED]> wrote: > -- > [ 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 > _______________________________________________ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlds
