Vincent "Freekje" Vanloo presents his findings on some of the technical debates regarding CS:S

This article is the sole opinion of the author and does not represent the opinion of Heaven Media Ltd or the opinion of any affiliates.

Editors Note:

The larger part of Counter-Strike: Source community has always been of the opinion that the game isn’t what it should be and that it needs “fixing”. It has become apparent over time that Valve aren’t going to answer the call and as such people have taken it up on themselves to try and make improvements to the game in order to make it more suited to competitive play.

Most notably this would include the Zblock team, creators of a server plug-in that has become all but essential for those that play competitively, but many players have also taken it upon themselves to get involved. While arguments still continue to break out about the existence of the “peeker’s advantage” bug and whether LAN should use interpolate 1 and 0 there are other aspects to the game that also might need resolving.

Vincent “Freekje” Vanloo is an experienced CS:S player and has been around for some time. He has made significant contributions to many projects in the past and has currently been working on looking into the technical aspects of the game in a bid to try and settle some of these disputes. Today we can present his findings and hope that it maybe clears up some of the confusion regarding them, although he himself admits that some of his suggestions may be viewed as controversial.

In the course of time we have seen CS:Source change from an incomplete showcase game to the game we play competitively today. While some gameplay changing alterations were made by Valve, over the years it has always been the community that decides what flies and what doesn’t. But change is not always welcomed with open arms... It took Tek-9 the bigger part of their 1st css cup to get tickrate 100 servers somewhat integrated in the European community and they were not loved for forcing everyone to play on their server during the cup. A month later ClanBase decided to force 66-125tick servers and nowadays it’s just as integrated as the mr15 round system.

Before we dive into the commands I’d like to get rid of the oldest CS:S myths around : “The Phantombug”. There is no such thing as the phantom bug. The game engine does not generate a number between 1 to 10 & scales your bullet registration to it, a hard disk with faster writing speed does not help. The “cssfix.reg” files only clean your registry clutter & give you the feeling like you just formatted your harddisk. You can find thousands of other mad scientist theories on the steampowered forums.

Some of these commands & value’s that I’m going to explain are already known and were proposed by various players over the last months/years. Yet they have only been used at the bigger LAN events and in a few cases online. These commands improve the smoothness and enjoyment of the game.

The use of Interpolate 1 offline.

I’m not going to bore you with the whole explanation of the netcode in CS:S. But it comes down to that the fact that with interpolate 1 the hitbox has a 100ms delay on the player model. Now for the greater time we have been using Interpolate 0 on European events and I’ve always supported this by pushing it at all the Benelux events I’ve been too. But when Dignitas (the old CGS Birmingham Salvo team) got rolled by LowLandLions (Current Fnatic) they came up with the reasoning that it’s not normal to play a whole year with Interpolate 1 to then play a play style that does not work on European events (since in the US and on some UK events interpolate 0 was never used). Ritch then asked for a public opinion (http://www.cadred.org/Forums/Thread/67460/ ) and ever since, the bigger events have and will be using interpolate 1. Interpolate 1 on LAN can be accomplished by setting sv_lan to “1” and sv_unlag to “1” as well.

Maxrate of a server

By putting a cap on the maxrate, you’re putting a cap on the maximum data a client can receive on the server, the unsent data ( after this cap ) is represented as choke in your net_graph. This is all good and well but the generalized cap is set at 25000bytes, while the server can send out around a good 40000bytes/sec of data ( while spawning for example ) Meaning that if we set sv_maxrate to 25000 we are delaying the dataflow of the server. Yet again, the bigger European events have been using sv_maxrate 100000 for a while and some ESL configs already include sv_maxrate 100000. But it’s not a default like it should be. A nice dataflow can be accomplished by setting sv_maxrate to “100000”.

fps_max (client sided)

Everyone will have experienced a match where some players just won’t drop dead. Although this is mostly a mix of different factors, this is also partially client side related. The fps_max command is linked with the output seen in your net_graph (-also controlled by cl_cmdrate-). Setting your fps_max to a value below 100, you cap the data you send out and this affects your ability to get hit by a bullet. Zblock recently forced fps_max 60 and higher which is a step in the right direction but the effect is still noticeable when the value is set to anything below 100. Do note that the output in net_graph is an average and that there is no real way to test “hitablity” but I’m sure there are enough players who can vouch that even on LAN with servers that are set up properly, people with lower fps are harder to hit.

Fps_max (server sided)

This command caps how often the server checks for game packets, at 1000 the server checks 1000times a sec ( 1ms ) , at 500 this would be 2ms. As you have guessed by now, the difference between 500 and 1000 is noticeable on top of the 110ms delay you already get from interpolate. But there is an undocumented catch : The stability of this fps influences the bullet registration. If you have server fps spikes your bullet registration will not be as it should be. The reason that this is undocumented is because it’s something that’s impossible to test, it’s only the gut feeling of both 1.6 and CSS players that feel how higher & stable the server FPS is, more the reg feels like being on LAN. The stability of servers has recently been tested in 1.6 : (http://alexhjelm.se/?p=281) and as for my findings in Source I’m actually quite surprised, in a both ways. You monitor your server fps with a website like www.fpsmeter.org or by using rcon stats in game. Do take note of the following fact :

SourceTV causes server fps instability.

Now to make that undocumented catch a real pain in the ass there is the fact that if you run a SourceTV on your server it doesn’t need to have spectators or even be recording a demo, you will have unstable server FPS. This is a known bug and there is absolutely nothing you can do about it.

Default fps_max 0 SourceTV disabled

Default fps_max 0 SourceTV enabled

As you can see the drops that SourceTV causes are close to the range of 500FPS , so I’ve run the same test with the fps locked at around 500 in the hope the drops would be minimal.

Default fps_max 500 SourceTV enabled

Unfortunately we are still receiving drops, these are now scaling down to the 400FPS region though.

I’m not suggesting we stop using SourceTV all together, but it would be wise if during a game that has no use for the sourcetv, demo- or spectator wise, it would best to turn off the tv.

The community has always been stubborn to use add-ons/commands that improve the game. The “stripper add-on” has been around since 2005 and is still not a generalized add-on both on- and offline. A “defuse-kit bug-fix” was already released in early 2007, yet has only been in use since Zblock picked it up. It’s time to finish the shape of this game ourselves and stop waiting for Zblock and the likes to bring us gameplay changing updates that have actually been around for ages.