// rate command

// if the client is on the same subnet as the server and we aren't running an
// internet public server, assume they don't need a rate choke
if ( Sys_IsLANAddress( cl->netchan.remoteAddress ) && com_dedicated->integer != 2 && sv_lanForceRate->integer == 1) {
cl->rate = 99999; // lans should not rate limit
} else {
val = Info_ValueForKey (cl->userinfo, "rate");
if (strlen(val)) {
i = atoi(val);
cl->rate = i;
if (cl->rate < 1000) {
cl->rate = 1000;
} else if (cl->rate > 90000) {
cl->rate = 90000;
}
} else {
cl->rate = 3000;
}
}

HAHA! WHY?

Seriously, no.

Refresh memories :

\rate
This setting controls packets to ensure a good connection. If you have an ISDN modem ( 128K ) then this can be set to around 12000. If you have a 56K modem then this should be around 4000-5500 depending on your connection speed. If you are on a LAN or have a ADSL modem then this can be around 25000 or perhaps even higher. Remember, it is best to experiment to find a suitable number but don't get too carried away or you may cap performance.

\snaps
This is possibly the most important setting for getting a good connection. As everyone knows, in Quake 2, your gameworld updates depended on your current FPS so slower computers were at a disadvantage. Now, in Quake 3, your snaps setting determines how many updates you recieve from the server. 56K modems should have a setting of around 20 - 30. ISDN modems (128K) should be around 40 as should any other fast connection devices ( LAN, T1 etc.... ).

\cl_packetdup
As the name suggests, this setting is used to send multiple packets to compensate for lost packet drops. This setting should be set at 1 unless you have a good connection (no lost packets) in which case set this to 0.

\cl_maxpackets
This setting puts a limit on the maximum amount of packets that can be sent to the server via the client. This setting is useful for people with slower modems. The default setting is 30 ( comparable to a 56K modem), but lower this if you have a 33.6K modem or less, and higher this setting if you have an ISDN or higher modem.

But remember, with \cg_lagometer "1"
"The first line displays the conjunction between your graphics card updating the frames in sync with the gameworld updates recieved from the server. Idealy, this should be a straight blue line. If it has bouncing yellow spikes then your display will stutter and be more difficult to view. To combat this, first ensure you have followed my tweaking techniques and then change your snaps setting. Usually, this means lowering it by 1 or 2 until your screen is stable and you have a nice flowing blue line in your lagometer. The second line shows if packets are being recieved from the server. This should be green. If it is yellow or red, try increasing your rate or try lowering your snaps."

oh, ok thx for the translation.

I am pretty sure that this cvars don't cause lag because of high setting.

wrote:

i thought online rate was capped by engine at 25,000 anyways

exactly.

Online you will never get rate above 25000 except if you play on a modified server, where you however, still just get as many rate as you need, so even if it is on 193500 you just get as many as people are around. Remember, for a 1on1 3000 would nearly work out.

About snaps -> =sv_fps or more as mow stated.

About cl_maxpackets -> depends on client connection and fps.

Even if you enforce 125 maxpackets, if someone has maxfps of 100 or 63 or 60 (blah blah ati drivers buggy shit blah nub whatever, don't read here, read it up elsewhere) the person will just send as many packets as fps.

So we can't enforce a rate down to 25000 because it has no sense (lower does make sens, but it is overall already forbidden ).

We can't enforce higher snaps because snaps do not alter how you are displayed to other people on server and on sv_fps 30 everyone gets enough snaps anyways, also its in clients interest to get as many snaps as possible.

We can't enforce maxpackets because of limited connection (discrimination) and zero sense considering maxfps. Also for rank/pb games maxpackets are at least forced to 63 which gives over 90%? (didn't measure it sorry ) accuracy considering the sv_fps of 30. So any miss on a person with that amount of maxpackets is mostly because failed at tracking, however due to this inprecision being stable, you have same amount of luck to actually hit that guy eventhough it should be miss.

Aj, so overall, great suggestion nosia, I am totally f1!... nooot

edit: Now to get it a bit more precise, Imo nosia either describes an general effect (if I think I am right) but explained it wrong.

However Nosia might also just complain because he stopped getting better and searches the source of it.

Anyways, I wonder about one very odd thing.

Back in 1.03 or 1.02b, when you run a localserver with sv_fps 30 and played on it with rate 25000, maxpackets 125 and snaps 125, you have just blue spikes on top of your lagometer.

In newer versions of E+ these blue spikes are interrupted by yellow eventhough connection to loopback adapter is perfect, reason?

Edit2: Now goes even funnier, sometimes I have yellow spikes on local and sometimes I don't D: if I run dedicated I don't for example, if I run just 1 q3 I have spikes.

If you say yes you clearly don't no anything about what these cvars actually do or why they exist. maybe yes if everyone lived in the same place with the same internet i would say yes but seriously this is just stupid.