-- [ Picked text/plain from multipart/alternative ] But I cannot see what the technical problem (other than maybe it might be computationally intensive for the server) would be to automate the clients various rate settings, to best suit the clients connection and the servers settings.
On 7/25/05, James Tucker <[EMAIL PROTECTED]> wrote: > > 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 > -- _______________________________________________ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlds
