cl_maxpackets

Something is not working. You need help with ET related things. Spam posts will be deleted!
Post Reply
gaoesa
Site Admin
Posts: 1520
her blog
Joined: 05 Apr 2010, 15:02
Location: Finland
Contact:

cl_maxpackets

Post by gaoesa »

NOTICE: I do not guarantee accuracy of any information provided here.

This setting is not very well know by many players and is surrounded with many superstitions. I will attempt to give some guidlines about this setting.

Cl_maxpackets restricts the amount of world updates client sends to the server. That is, the maximum amount of game updates that are sent from your game to the server. This setting is used to help upload bandwidth problems. Notice, that the absolut maximum amount of packets is always your FPS (Frames Per Secod).

The usable range of this cvar is often 15-100 or 30-100.

The recommended setting is your average FPS.

There is no point setting this to 100 if your FPS is for an example 76. It doesn't hurt either so feel free to set it to 100. Remember, the max amount that is used is your FPS, unless it is over 100. Setting this to 100 will force all the hurted egos to whine from something else.

If your FPS is higher then 100, it is recommended to use some divisor of your FPS (e.g. FPS=125, cl_maxpackets should be set to 31/32 or 62/63). If you have FPS less then 100 and bandwidth problems, it is recommended you set the cl_maxpackets to some divisor of your FPS.

In other words, if you don't set it to your FPS, set it to some divisor of it.

Notice! I do not guarantee that any information here is correct.

Here is a link to a more complete tweaking guide that I used as a basis for this tweak info.

http://ucguides.savagehelp.com/ConnectionFAQ/Quake3.htm

If I find out that I have written wrong information here, I will attempt to fix all that information.

If you don't know what is FPS, then ignore this tweak because first you need to know FPS stuff before this can be any help to you.
He hoped and prayed that there wasn't an afterlife. Then he realized there was a contradiction involved here and merely hoped that there wasn't an afterlife.
- Douglas Adams

silEnT development
http://mygamingtalk.com/
toogi
Posts: 1
Joined: 15 May 2010, 23:33

Re: cl_maxpackets

Post by toogi »

cl_maxpackets 100, no matter what. Its forced to 100 in matches, like rate to 25000 and snaps 20, fps just higher stable
User avatar
neroWinger
Posts: 116
Joined: 11 Apr 2010, 21:25
Location: Berlin

Re: cl_maxpackets

Post by neroWinger »

hey gao, thx for clarifying in relation to configs (very helpful for designing a cfg, maybe u make a list of grafic cmds with relevance, tia ;=))))

i browse some posts according to maxpackets,
someone r infected to placebo, someone rly have the feeling of better aim
whatever it s the rate of sending packets to the server (so it makes sense of sending more packets for a liquider game-play)
most of the players use 100 (dunno if it s be a benchmark)

related to fps, the tj´er use 76 125 333 com_maxfps (dont forget about the pmove)
gaoesa
Site Admin
Posts: 1520
Joined: 05 Apr 2010, 15:02
Location: Finland
Contact:

Re: cl_maxpackets

Post by gaoesa »

Yes it is forced in clan base configs. The engine should select the suitable divisor by itself. The rreal value usually never is 100 unless the fps is 100 or some value where 100 is divisor of it. I don't exactly know why it is forced. Maybe it is to prevent some lag scripting but it really shouldn't matter because changing the com_maxfps setting does the same thing as changing the cl_maxpackets.

Another one is the snaps 20. Yes, the snaps is supposed to be 20, the engine has many bugs if it's not. However, it is the server frame rate and setting this to any value in client side should not have any effect. So I don't really know whats the issue with this one either. Probably I should be reading more of the etpro forum to find the answers :P
He hoped and prayed that there wasn't an afterlife. Then he realized there was a contradiction involved here and merely hoped that there wasn't an afterlife.
- Douglas Adams

silEnT development
http://mygamingtalk.com/
User avatar
neroWinger
Posts: 116
Joined: 11 Apr 2010, 21:25
Location: Berlin

Re: cl_maxpackets

Post by neroWinger »

quote from http://enemy-territory.4players.de/e107 ... php?185347

