Thread: Customizing your CSS config.cfg

Someone in hideout asked about how to turn off sprays and I said you can do that in your config.cfg (it's also called autoexec sometimes) and he was unaware of it, so I thought I would post a little guide about stuff. I didn't see one but if there is already a guide here like this then please don't hurt me.

The config file is at C:\Program Files\Steam\steamapps\{USERNAME}\counter-strike source\cstrike\cfg
{USERNAME} = your steam id
right click it and go to properties, turn off readonly. Make sure you set it back to readonly when you are done otherwise when you start CSS your file will be reset and you'll lose everything.

The settings they are at are the recommended settings unless otherwise specified.


cl_cmdrate "66"
This sets the max number of packets sent to the server per second. See !RATES on an NG server for more information.

cl_updaterate "66"
Like above, this sets the max number of packets received from the server per second. See !RATES on an NG server for more information.

cl_interp "0.01"
Sets how far ahead your computer will guess where another player is moving to in seconds.
To set this you divide your latency by 1000.

cl_interpolate "1"
Estimates where an object is between packets.

rate "25000"
Sets the maximum transfer rate from the server to the client. If you have a fast internet you want this set to 25000.

cl_lagcomp_errorcheck "1"
Enables player position error checking.

cl_lagcompensation "1"
Enables server side lag compensation.

cl_smooth "0"
This enables or disables client smoothing.

cl_ragdoll_physics_enable "0"
Setting this to 0 will disable dead bodies in the game. They will fade out instead of loitering on the floor.

cl_ejectbrass "0"
Setting this to 0 will disable the bullets from spitting out of your gun when you fire.

fps_max "100"
This is your max fps. Duh.

mp_decals "200"
This is set to 200 by default. Setting this to 0 will disable bullet holes.

cl_playerspraydisable "0"
Pyron says this does what it says it does. Thanks Pyron.

cl_crosshairscale "1200"
This scales your crosshairs but you should use the crosshair settings in game instead. I set mine smaller and thicker so it's just a big green dot. Some people prefer to use red instead. I suggest turning off blending.

bind "F1" "buy ak47; buy m4a1; buy deagle; buy primammo; buy secammo; buy defuser; buy vesthelm; buy flashbang; buy flashbang; buy hegrenade; buy smokegrenade"
Binds are at the top of the config file and allow you to set keys for certain actions like buying stuff. I have all of my F# keys set to buy different things. You can get a list of inventory codes for your binds in the autobuy file in the cstrike folder. You can also disable F10 here if you want.


When you're done close the file and right click to properties, check the readonly box or you will lose your changes.



This post may be edited, shared or spit at as the NG community deems suitable.

way back with a big update they took out 100 tic servers... so setting your cmd and update rate to 66 is good enough

Originally Posted by Pyron

way back with a big update they took out 100 tic servers... so setting your cmd and update rate to 66 is good enough

Sweet, I didn't know that. I'll edit that in there.

it help

Does the interp settings help a lot to notice the difference?
I read an article a long time ago about interp and the author in the article said if your ping doesn't jump around a lot then it's okay to leave interp at default settings. Is this true?

Originally Posted by zbone1

Does the interp settings help a lot to notice the difference?
I read an article a long time ago about interp and the author in the article said if your ping doesn't jump around a lot then it's okay to leave interp at default settings. Is this true?

I'm not sure. I did a bit of searching on it and this is what I found.
Take a deep breath and prepare for a lot of reading.

Originally Posted by Inker\\GameFAQs

Cl_interp interpolates object positions starting x seconds in the past. For example, the default cl_interp value interpolates object positions starting 100 milliseconds (.1 seconds) in the past, when your client is receiving 33 updates a second (1 / 33 = .03 seconds per update) this allows your client to receive 3 new complete updates (.1 seconds / .03 = 3.3 updates) in 100 milliseconds. In comparison, a 66 millisecond time frame would only allow 2 complete updates (.066 seconds / .03 = 2.2 updates), and a 33 millisecond time frame would obviously only allow 1 complete update (.033 seconds / .03 = 1.1). Basically the value of cl_interp is directly proportional to the the amount of updates received for interpolation, and doubling the time of cl_interp will have the same effect on the amount of updates used for interpolation as doubling the rate updates are received, assuming the rate can be doubled.

The default cl_interp value will work fine in most situations, but the problem is that it is not optimal for most situations and a better value could give you better results. The default cl_interp value (0.1) was designed to be optimal when your client is receiving 20 updates a second, which is coincidently the default value for cl_updaterate. When your client is receiving 20 updates a second your client will receive a new update every 50 milliseconds (.05 seconds), and with the default cl_interp value being 100 milliseconds (0.1 seconds) the client render time is shifted back to the exact time it takes your client to receive 2 updates, so this allows 2 updates to be used for interpolation. The advantage of using 2 updates is that your client does not need to receive both updates for interpolation, even if one update is lost, there will always be two valid updates to interpolate between. The problem with using a cl_interp value equal to the time it takes your client to only receive one update, is that if that update is lost your client has nothing to use for interpolation until it receives the next update.

However their is also a problem with using a cl_interp value that is set too high, the higher the cl_interp value the more the client render time is shifted back. This means if a player moves around a corner, the higher the cl_interp value the later they will be rendered on your client. This is because cl_interp is designed to interpolate object positions starting x (cl_interp value) seconds in past like I explained earlier, so the later interpolation starts the later objects will be rendered on your client. Using the values from my example, your client has time to receive 3 complete updates for interpolation with the default cl_interp value when your client is receiving 33 updates a second. If you adjust your cl_interp value to the time it takes for your client to receive only 2 updates, the value would be around .06 seconds (2 * 1/33). Now compared to the default cl_interp value of 100 milliseconds, object positions on your client will only be rendered 60 milliseconds in the past, this means object positions on your client will be more up to date, and since this is the exact time it takes for your client to receive two updates this value is still high enough to allow accurate interpolation even if an update is lost.

Could someone explain rates and cl_interp to me? - Left 4 Dead Message Board for PC - GameFAQs




I also found this post on the halflife2 forums.

Originally Posted by s3pReMiSis\\halflife2.net forum

for you noobs who werent around when WON was going strong, ex_interp -- now known as cl_interp, basically is the setting which hitboxes and other things are aligned up with the model

.01 is what you should use, you aim at him and he gets shot

.05 os good if .01 isnt working. you aim slightly behind with .05

cl_interp [Archive] - Halflife2.net Forums




I also found a post made by a cs:go developer about a year ago.

Originally Posted by Echo\\forums.steampowered

From the TF2 page:

The Source engine runs internal simulation at a tick interval of 15 msecs (66.67 ticks per second). Each client "usercmd" is a 15 msec timeslice (which makes it possible for prediction to work, since the inputs on both the client and server should result in the same outputs in most cases). The cl_cmdrate ConVar determines how many physical packets per second the client will try and send to the server. Note that this is decoupled from the tick interval. If the cl_cmdrate setting is low, or the client's actual framerate is low, then it's possible that a single physical packet from the client to the server will contain multiple actual "usercmd" payloads. Conversely, if the cl_cmdrate is higher than 66.67, it's possible that some physical packets will be sent to the server without any actual "usercmds" in them. Furthermore, if the client sets a low "rate" setting, then less physical packets could be sent to the server. The frequency of cl_cmdrate updates generally doesn't impact a player's ability to hit opponents, since lag compensation factors in the player's latency to the server and interpolation amount when checking whether shots would have hit opponents.

From the server side, the client's cl_updaterate setting determines how often the server will attempt to send a physical packet to the client. The basic formula is:

next packet time = current time + max( 1.0/cl_updaterate, bytes sent/rate setting )
Note:"bytes sent" includes the UDP packet header overhead of 28 bytes.In other words, if the player is requesting an updaterate of 20 packets per second, then the minimum time interval between physical packets is 50 milliseconds. However, if the player has a rate setting of 10000, and we just sent the player a 1000 byte packet, then the minimum time will be 1000/10000 or 100 milliseconds instead. If 1.0/cl_updaterate has elapsed and the server checks the "rate" part of the above equation and finds that it cannot yet send a packet, then the "choke" counter is incremented for the player. All this means is that the combination of rate, cl_updaterate, and physical packet size has forced the server to defer sending the player another packet. Thus, artificially setting cl_updaterate to a high number will usually increase "choke", especially in a busy scene, since the server is always trying to obey the user's specified rate setting. Choke is not necessarily a negative indicator, it could just mean that the cl_updaterate setting is too high.

The cl_updaterate, cl_interp_ratio, and cl_interp ConVars control interpolation (and lag compensation) in the following relationship. By default, Source games are tuned for an updaterate of 20 packets per second. This leads to an expected delta between packets of 50 msecs. Because packet loss can occur, the interpolator was tuned to allow for a single dropped packet without any hitch in the smoothness of motion perceived by the client. Thus, 100 milliseconds was chosen as the default for cl_interp (0.1 s = 2 x ( 1.0f / cl_updaterate default of 20 ) ). cl_interp_ratio defines the lower "bound" on what the actual interpolation amount used on the client. Specifically, the interpolation amount is:

min( max( cl_interp, cl_interp_ratio / cl_updaterate ), 0.25f )
Note:Server operators can clamp the allowable cl_interp_ratio and cl_updaterate settings and the clamped values are factored in to the above calculations.The Source netgraph now includes "lerp" indicator which shows the actual interpolation amount (usually 100 msec unless the server or user is forcing non-default settings). The indicator will turn yellow if the server's framerate (actual framerate on the remote machine) drops below this interval. This can be used to figure out why all of the objects in the world are no longer moving smoothly. In addition, the indicator will turn orange if the user or server has tuned the ConVars such that the interpolation amount is less than 2 / updaterate. This indicates that if there is any packet loss (or possibly choke if the choke is occurring for long periods of time due to large packets being sent over a low bandwidth rate setting) that the player will likely see sluggishness in the game.

From the network engineer at valve:

The default for cl_interp_ratio is two to allow for an occasional dropped packet w/o a visual hitch. I think amount of interp is max( cl_interp, cl_interp_ratio/cl_updaterate ) ... max( 0.1, 2.0/20.0 ) = max (0.1, 0.1) = 0.1, etc.

If update rate is 20, then packets come in at 50 msec. If interpolation is 100 msec, you can drop one packet, but get the next one, and not have run out of data to interpolate up to. That was the design of the original system and why interp was set to 0.1 seconds.

If they have a higher updaterate, then a lower interpolation amount can be fine. If they hardly ever have lost packets, I could see living with inter_ratio of 1.0. If they go less than 1.0, then the game will be somewhat stuttery, modulo at a high cl_updaterate with a fast server giving them updates close to the 66 hz max tickrate would make the visual hitching less noticeable. The other thing that impacts packet frequency is the amount of data being sent and the user's rate setting. We will "choke" packets if the rate setting for the client is too low, which will delay them. If they are only interpolating for 1/updaterate seconds, then if there is any choke at all, they will run out of data for interpolation, again causing visual hitching. This is another reason that keeping the default intep_ratio > 1 is good and why 2 is a reasonable compromise. Note that the lag compensation system takes into account the user's computed interpolation amount, so from an aiming point of view it shouldn't matter.

Updated--
here's some good community (unverified by us) information:

Sheyster's post on tradeoffs with cl_interp:
http://forums.steampowered.com/forum....php?t=1358325

How cl_interp and rates work - Steam Users' Forums