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