Well Gotenks is right here it does skip.... However if you notice the settings I gave actually have the PacketDup set to 1.
This causes the server to resend the missing packets when your snaps are set to 30 actually before the next snaps cycle begins (a maximum of 10 replacement packets "snapshots" if needed) thats why it I included the 30 snaps. 40 snaps just duplicates the 20 snaps twice over but takes longer to extrapolate the info in relevence to position / accuracy on the server (great if you live on the doorstep of the server).... Thats why you see a lot of older Q3 guys play around with it in wolf.... They know more about the wolf q3 engine /net properties than you think... !
User avatar
neroWinger
Posts: 116
Joined: 11 Apr 2010, 21:25
Location: Berlin

Re: cl_maxpackets

Post by neroWinger »

neroWinger wrote:quote from http://enemy-territory.4players.de/e107 ... php?185347

Well Gotenks is right here it does skip.... However if you notice the settings I gave actually have the PacketDup set to 1.
This causes the server to resend the missing packets when your snaps are set to 30 actually before the next snaps cycle begins (a maximum of 10 replacement packets "snapshots" if needed) thats why it I included the 30 snaps. 40 snaps just duplicates the 20 snaps twice over but takes longer to extrapolate the info in relevence to position / accuracy on the server (great if you live on the doorstep of the server).... Thats why you see a lot of older Q3 guys play around with it in wolf.... They know more about the wolf q3 engine /net properties than you think... !

the quote is oriented to a toggle btw
gaoesa
Site Admin
Posts: 1520
Joined: 05 Apr 2010, 15:02
Location: Finland
Contact:

Re: cl_maxpackets

Post by gaoesa »

@nero

b_placebo is a well know etpro cvar. It is usually used to have better aim or to lag in demand. Unfortunately N!tmod doesn't have this cvar. So we are stuck with our bad aims :D

The pmove_fixed 1 is very buggy in N!tmod and it is forced to 0. For an example the rifle grenades switch on and off with single mouse button click. I have forced it to 0 so that people wouldn't be complaining about it when they experience bugs related to this. It is also bugged in etpro and they made themself a fixed physics system to fix the issues related to this setting.

Praise the etpro team. The one team that actually produced original code other mod teams have tried to replicate. The custom mapscripting, antiwarp code that actually is incorporated to other mods, the realistic hitboxes that usually don't work as good as in etpro. The etpro antilag, actually the current et SDK has antilag code that is modified by the etpro team. The LUA interface.

Numerous things copied to other mods originate from the etpro, though the complete etpro code was never opened to public so it is a question of mimicing the behaviour.

The other notable team is the etpub team. Mostly all the major mods are based on the etpub source code. At least the most significant code is.

Jaymod is the third, and the last that I can think of now, unique ET mod. Dunno from what source it was based on but it was completely rewritten to C++ where as other mods use C.
He hoped and prayed that there wasn't an afterlife. Then he realized there was a contradiction involved here and merely hoped that there wasn't an afterlife.
- Douglas Adams

silEnT development
http://mygamingtalk.com/
gaoesa
Site Admin
Posts: 1520
Joined: 05 Apr 2010, 15:02
Location: Finland
Contact:

Re: cl_maxpackets

Post by gaoesa »

So according to that, if you set the snaps to other value then 20 in client side, the client may skip a packet and thus force the server to resend it to it. But whats the purpose of that? Other then in relation to b_placebo of course.
He hoped and prayed that there wasn't an afterlife. Then he realized there was a contradiction involved here and merely hoped that there wasn't an afterlife.
- Douglas Adams

silEnT development
http://mygamingtalk.com/
User avatar
neroWinger
Posts: 116
Joined: 11 Apr 2010, 21:25
Location: Berlin

Re: cl_maxpackets

Post by neroWinger »

b_placebo 1.0000 is my standard setting :/

pmove 1 according to rifle i have no experience, i just know that ur sniper aim is not good that it should be
so imo it s only used in tjing

SDK<--- dunno what it means

@etpub thx for the information, didnt know htat the team has done so much for us


as i said above, would be nice to discuss about soem graphics settings whatever maps
User avatar
neroWinger
Posts: 116
Joined: 11 Apr 2010, 21:25
Location: Berlin

Re: cl_maxpackets

Post by neroWinger »

it s just a point to explain, so 20 snaps more than enough
gaoesa
Site Admin
Posts: 1520
Joined: 05 Apr 2010, 15:02
Location: Finland
Contact:

