Dan look over this.... http://developer.valvesoftware.com/wiki/Source_Multiplayer_Networking
Then give a rethink of some of what you said.... ----- Original Message ----- From: "Dan Sorenson" <[EMAIL PROTECTED]> To: <[email protected]> Sent: Thursday, July 14, 2005 1:06 AM Subject: [hlds_linux] Re: Request a higher minimum value for cl_cmdrate. > At 12:36 AM 7/13/2005 -0700, Eric said to all and sundry: >>>>Thousands of times, theoretically, when you consider >>>>holding the mouse button down is sending the signal that >>>>you're doing so... >>> >>> and that still only makes your weapon discharge a single >>> round >> >>...if you're firing a semi-auto weapon, I guess. > > I doubt any of that is actually transmitted to the > server. Alfred probably can't disclose much, but typically > the mouse-click is handled client-side and the action performed > is sent to the server, which responds with a result. Thus, > typical netcode will have the client report to the server > "I'm at position X.Y.Z and pointed to position A.B.C, action > is automatic fire from Super Soaker." The server takes that > information, determines if this action has a result on another > client, then informs all clients of your new location and > specific clients of the effects of your action. We're all > familiar with seeming to die at the same time a player > rounds a corner and fires, though human reaction times are > nowhere near that fast. In fact, the scene was probably played > out in the server a half-second prior, and your client is just now > getting both the "Client 1 moved to position X.Y.Z and is facing towards > A.B.C" message to generate his form and the "client 1 hit you > with eighteen gazillion damage" message that tells you to die > at about the same time. > > It would be possible for the netcode to only send updates > about client position to relevant clients, so when Client 1 moves > to a position only those with line-of-sight to that location are > updated. However, this would necessarially increase the processing > required on the server and may actually introduce more latency. > It would also eliminate wallhacks and ESP, since there's nothing > coming in for them to work with, but that could require an entire > engine overhaul and coupled with server demands there's probably > a reason it was written the way it is. > > So, in theory a server is going to be sending a bit > more data than it takes in, since it's taking in only position > and action while sending out that same info to all clients as > well as results of actions. Naturally, this is going to take > a bit of buffering in the engine to handle the wide range of > update rates that players are connected at. If I have a ping of > 200 (not uncommon given my method of connecting to the internet) > and you have a ping of 100, that's 300ms worth of player movement > and action that needs to be buffered. Let's say a half-second is > what's in buffer that the server acts upon. Let's also assume that > a cl_cmdrate of 10 means 10 updates per second to the server. > > So with a cl_cmdrate of 20, if I fire one round at > time 0.0s the server only knows that action happened between > t0.0 and t0.05, when it gets the next update. If I set my > cl_cmdrate to 10, the server only knows it happened between > t0.0 and t0.10. Suddenly I'm firing for twice as long a period. > Now the server has to figure I fired during that 10th of a second, > checks the location of you my target, and if you were within the hit > cone during that 10th of a second has to record a hit. So, by setting > my cl_cmdrate to the lowest setting single-shot weapons would > suddenly be more effective because the time they're on-target > is a 10th of a second rather than a 20th or a 30th. > > Note: all this is speculation on my part. > > So, rather than increase the cl_cmdrate minimum, what > I'd suggest is to base both cl_cmdrate and cl_updaterate off of > the old rate variable, and just make them a ratio of what the > server needs vs what it has to send. So if the server has a > maxrate of 10000, and a minrate of 5000, when client 1 connects > with rate 5000 he gets cl_cmdrate 20 and cl_updaterate 30. > When he connects with rate 10000 he gets cl_cmdrate 40 and > cl_updaterate 60, just to use an example. > > If we base the up and down rates as portions of the > overall rate, it should be easier for the engine to handle. > The caveat is DSL is asymetrical, so people with a 3M download > speed and a 48K upload speed might have a problem, but overall > I think it would even out a lot of the differences between > the broadband and the dial-up users. > > -- Dan > > * Dan Sorenson DoD #1066 A.H.M.C. #35 [EMAIL PROTECTED] * > * Vikings? There ain't no vikings here. Just us honest farmers. * > * The town was burning, the villagers were dead. They didn't need * > * those sheep anyway. That's our story and we're sticking to it. * > > > _______________________________________________ > To unsubscribe, edit your list preferences, or view the list archives, > please visit: > http://list.valvesoftware.com/mailman/listinfo/hlds_linux > _______________________________________________ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlds_linux
