MAX_PACKET_CMDS

[Oblivion]

Could someone help me out with this and tell me what the problem is.  I got a demo of it doing this to me, hmm it does it alot now, but in the past it did not.

http://www.filefactory.com/file/2d49bf/

[/dev/humancontroller]

The demo doesn't show anything out of ordinary.

MAX_PACKET_CMDS is a constant (on both server and client) that limits how many usercmds you can send in one packet. This is an informational error message, indicating that some usercmds were thrown away.

This may happen if you have a combination of a very high framerate, a high cl_packetdup, and a low cl_maxpackets value.
- Each frame the client generates a usercmd that is queued for sending. Higher framerates generate more in time.
- cl_maxpackets sets how many packets you can send in one second. The lesser the value, the more time will the client wait before generating a packet. It is used to decrease bandwidth usage by saving headers and adding more delta compression. Sending a packet every frame is used on LAN.
- To defeat the effects caused by packet loss, cl_packetdup is used. It sets how many times each usercmd is resent in the next packets, so that even if several packets are dropped in a row, all usercmds will make it to the server.

[next_ghost]

Set com_maxfps to some reasonable value, like 125.

[Caveman]

wasn't that 76 or 143 to take advantage of the rounding issue?

[kevlarman]

wasn't that 76 or 143 to take advantage of the rounding issue?

25,43,76,125,333 (another one at about 450 and another at 800ish for people with overflow's rig).

[Oblivion]

Set com_maxfps to some reasonable value, like 125.

Well my max FPS is 700 but my FPS stays in the area of 450 to 500.

[/dev/humancontroller]

- Set cl_packetdup to 0.
- Set your com_maxfps to a value which you can constantly achieve (that is, if your framerate goes well below 450 when you see a lot of shit around you, use 333).
- Essentially, set cl_maxpackets as high as possible, until your ping starts going up (your upload speed is too low) instead of down.

If you have annoying packetloss with cl_packetdup 0, then you should set it to 1, but that requires a higher cl_maxpackets value.

There's nothing wrong with settings that are just below the MAX_PACKET_CMDS limit.

[next_ghost]

Well my max FPS is 700 but my FPS stays in the area of 450 to 500.

Each rendered frame generates client commands. MAX_PACKET_CMDS is enough for about 200 fps, not for 500 fps!

[/dev/humancontroller]

Well my max FPS is 700 but my FPS stays in the area of 450 to 500.

Each rendered frame generates client commands. MAX_PACKET_CMDS is enough for about 200 fps, not for 500 fps!

No, MAX_PACKET_CMDS is enough. Just enough. It's only to disallow packets with thousands of usercmds that require a lot of processing power and cause server hitches.
The default settings may be enough for 200 fps, but there's nothing wrong with 800 FPS, it just generates more bandwidth (and you have to tweak your packet settings along with the maxfps). Pro gamers have ubercomps and ubernets.

[next_ghost]

Yeah, there's nothing wrong with 800 fps, except that human eye can't see any difference above 60 fps and the best CRT monitors can't show more than about 200 fps anyway (I've never seen a CRT monitor with vertical frequency above 200Hz). LCD screens can barely show 125 fps so far. :roll:

So if you want to stroke your ego by having 500+ fps, don't complain that the game doesn't like that and keeps complaining.

[kevlarman]

Yeah, there's nothing wrong with 800 fps, except that human eye can't see any difference above 60 fps and the best CRT monitors can't show more than about 200 fps anyway (I've never seen a CRT monitor with vertical frequency above 200Hz). LCD screens can barely show 125 fps so far. :roll:

So if you want to stroke your ego by having 500+ fps, don't complain that the game doesn't like that and keeps complaining.

and the pmove logic behaves differently depending on your fps...

[next_ghost]

and the pmove logic behaves differently depending on your fps...

... because of a bug which can be fixed and HAS been fixed in the past, for example in ETPro. That bug doesn't really matter in Tremulous anyway because there's no real advantage or disadvantage from it as opposed to Enemy Territory or Quake 3.