Re: cl_maxpackets

Post by gaoesa »

In that same thread, there is a reya1p's reply to ronee who is making the statements about the snaps and maxpackets. You should read his post too. He is a member of the etpro team and, in fact, does know the Q3 engine. Where as the ronee posts look a lot like the placebo posts sometimes are seen around.

Here are some quotes from him.
The description of the effect of snaps is incorrect. The server will send at most one snap per server frame to any given client. Higher values of snaps cannot cause "duplicate snaps". Every server frame, the server checks snaps, rate (or sv_maxrate if it is lower) and decides whether it should send the client a new snap or not. IIRC there are some parts of the rate calculation that do not take into account the fact that snaps is effectively capped at sv_fps, so rate limiting can get slightly confused, but the only possible effect is that you will see less snaps than you would by setting the correct value.
On the subject of cl_maxpackets, my testing in etpro has shown very little effect in from using either low values or maxpacket toggle scripts. This includes blind testing with top level players. RTCW, which doesn't have working antilag*, might be affected somewhat more by low values

Of course the people using maxpacket toggle scripts are trying to gain an unfair advantage, even if they are misguided, so I certainly wouldn't feel bad about banning them

The connection between maxpackets and maxfps does have some validity, although the importance is open to question. The client only decides whether it should send a packet once per frame. If your maxpackets doesn't evenly divide your FPS, then you will get a slightly less even connection, which will show up as bumps in the lagometer. This is further complicated by the fact that q3 works in whole milliseconds only, so if you try to cap at FPS with a frame time that doesn't evenly divide 1000, your FPS bounces around as well (this also explains the capping artifact Ronee mentioned)

You can verify most of the stuff I've said here by examining the Q3 source.
He hoped and prayed that there wasn't an afterlife. Then he realized there was a contradiction involved here and merely hoped that there wasn't an afterlife.
- Douglas Adams

silEnT development
http://mygamingtalk.com/
User avatar
neroWinger
Posts: 116
Joined: 11 Apr 2010, 21:25
Location: Berlin

Re: cl_maxpackets

Post by neroWinger »

thx a lot
gaoesa
Site Admin
Posts: 1520
Joined: 05 Apr 2010, 15:02
Location: Finland
Contact:

Re: cl_maxpackets

Post by gaoesa »

In case it didn't come clear, setting the snaps to any other value then the server frame rate can cause miscalculations in the client but the snap is not sent again if the client misses it. The packetdup setting does not effect the snaps sent to the client, the setting only determines will the missed packets be sent from the client to the server if the server misses them.

According to ReyalIP, there are no benefits in setting the snaps or from toggling the maxpackets setting.

In addition, the thread that nero posted mentioned the variable cl_nodelta. This variable sets the delta compression on/off. The delta compression mean in short, the data that is sent is sent as a hole or as a difference to previous value (delta). The difference in the transmitted traffic is significant. The Himalia server forces this setting to 0 so that no client can take the delta compression off.
He hoped and prayed that there wasn't an afterlife. Then he realized there was a contradiction involved here and merely hoped that there wasn't an afterlife.
- Douglas Adams

silEnT development
http://mygamingtalk.com/
gaoesa
Site Admin
Posts: 1520
Joined: 05 Apr 2010, 15:02
Location: Finland
Contact:

Re: cl_maxpackets

Post by gaoesa »

Little bit more of the cl_packetdup setting. Something I failed to put in the previous quotes but probably is interesting to those who want to tweak their network settings.

Quoting ReyalIP again.
The description of cl_packetdup is also incorrect. cl_packetdup only affects client->server packets, and what it does is stuff N previous commands in the same packet as the current command. So at 1, every packet contains the most recent command from the client, and the previous one. Because of the encoding used, this takes very little extra bandwidth. The effect is that if N packets are missed, the one that arrives will contain all the required client commands up to that point. If there is no packet loss, the only effect is a slight increase in bandwidth usage. Server to client loss is handled in a different way.
Having cl_packetdup set to 1 is recommended because without it, you can lose some packets you might want the server receiving :P
He hoped and prayed that there wasn't an afterlife. Then he realized there was a contradiction involved here and merely hoped that there wasn't an afterlife.
- Douglas Adams

silEnT development
http://mygamingtalk.com/
Post Reply