Ég var að skoða korka á Xsreality.com áðan og rakst á þetta, skrifað af [iq]Strider(sá sem gerði 125 hz)



I'll give a brief rundown on all the settings… I was gonna do a website on the Challenge network about all this stuff but unfortunately noone else was interested in helping me and I haven't got the time to do everything myself these days…

Anyway, here's the main stuff you should know about:

The info following is my own investigation work, as far as I can work out it's pretty much exactly how things work.

<h3>RATE </h3>

The rate command specifies how much bandwidth you have available. The following is a quote from Carmack:

“The most important one is ”rate“, which is what the connection speed option in the menu sets.

We are fairly conservative with the values we set for the given modem speeds: 2500 for 28.8, 3000 for 33, and 3500 for 56k. You may actually be connecting faster than that, and modem compression may be buying you something, so you might get a better play experience by increasing the values slightly.
If you connect at 50000 bps, try a rate of 5000, etc.

I err on the conservative side, because too low of a rate will only make the movement of other things in the world choppy, while too high of a rate can cause huge amounts of lag.

Note that the optimal rate will be somewhat lower than a rate for QW or Q2, because I now include the UDP packet header length in the bandwidth estimate.”

<h3>SNAPS </h3>

The snaps variable dictates the maximum number of snapshots a server should send per second. The default value is 20.

A snapshot contains information about the current state of the game, player positions and movement direction, events (ie. footsteps, pickup sounds), projectiles (ie. rockets and grenades), the impact point of a rail shot, door states (open, opening or closed) etc. All the relevant information about what is happening in the game and is potentially visible to you is included in the snapshot.

The latest version of Quake 3 (v1.17) allows a maximum of 25 snapshots per second. The server is also able to override the maximum snapshot frequency you can expect. If a server is running at 20hz (sv_fps 20) then the maximum number of snapshots you can receive is 20 per second even if you set snaps to a higher value. Note that a server running at 40hz (sv_fps 40) won't actually send 40 snapshots per second since 25 is the absolute maximum.

The frequency of the snapshots determines how smoothly you see things. The higher the frequency the smoother things become.

A higher frequency can easily cause lag depending on the number of players on your screen and the weapons they are firing.

Changing from 20 to 25 can give you severe lag when fighting in a TDM game on ISDN especially if you have upped your cl_maxpackets setting (see below).

<h3>CL_PACKETDUP </h3>

Not much is known about cl_packetdup at this time but from looking at the QuakeWorld net protocol, it's probable that each packet sent to the server contains the latest command and previously sent commands. So with cl_packetdup 1 each packet contains the current command and also the previous one. For sure it doesn't increase the number of packets sent but it does increase outgoing bandwidth so it looks like a safe assumption.

I've learned more about how this works now. It's pretty much what it says above and shouldn't be considered an assumption anymore :)

Also, the maximum is cl_packetdup is 5, giving a possible 6 movement commands (the latest plus the previous 5) in each client to server packet.

<h3>CL_MAXPACKETS </h3>

The cl_maxpackets variable controls the number of packets to be sent to the server per second. It defaults to 30.

These packets contain movement instructions (forward, back, jump, strafe etc), the buttons currently pressed (attack, use item, gesture etc), the angle you are facing etc. They also contain your say and say_team messages as well as older movement commands if you have cl_packetdup > 0.

This is perhaps one of the most important tweak variables depending on your framerate.

The cl_maxpackets value is uncapped in Quake 3 (v1.17). Your framerate can dictate the maximum since a framerate of 50fps means input sampling occurs 50 times per second so only 50 packets will be sent regardless of cl_maxpakets being > 50.

If your framerate is consistently 60fps and you use cl_maxpackets 60 then what you see locally on your screen is syncronised with what is being sent to the server. If your ping is 50ms then the server will reflect what you see 50ms later.

Quake 3 defaults cl_maxpackets to 30 so a framerate of 60fps means input sampling is occuring at 60hz but it's not syncronised since new commands will be sent to the server every 2 frames.

With cl_maxpakcets 30 and 120fps then new commands are sent to the server every 4 frames. If your framerate is changing dramatically as you play then the input sampling will be just as erratic.

This delay in sending commands to the server isn't noticable to you since locally you see everything occuring smoothly. You move the mouse and it's smooth as is your movement. With a low cl_maxpackets you don't really have a clue what is going on in the server, especially with aiming, to you locally you could shoot someone with the shotgun dead on, but by the time it gets to the server you might not be looking at the enemy.

Each packet sent to the server during testing averaged around 50 bytes (using cl_packetdup 0). With cl_maxpackets 75 the outgoing bandwidth will be around 3750 bytes per second. ISDN or better can usually handle that but a modem will be flooded. During testing cl_maxpackets 40 was achievable (with cl_packetdup 0) on a 46k connection speed.

NOTE: For TDM games, you should really make sure you play some test games, the snapshots in TDM are way bigger than they are in a duel so if you have too high a cl_maxpackets value and suddenly get into a 4 or 5 player fight then you'll be flooded, even on ISDN.

Most likely, cl_maxpackets 50 would work well for ISDN in TDM so it's probably better to try that first.

The cl_maxpackets variable should NOT be significantly lower than your framerate. Otherwise, what you see on your screen will be very different from what is happening on the server resulting in an inconsistent aim. Also if your framerate is inconsistent then your input sampling becomes erratic with the potiental to also seriously affect your aim.

So, in order to ensure a consistent online playing experience you should set com_maxfps and cl_maxpackets to a framerate that you can achieve consistently. If you achieve a minimum of 50fps on q3tourney4 then com_maxfps 50 and cl_maxpackets 50 would be the best setup for that map.

If you consistently achieve 100fps then you could use com_maxfps 100 and cl_maxpackets 100. It's up to you to test it out and choose the settings that suit you and your connection speed.

Remember, that the higher the sampling frequency being sent to the server, the more accurate things will be between what you see locally on your screen and what actually happens on the server. There'll be a point where it won't matter, such as having 200fps and using cl_maxpackets 75.

I have written a sampling mod to demonstrate how a low command sending frequency affects what is happening on the server regarding your movement and angle changes.

I'll upload the sampling mod soon for anyone wanting to check it out.

Also, sometime soon I'm gonna check this all out again. If anyone else has more info then please post it!

Happy Q3'ing :)