Interpreting the lagometer, rate, fps, snaps, etc.

View previous topic View next topic Go down

Interpreting the lagometer, rate, fps, snaps, etc.

Post by Roumich on Sat Jul 17, 2010 4:02 pm

dear all!


Today, i started a topic about the famous Lagometer.

I' ll try also to clear a bit the myth, fake ideas and all the crap players say about snaps, maxpackets, rate, etc.
(they may just want to justifying the fact they' ve been killed.. because of the setting of others..hoho)

To turn on your lagometer, Go to Menu/ETpro/HUD/lagometer..

That stuff is quite hard to understand and the documentation is absolutly a nightmare to read.
But i ll will try to give progressively a clear explanation about it.

I will need a few days(weeks) and many post on that topic to make it understandable.

So please. for those who are interested, be patient and come back often on that topic. I' ll update it regularly.

I don' t pretend having a full knowledge about it but i' ll try the explain what i do understand and discover about it days after days.

For those who got a good understanding of the lagometer, rate, snaps, etc,Your help is more than welcome.

Please do not hesitate to contribute by writing on this topic or sending links


Your beloved Roumich



avatar
Roumich
Admin

Number of posts : 441
Age : 43
Location : London, UK
Registration date : 2009-05-24

View user profile

Back to top Go down

Re: Interpreting the lagometer, rate, fps, snaps, etc.

Post by Roumich on Sat Jul 17, 2010 4:51 pm

Ready?

Ok. so now, you have the lagometer on.

You also have a few aspirin pills.
Believe me, you will need them.

If not, here is the console command : /cg_lagometer 1
If you don' t have aspirin, paracetamol should be fine..

The Lagometer

You can actually tell alot about you and the servers connection with the lagometer.

When you have a complainer spamming "Server LAG!!", you can check it out yourself.
Here is a little description of what this all means:

The top line is the server.
It is a fast blue line if frames are being rendered in time with the server updates.
Should it have "yellow hills" then server snapshots are being dropped, this is a server problem but as a player you can reduce your com_maxFPS, snaps, or tweak your graphic settings to raise your average framerate (cg_drawFPS 1) so it is always above your snaps setting (use in increments of 20 when you can, Quake is a 20Hz engine).

The bottom line is the players connection.
Normally green indicating a received snapshot, the higher the lines the higher your ping.
A yellow line indicates your rejecting packets (you're at your max Rate) and red that the packet was lost.
In the case of yellow increase your rate or lower your snaps. When it is red packets are being lost from the server to you, this is usually a server or internet congestion/routing problem.
Red is dead, change server's or ISP's.

LAGOMETER EXAMPLES:





LPB mean Low ping bastard..Hoho






HPB mean High ping bastard..Hoho




Source are from : Zxel

Don' t forget to take your aspirin with water.

Your beloved Roumich

_________________
Your Beloved Roumich
avatar
Roumich
Admin

Number of posts : 441
Age : 43
Location : London, UK
Registration date : 2009-05-24

View user profile

Back to top Go down

Re: Interpreting the lagometer, rate, fps, snaps, etc.

Post by Roumich on Sat Jul 17, 2010 5:24 pm

For those who really want to read some nasty, complicate, boring thing about QIII lagometer, google John Carmack Archive.

(Co-founder of ID soft)

Good luck.

Your beloved Roumich


Last edited by Roumich on Sun Jul 18, 2010 11:02 pm; edited 1 time in total
avatar
Roumich
Admin

Number of posts : 441
Age : 43
Location : London, UK
Registration date : 2009-05-24

View user profile

Back to top Go down

Re: Interpreting the lagometer, rate, fps, snaps, etc.

Post by Roumich on Sun Jul 18, 2010 2:34 pm

Morning !

today, i was reading some stuff about Time nudge.

When we write /players in the console, we can see "Nudge 0" (default setting)

So, what the hell is that??

The Q3 client likes to have two snapshots active.
The latest one and the previous one and it uses them both to interpolate player movement.

It' s mean: between the two snapshot, the game is imagining the position and make the movement more fluid.

Without that interpolation, the game would look like an old stop motion film effect. (like The old version of "the clash of the titans.hohoho great film..)

Most servers default to 20hz (meaning a packet is sent out every 50ms).
A server sends out a packet containing a snapshot of everything in the server (that is visible to you), players, riffle nad, items etc and the client receives it then another is sent out 50ms later and so on.

Once the client has received two packets, it starts to interpolate other players in the game from their old position (contained in the first snapshot) to their new position (contained in the second snapshot).

Note: We still have a delay between two client.
If a player is in USA and a other is in UK, the usa players, sent snaps to server, server sent snap to UK.

Sometime, when you spec a player, you say..damn..he have a aimbot. because you see him shooting all around a enemy and he get shot.

Well that is the delay+interpolation witch bend a bit the visual reality. (your view of the scene and it synchro)

(i hope i' ve been clear on this one..Hummm)

cl_timenudge effectively changes that behaviour by reducing the time available for interpolation.

Since the interpolation time window is 50ms (on servers that use the default 20hz), you can effectively remove it by doing cl_timenudge -50 or you can half that time by doing cl_timenudge -25.

By removing all or part of the interpolation time, you are forcing the client to show the latest position of your opponents much quicker than it would normally.
That means when you shoot at them on screen you have a better chance of hitting before they've moved far enough for you to miss.

Today, i did try to change that famous nudge.
Technicaly, i didn t see any difference.

BUT, when i checked my famous lagometer...Damn O surprise.
My connection with the server was clearly altered so i directly put it back at 0.

So, what did i learn in that stuff??

By reducing the timenudge, the game is not holding back data reducing your chances of aiming and hitting an enemy.

Negative values increase gameplay responsiveness in exchange for visual jerkiness.
Positive values increase smoothness in exchange for input/gameplay responsiveness

I' ll would go for a value = 0


See you soon on the game

Your beloved Roumich.


Source info: =W=J4M32=, UpsetChaps Guides, Strider and Networking, lag meter, and gaming consistency guide.








Last edited by Roumich on Sun Jul 18, 2010 11:06 pm; edited 1 time in total
avatar
Roumich
Admin

Number of posts : 441
Age : 43
Location : London, UK
Registration date : 2009-05-24

View user profile

Back to top Go down

Re: Interpreting the lagometer, rate, fps, snaps, etc.

Post by Roumich on Sun Jul 18, 2010 3:56 pm

LAGOMETER:

In this Topic, i did try to explain how to interpret the lagometer.

If you did read the post, you may have realise how boring and hard is to interpret it.

Here is an other way to explain it:

The Top Line:
The first line is related to your graphics card updating displayed frames in time with received gameworld updates from the server.

Blue: Frames are being rendered in time with the world updates.
your fps. the faster it flows the higher your fps is. you want it to be as thin as possible, the spikier it is is due to FPS lag

Yellow: Gameworld updates are not being displayed and are being dropped.
lag spikes, mostly due to server lag, or FPS lag.

Ask fellow players if they are getting them, if they arn't your computer might be loaded with spyware or you are running other programs or ur system is too low.

Fix: Reduce your snaps or tweak your visual settings to raise your average framerate so it is always above your snaps setting.

The Bottom Line:
The second line relates to your connection and packet performance.

Green horizontal line: Packets are being received okay. its your ping. the thiner the less ping you have, it will be like a mountain range, spikes = ping spikes

Yellow: Capping is causing your client to reject packets.
If these are happening something is wrong with your internet (viruses etc) or the server

Fix: Increase your rate or try lowering your snaps.

Red lines: The packet was lost.
The amount of lines you see at one time in the lagometer is what you should set your 'packetdup' at.

/cl_packetdup "0-5" the higher your red lines, the more your value should be, this is due to you having a bad connection to the server, sometimes a wireless internet will cause this or just a plain old bad server.

Fix: Change ISP
If you have to play on the server or use the ISP then make sure that your cl_packetdup is set to 1
and try adjusting snaps and cl_maxpackets to compensate for the lost packets.

For the command "/CL_packetdup", i will dedicate an other post soon.

You beloved Roumich.

_________________
Your Beloved Roumich
avatar
Roumich
Admin

Number of posts : 441
Age : 43
Location : London, UK
Registration date : 2009-05-24

View user profile

Back to top Go down

Re: Interpreting the lagometer, rate, fps, snaps, etc.

Post by Z3RO on Mon Jul 19, 2010 12:57 am

The problem in cl_timenudge is if you granted a player to use different value them 0 this player can use it to cause false delays between him and the server, so when you try to hit him you get nothing but him get you with a headshot or a body shot. About snaps by default a server have a cvar (setting) sv_fps 20, this means the server take 20 snapshots from the entire server per second and send it to the players so if the players use a different value them 20 they have less snapshots from server or more depends wich value they use and its cause confusion in the server to interpret that player moviments/shots. Basicaly snaps and cl_timenudge need to be fixed at the default value to get a fair game for everyone in the server, if someone want to use a snaps in 40 like many times i saw that the server need to use a sv_fps 40 instead the 20 (default value), in the tournaments (clanbase / STA and others leagues) its forced to use timenudge = 0 and snaps = 20. About the cl_packetdup its by default at 1 but with if have problems in connection you can set it in a high value but it only accept 4 at maximum, this will increase the number of packets from the player to the server and sometimes will increase the stability of the connection between the server and player.
avatar
Z3RO
Admin

Number of posts : 310
Age : 41
Location : Brasil
Registration date : 2008-08-22

View user profile

Back to top Go down

Re: Interpreting the lagometer, rate, fps, snaps, etc.

Post by Roumich on Mon Jul 19, 2010 1:32 am

You are right Z3RO. That could be used in a nasty way.

We won' t let it happen on TE666 server anyway. Ha!

For the CL_packetdup, you are also right.

But the objective of this topic isn' t to tell to people what they have to do or not to do but to explain how it does work.

And i think, Mr Z3RO, your help on this topic will be needed and be more than welcome.

Thanks for your comment.

Your beloved Roumich




avatar
Roumich
Admin

Number of posts : 441
Age : 43
Location : London, UK
Registration date : 2009-05-24

View user profile

Back to top Go down

Re: Interpreting the lagometer, rate, fps, snaps, etc.

Post by Z3RO on Mon Jul 19, 2010 4:55 pm

Ok Roumich, youre telling to people how these settings works but when you give a information for someone who want to understand how it works that was great! These people can use it to get the right info to fix a connection problem or improve the stability of his connection in game, but these people can interpret this info in the wrong way and use it with bad intentions, so in my opinion to be more specific the right way to share info is telling to people how it works and what settings are allowed in the Te666 server and wich values are granted. I really apreciate a discussion about these kind of info, but we need to share these kind of info carefuly, we need to think about what info is good to improve the game and what info is dangerous to share!
avatar
Z3RO
Admin

Number of posts : 310
Age : 41
Location : Brasil
Registration date : 2008-08-22

View user profile

Back to top Go down

Re: Interpreting the lagometer, rate, fps, snaps, etc.

Post by Roumich on Tue Jul 20, 2010 2:50 am

Well,...yes.As you said in the first and second line; This topic is for understanding how does that work.
hopefully, by understanding, players will resolve some problems they could have.

After that, you are right. (4th line of you post.) "these people can interpret this info in the wrong way and use it with bad intentions"

But that is an other topic : RULES

As said on a previous post: We won' t let it happen on TE666 server anyway. Ha!

(post by Roumich on Sun Jul 18, 2010 11:32 pm..)

So, people suppose to be responsable about their knowledge, And the way they use it.

Any info is good for good people.
Naughty players will be wiped out of the TE666 server.

Let' s be positive!

You beloved Roumich.




avatar
Roumich
Admin

Number of posts : 441
Age : 43
Location : London, UK
Registration date : 2009-05-24

View user profile

Back to top Go down

Re: Interpreting the lagometer, rate, fps, snaps, etc.

Post by Roumich on Wed Jul 21, 2010 7:59 pm

Ho Ho Ho.

Today, as said above (by Roumich on Sun Jul 18, 2010 1:56 pm)

I will explain the command :"/cl_packetdup" and try to make it understandable.
(wish me good luck..Her..)


As explained above (lagometer section)

If you watch you lagometer and you see Red lines;
The packet was lost... (damn...we don' t like losing things..)

The amount of lines you see at one time in the lagometer is what you should set your 'packetdup' at.

Let' s read some theory:

cl_packetdup duplicates information from client to server in order to have a higher probability of getting input commands from the client to the server on the next packet in case of packet drop.

It gets the values of 1, 2 or 3 untill 5 for the amount of snapshots of information from the past any current snapshot from the client to server duplicates.

Turning it on is more important than it may seem at first.

This is because the lag meter is quite generous on informing us about what happened with the packets a server sends, but does not inform us about what happened with our input commands sent to the server (lazy bastard..)

Hence it's quite probable to have gameplay inconsistencies sourcing from the client->server part of the bargain while the lag meter appears to be clear.

Of course, in the quest for "absolute low latency", one could experiment with a low or disabled cl_packetdup if confident for no relevant packet loss.

As already mentioned in the lag meter section, red lines on the lag meter do not mean that cl_packetdup may certainly help.

This is because red lines reflect packet loss of information from server to client and not client to server where cl_packetdup applies.

However, since the same reason that created packet loss for server snapshots (and hence red lines) may create packet loss from client to server too (e.g. faulty network equipment and not a congested server upload) cl_packetdup to be often beneficial when red lines appear at the same time.

The occurrence of black lines on the lag meter which report the application of antiwarping, may indirectly indicate the occurrence of packet loss from client to server in which case cl_packetdup may help

(even though it may be also sourced on unstable ping).

Ok? (let' s get an aspirin..Ha..)

What on earth did i learn and understood:

This setting determines if duplicate commands are sent, range is 1 to 5.(By the way; 1 is the default config..)

if a packet gets lost then a 'backup' command may still be received.

Set to 1 as default which is recommended if you have packet loss.

If you have an excellent connection with very little or no packetloss at all then this could be set to 0 and cl_maxpackets possibly raised.

However, as with all settings experiment to see which is best suited for your connection.

I did personally put the setting at 0 because i' ve got a very low ping on the server and my connection isn' t erratic.(unlike me..Her..)

i m maybe wrong, but i seem to gain some FPS (frame per seconde)

Talking about FPS (frame per seconde), I will talk about that on my next post.


Because i don' t know what' s going on in clan war mode or official game, I hope Mr Z (or somebody else..) will have his word to explain what should be done in official game.
In advance, Thanks.

Any questions, help and love post are welcome.

Your beloved Roumich


Source :temclan, Networking, lag meter, and gaming consistency guide to Urban Terror





avatar
Roumich
Admin

Number of posts : 441
Age : 43
Location : London, UK
Registration date : 2009-05-24

View user profile

Back to top Go down

Re: Interpreting the lagometer, rate, fps, snaps, etc.

Post by jokiman on Thu Jul 22, 2010 12:38 am

Mate u lost me at Ho Ho Ho. Nice that u go to all that bother to find out shit but mate i aint got a clue what that all means . Keep up the good work
avatar
jokiman
Senior Clan Member

Number of posts : 95
Age : 51
Location : finland
Registration date : 2007-09-20

View user profile

Back to top Go down

Re: Interpreting the lagometer, rate, fps, snaps, etc.

Post by Essari on Thu Jul 22, 2010 1:38 am

Roumich wrote:Because i don' t know what' s going on in clan war mode or official game, I hope Mr Z (or somebody else..) will have his word to explain what should be done in official game.
In advance, Thanks.

// CB + ESL + CF ET Config
// Enemy Territory Stopwatch
// ETPro
// April 2010
// Version 1.3

configname "^dSummerCup ^35on5"
version 1.3 clanbase.com

init
{
setl sv_pure 1
setl sv_cheats 0

setl g_gametype 3
setl g_warmup 14
setl g_doWarmup 1
setl g_voiceChatsAllowed 99
setl g_spectatorInactivity 0
setl g_friendlyFire 1
setl g_heavyWeaponRestriction 16
setl g_medicChargeTime 45000
setl g_LTChargeTime 35000
setl g_engineerChargeTime 30000
setl g_soldierChargeTime 30000
setl g_covertopschargetime 30000
setl g_landminetimeout 0
setl g_teamForceBalance 0
setl g_filtercams 1
setl g_fastres 0
setl g_noTeamSwitching 1
setl g_knifeonly 0
setl g_alliedmaxlives 0
setl g_axismaxlives 0
setl g_speed 320
setl g_gravity 800
setl g_knockback 1000

setl team_maxSoldiers 1
setl team_maxMedics -1
setl team_maxEngineers -1
setl team_maxFieldops -1
setl team_maxCovertops 1

setl team_maxFlamers 1
setl team_maxMg42s 0
setl team_maxMortars 0
setl team_maxPanzers 1
setl team_maxRiflegrenades 1


setl match_latejoin 1
setl match_minplayers 2
setl match_mutespecs 0
setl match_readypercent 100
setl match_timeoutcount 2
setl match_timeoutlength 240
setl match_warmupDamage 2
setl team_maxplayers 0
setl team_nocontrols 0

setl sv_minping 0
setl sv_maxping 0

setl pmove_fixed 0
set nextmap ""

setl g_allowVote 1
setl vote_allow_balancedteams 0
setl vote_allow_cointoss 1
setl vote_allow_comp 0
setl vote_allow_config *
setl vote_allow_friendlyfire 0
setl vote_allow_gametype 0
setl vote_allow_kick 1
setl vote_allow_map 1
setl vote_allow_matchreset 1
setl vote_allow_mutespecs 1
setl vote_allow_muting 1
setl vote_allow_nextmap 0
setl vote_allow_pub 0
setl vote_allow_referee 1
setl vote_allow_shuffleteams 0
setl vote_allow_shuffleteamsxp 0
setl vote_allow_surrender 0
setl vote_allow_swapteams 1
setl vote_allow_timelimit 1
setl vote_allow_warmupdamage 0
setl vote_limit 99
setl vote_percent 51

setl b_mapscriptdirectory "etpromapscripts"
setl b_mapconfigdirectory ""

setl b_levels_battlesense "-1"
setl b_levels_engineer "-1"
setl b_levels_medic "-1"
setl b_levels_fieldops "-1"
setl b_levels_lightweapons "-1"
setl b_levels_soldier "-1"
setl b_levels_covertops "-1"
setl b_defaultskills ""
setl b_noskillupgrades 1

setl b_statsaver 1
setl b_intermissiontime 20
setl b_privatemessages 0
setl b_floodKickRate 10
setl b_floodKickBurst 15
setl b_floodKickTime 0
setl b_match_warmupjoin 0
setl b_multiview 0
setl b_xpstopwatch 0
setl b_spectatornames 1
setl b_shove 60
setl b_shove_noz 1
setl b_stickycharge 2
setl b_damagexp 1
setl b_antiwarp 1
setl b_panzerlevelup 5
setl b_headshot 0
setl b_riflegrenades 1
setl b_fallingbugfix 1
setl b_fixedphysics 1
setl b_fixedphysicsfps 125
setl b_campaignfile ""
setl b_defaultbantime 60
setl b_ettv_flags 3

setl b_shrug 0
setl b_wolfrof 0
setl b_flushitems 1
setl b_distancefalloff 1
setl b_helmetprotection 1
setl b_maxmortarpitch 20
setl b_chargetransfer 0
setl b_sv_hitsounds 1
setl b_realhead 1

setl b_extendedprone 1
setl b_pronedelay 1

setl b_banners 0

setl lua_modules "combinedfixes.lua"
setl lua_allowedmodules "7E3DBB8813DA82A795C63B89596DCFBFA921386B"

set g_log "global5.log"
set b_cheatlog "global5_cheats.log"

setl b_anticheat 1
setl b_cheatkicktime 1

command "pb_sv_enable"
command "pb_sv_kicklen 1"

command "sv_cvarempty"

command "sv_cvar cl_freelook EQ 1"
command "sv_cvar cl_pitchspeed EQ 0"
command "sv_cvar cl_yawspeed EQ 0"
command "sv_cvar cl_timenudge EQ 0"

command "sv_cvar b_simpleitems EQ 0"

command "sv_cvar cg_bobup IN 0 0.005"
command "sv_cvar cg_fov IN 90 120"
command "sv_cvar cg_shadows IN 0 1"
command "sv_cvar cg_autoaction IN 2 7"

command "sv_cvar rate EQ 25000"
command "sv_cvar cl_maxpackets EQ 100"
command "sv_cvar snaps EQ 20"
command "sv_cvar com_maxfps IN 40 125"

command "sv_cvar m_pitch OUT -0.015 0.015"
command "sv_cvar m_yaw IN -0.022 0.022"

command "sv_cvar r_ambientScale EQ 0.5"
command "forcecvar r_ambientScale 0.5"
command "sv_cvar r_drawentities EQ 1"
command "sv_cvar r_drawworld EQ 1"
command "sv_cvar r_lightmap EQ 0"
command "sv_cvar r_showmodelbounds EQ 0"
command "sv_cvar r_showtris EQ 0"
command "sv_cvar r_znear EQ 3"
command "sv_cvar r_allowextensions EQ 1"
command "sv_cvar r_ati_fsaa_samples EQ 0"
command "sv_cvar r_ati_truform_tess EQ 0"
command "sv_cvar r_clamptoedge EQ 1"
command "sv_cvar r_colorMipLevels EQ 0"
command "sv_cvar r_depthbits IN 24 32"
command "sv_cvar r_detailtextures EQ 0"
command "sv_cvar r_flares IN 0 1"
command "sv_cvar r_ext_ATI_pntriangles EQ 0"
command "sv_cvar r_nv_fogdist_mode INCLUDE NV GL_EYE_RADIAL_NV"
command "sv_cvar r_primitives IN 0 2"
command "sv_cvar r_subdivisions IN 1 20"
command "sv_cvar r_lodcurveerror GE 60"
command "forcecvar r_wolffog 0"
command "forcecvar r_zfar 0"

command "wait 50"

command "pb_sv_restart"

}
map default
{
set g_userTimeLimit 0
setl g_useralliedrespawntime 0
setl g_useraxisrespawntime 0
setl b_moverscale 1
setl team_maxMines 4
command "forcecvar r_drawfoliage 1"
}
map fueldump
{
set g_userTimeLimit 15
setl b_moverscale 1.5
mapscripthash E2EC013C9CB6C9F66635EDE8A2BBABA1CA87C122
}
map sw_fueldump
{
setl g_usertimelimit 15
setl b_moverscale 1.40
mapscripthash 8C9C0A73737ADC454C1D00F2CD619F0AA6360212
}
map radar
{
set g_userTimeLimit 12
command "forcecvar r_drawfoliage 0"
mapscripthash 014FEC1CED572CBFF45D6B844778F2FF9FA0DC9C
}
map battery
{
set g_userTimeLimit 10
setl team_maxMines 0
mapscripthash 61709BCD0D4DFC0BC6523E01C456F0DBE295CCD8
}
map goldrush
{
set g_userTimeLimit 15
setl b_moverscale 1.5
mapscripthash D3275D44A296BA7A2A5CA0031B069D7E8851AD0A
}
map sw_goldrush_te
{
set g_userTimeLimit 15
setl b_moverscale 1
mapscripthash D550394E603289A09DE640E1770936B94B1FBBF7
}
map oasis
{
set g_userTimeLimit 20
setl g_useralliedrespawntime 15
setl g_useraxisrespawntime 30
mapscripthash F66E3D3D51AFD5439CD7D917F4E01F96AC473145
}
map sw_oasis_b3
{
set g_userTimeLimit 15
setl g_useralliedrespawntime 20
setl g_useraxisrespawntime 30
mapscripthash DD6F3657C33F0A56C7677C629806B46D97422441
}
map railgun
{
set g_userTimeLimit 15
setl g_useralliedrespawntime 30
setl g_useraxisrespawntime 15
setl b_moverscale 1
mapscripthash EE0CE68EA03754CAEF4910C32FFF2D498830B489
}
map et_ice
{
set g_userTimeLimit 12
setl g_useraxisrespawntime 25
setl team_maxMines 0
mapscripthash 190D6B073B415C56564ABD268688042711F5FB6F
}
map tc_base
{
set g_userTimeLimit 12
setl team_maxMines 0
mapscripthash 51C412FDC12F9E1726AD46CF24BEE2FEFE582FE9
}
map reactor_final
{
set g_userTimeLimit 12
setl g_useralliedrespawntime 20
setl g_useraxisrespawntime 30
mapscripthash B3065DD47E420BFB3338F6D8F993D1ADB6ECE63A
}
map dubrovnik_final
{
setl g_useraxisrespawntime 30
setl g_useralliedrespawntime 10
mapscripthash 98718FC022E5E53A8E3131A37189E3633084F820
}
map braundorf_b4
{
set g_userTimeLimit 12
mapscripthash 0A3929F218069B42028C0DF9E84D6A7FCADC8425
}
map frostbite
{
set g_userTimeLimit 10
setl g_useralliedrespawntime 25
setl g_useraxisrespawntime 30
mapscripthash AF83E0603FC830DA883E856451CB1B02EC24DF64
}
map adlernest
{
set g_userTimeLimit 10
mapscripthash 9503D4BE40D0377B73288CF42A5EECDA71026B9F
}
map warbell
{
set g_userTimeLimit 15
setl g_useralliedrespawntime 30
setl g_useraxisrespawntime 15
mapscripthash 21C2CD515B183664F4CDF4F2EBFAF15B368EF041
}
map supply
{
set g_userTimeLimit 15
mapscripthash 346B4B9261931F5E89EF28DA24D44E4E35BE0A0B
}
map supplydepot2
{
set g_userTimeLimit 15
mapscripthash 4CE8A2E699DDAAB1787802E0A49599FE2AC434E3
}
map sw_battery
{
set g_userTimeLimit 12
mapscripthash F3C4054DC1E486F4F3AD179947434E4651E01A97
}
map sp_delivery_te
{
set g_userTimeLimit 12
setl g_useralliedrespawntime 20
setl g_useraxisrespawntime 30
mapscripthash 8E97A9BA385452B153C81C53925574E3BDA5314E
}
map bremen_b2
{
set g_usertimelimit 15
mapscripthash 14B91ABC90CE5DD9842219D8134947AEB922E0B9
}
map bremen_b3
{
set g_usertimelimit 15
mapscripthash B1BCBA74980E8BCC39790A25AD685312035E8951
}
map et_beach
{
set g_userTimeLimit 10
mapscripthash 138638DCE9A613D63CF09DC20A5A81959FAF1D8E
}
map karsiah_te2
{
set g_userTimeLimit 12
mapscripthash 1A087736727855C2A50015D0D838DB46B258F3D0
}
map wolken1_b1
{
set g_userTimeLimit 12
mapscripthash CEA279C2F1FC44DEF59025A4387D268793630B46
}
map caen
{
set g_userTimeLimit 15
setl g_useralliedrespawntime 30
setl g_useraxisrespawntime 20
setl team_maxMines 4
mapscripthash 863650731A7EF5990C00A915B5CC801E301704EE
}
map te_escape2
{
set g_userTimeLimit 15
setl g_useralliedrespawntime 20
setl g_useraxisrespawntime 30
mapscripthash A168C3994DD1332EECE8249408719F2D1E8DDC50
}
map mp_sub_rc1
{
set g_userTimeLimit 15
setl g_useralliedrespawntime 20
setl g_useraxisrespawntime 30
mapscripthash 96F8A7322CD580E4104D0FC1DADF6D371F377A76
}
map et_ufo_final
{
set g_userTimeLimit 15
setl g_useralliedrespawntime 20
setl g_useraxisrespawntime 30
mapscripthash 85D5D4C655E152D154337BBCABEC4B5111D85F13
}






Essari
Member
Member

Number of posts : 96
Age : 31
Location : Finland
Registration date : 2007-06-18

View user profile http://vhr.clangrid.com/main.asp

Back to top Go down

Re: Interpreting the lagometer, rate, fps, snaps, etc.

Post by Roumich on Thu Jul 22, 2010 2:01 am

Thx essari.

That s a loooot of lines.

I' m glad my printer doesn' t work.

But..here is the problem:

i did effectively said "Because i don' t know what' s going on in clan war mode or official game, I hope Mr Z (or somebody else..) will have his word to explain what should be done in official game."

Mean: giving a point a view of what i' m writing about......
I tried to read that fantastic copy/past and it doesn t seem to bring any complement about that command.

I even didn' t find /cl_packetdup




Your beloved Roumich



avatar
Roumich
Admin

Number of posts : 441
Age : 43
Location : London, UK
Registration date : 2009-05-24

View user profile

Back to top Go down

Re: Interpreting the lagometer, rate, fps, snaps, etc.

Post by Z3RO on Thu Jul 22, 2010 10:09 pm

The command packetdup not are restricted in the clan wars /leagues configs because it isnt cheat protected, this command not give anyhting kind of advantage if ppls use it with 2/3/4 values, it doesnt matter, this setting only helps if someone have packets loss. I use that setting in 2 (i put it in 2 for have sure no packets are loss when i was playing).
avatar
Z3RO
Admin

Number of posts : 310
Age : 41
Location : Brasil
Registration date : 2008-08-22

View user profile

Back to top Go down

Re: Interpreting the lagometer, rate, fps, snaps, etc.

Post by Essari on Fri Jul 23, 2010 4:25 pm

exactly about what Z3ro said.
If u have like cl_maxpackets in 40 those clanwar configs will force it to 100 automaticly and it gives your some cvar warnings but nothing else. So there isnt any settings which can give any advantage to you.

Essari
Member
Member

Number of posts : 96
Age : 31
Location : Finland
Registration date : 2007-06-18

View user profile http://vhr.clangrid.com/main.asp

Back to top Go down

Re: Interpreting the lagometer, rate, fps, snaps, etc.

Post by Roumich on Fri Jul 23, 2010 4:47 pm

Understood. thx

_________________
Your Beloved Roumich
avatar
Roumich
Admin

Number of posts : 441
Age : 43
Location : London, UK
Registration date : 2009-05-24

View user profile

Back to top Go down

Re: Interpreting the lagometer, rate, fps, snaps, etc.

Post by Roumich on Sat Jul 24, 2010 11:44 am

dear Geeks!


Today, i' ll try to explain the setting of FPS ( frame per second) and the max packets configuration.

The console command is: cl_maxpackets "value"



What cl_maxpackets does?

cl_maxpackets governs the max amount of packets of information the client is willing to send to the server (client->server) a second.

This is highly related to the FPS (frame per second) of the client.

Important and slightly incomprehensible bit:

Because of certain game engine mechanics that can be summed up as 'FPS is the governing cycle through which stuff are being done' (not just graphics), the client is able to send only 1 update to the server every 1 frame, or 1 every 2 frames, or 1 every 3 frames and so on.

Hence, if your FPS is 125 you can send either 125 a second, 62.5 a second, 41.7 updates a second, 31.25, 25 and so on (no rounding up is taking place). If it drops (or is set) to 100 FPS it can only send 100 a second, or 50 a second, or 33.3 a second, 25, 20 and so on.

What that means?

So, if you have a cl_maxpackets of 30 on 125 FPS, the client will send 25 updates a second.

If you have it on 100 FPS, it will send again 25 a second.

Math based on the above base logic can be made for calculating other cases.

The basic aim here is to have the lowest latency possible by trying to send the most packets per second to the server as possible.
e.g. currently on a stable FPS of 125 it appears it is best to leave it at the max value of 42.

An example of a bad decision here is that if one draws FPS at 60 the client will be able to send either 60, 30, 20 packets per second to the server.
That means it won't be able to use the max value of 42 but only 30 of cl_maxpackets.
Similarly with 100, it will only be able to send 33.3.

meaning of FPS (Command /Com_MaxFPS)

This variable controls the maximum permitted framerate.

The Q3 software engine measures time in an integer number of milliseconds. There are a thousand milliseconds in a second.
There can be no fractions in the number of frames per second that you see on your monitor;
thus, the only viable number of frame rates you can have are defined by this equation:

Viable Frame rates (FPS) = int(1000 / N)

N = time in milliseconds between frames
int() = integer function

The only valid values are those which are equal to (1000/N) where N is an integer.

Here are valid Com_MaxFPS's:

1000/1 = 1000
1000/2 = 500
1000/3 = 333
1000/4 = 250
1000/5 = 200
1000/6 = 166
1000/7 = 142
1000/8 = 125
1000/9 = 111
1000/10 = 100
1000/11 = 90
1000/12 = 83
1000/13 = 76
1000/14 = 71
1000/15 = 66
1000/16 = 62
1000/17 = 58
1000/18 = 55
etc...

To maximize the efficiency of your connection Cl_maxpackets and Com_maxfps have to be chosen in such a way as to respect the relationship between data upload rate and framerate.

The upload rate should be equal to int(Framerate/N).

Anything else is not effici
ent

It turns out that if you set your Cl_MaxPackets to a value which is not equal to Framerate/N, your Cl_MaxPackets will rounded DOWN to the next valid value!


Most of you will use MaxFPS 125. If so, your valid MaxPackets values will be as follows (assuming your PC can achieve its MaxFPS value constantly):
(always round up these calculations to integers) 125/1 = 125 125/2 = 63 125/3 = 42 125/4 = 32 125/5 = 25 etc.
You should choose the largest value that your connection can handle.

If your MaxPackets is not set to a valid value, it is a potential waste of bandwidth and therefore potential lag/instability.
For example, if your framerate drops to 100 then your valid MaxPackets values will change to: 100/1 = 100 100/2 = 50 100/3 = 34 100/4 = 25 etc.

So if you have your Cl_MaxPackets set to 100 and are using 125fps then mostly your MaxPackets will be at 63
(this is the largest value not exceeding the input Cl_MaxPackets limit).

However, when the framerate drops to 100fps, the MaxPackets will change to 100 as this is now the largest value that does not exceed the input Cl_MaxPackets limit.

If your connection cannot handle 100 packets it will cause your ping to rise or spike.
Even if it can handle the jump from 63 to 100 packets, this may well cause your ping to fluctuate more than if your actual MaxPackets were constant.

WHAT DID I LEARN FROM THAT:

choose the largest values of Cl_MaxPackets and Com_MaxFPS that your connection will allow.

If Cl_MaxPackets is not a valid value, it is a potential waste of bandwidth and therefore potential lag or instability.

The higher this number is the better your game will "feel" due to the fact that you are telling the server where you are and what you are doing more often.

set Cl_MaxPackets as high as you can without it affecting your ping (and without going over 125).
FOR TE666Server, Do not set it lower than 30. we don' t like that..err...

Higher Cl_MaxPackets will also provide you with better hit "registration", that is, you hit what you're aimin' at!
It can work both ways of course - other people can hit you with more accuracy as well.
On the opposite end, low values make it harder to be hit and vice-versa.
If you're a superior player you will score higher at high values of Cl_MaxPackets.

This mean, when a player is 30 maxpacket and an other is 100, the game still fair on BOTH CLIENT SIDE
the player with 30 maxpacket become less hittable BUT this same player will also struggle to hit the other players.

For the end:: Again, i don' t specificaly know what are the rules in clan war and competition.

But If your FPS is lower than 100, it doesn' t seem to be a good idea to set the maxpackets at 100.
Do the calcule by yourself as shown above.


Source: jockyitch/bashandslash, Networking, lag meter, and gaming consistency guide to Urban Terror


Your beloved Roumich







avatar
Roumich
Admin

Number of posts : 441
Age : 43
Location : London, UK
Registration date : 2009-05-24

View user profile

Back to top Go down

Re: Interpreting the lagometer, rate, fps, snaps, etc.

Post by Sponsored content


Sponsored content


Back to top Go down

View previous topic View next topic Back to top

- Similar topics

 
Permissions in this forum:
You cannot reply to topics in this forum