—

Our lovely and most excellent server host is moving our machine.
As a result, we lose our IP.
Nothing I can do about it at this point and I just got word of the new IP about 2 hours ago.
We have a small bleed over for the old IP and the new IP.

Thanks again to all teams that participated.  We hope you enjoyed the tournament as much as the rest of us and hope to see you again next year.

Team I Don’t Know:

Staby

Maniac

Persistant

ikonoclast

The team won a best of 3 map match up taking the final two maps. Team DickPirates won on map de_season 16 - 12, I Don’t Know was victorious on de_nuke 13 - 9, and de_inferno 13 - 7.

Blizzard and Warhammer have both released new cinematic trailers for The Wrath of the Lich King and Age of Reckoning, respectively. Blizzard has always released amazing trailers for anything they do - their cinematics are unrivaled in their awesomeness. Warhammer has pulled a rabbit out of their hat and released something absolutely amazing too.

For anyone who doesn’t know what these two games are - (From Wiki)

World of Warcraft: Wrath of the Lich King is the upcoming second expansion for the massively multiplayer online role-playing game (MMORPG) World of Warcraft, following The Burning Crusade. It is set in the land of Northrend, home of the Lich King, Arthas Menethil/Ner’zhul. It was confirmed on the first day of BlizzCon 2007, August 3, 2007.^[3][4]

Warhammer Online: Age of Reckoning (officially abbreviated as WAR^[5]) is an upcoming massively multiplayer online role-playing game based on Games Workshop’s Warhammer Fantasy setting. It is currently under development by Mythic Entertainment and is scheduled for a simultaneous release in North America, Europe, Asia, Australia and New Zealand on September 18, 2008. ^[3] The game revolves around the continual worldwide conflict that the Warhammer Fantasy setting is known for, and the game will be geared toward ongoing, constant war.

But, you already knew all of that, didn’t you. The real question is, which one (if any) are you getting?

Enough stalling - here’s the good stuff. Enjoy!

Warhammer

WOTLK

Both teams should reach out to each other to schedule the Final Match before next Sunday August 31st. The match time should should be posted in the forums so that others can know the event scheduling.

The Final Round map will be de_dust2.

If you should need any assistance, please post in the forums and an oPg community member will assist you.

Good luck to both teams!

DDR Freestyle is simply actual dancing to DDR songs while still hitting the steps. Rather than looking like a penguin robot having a seizure, you actually look like you are dancing. A sketchy idea in theory. As you can imagine, it is incredibly difficult to choreograph a routine when you have already been given the steps. Steps which rarely make sense in any genre of dance.

As you can imagine, freestyle never really panned out for 99% of the population. Most people could never choreograph anything which was actually pleasing to watch. They would just waggle their arms and hips while dropping the occasional knee. After the novelty of watching them make an ass of themselves wore off, freestyle became embarrassing to watch.

Freestylers were like the LARP (live action role playing) nerds you occasionally see down at the park in their cloaks and costumes. 99% of freestyling was just horrible. Don’t take me the wrong way, though. Despite the bile I am spewing about freestyle, there are some genuinely fun and original routines.

There is hope!

Some people actually combined the time and effort with enough artistic ability to create something entertaining and fun. I’ve picked some of my favorites and they are as follows:

Top 3 (As Picked by me)

1st Place - Kevin Kim’s Single Freestyle Dam Dariram routine at SVGL Golfland. Best. Freestyle. Ever. His whole routine is just amazing.

2nd Place- Then we have the A-Team (My favorite DDR freestyle group, ever) throwin down Brilliant. They never fail to disappoint. Not to mention they almost single handedly invented freestyle.

3rd Place - The smidget playing Pump It Up (PUI). Moves are impressive, musicality is pretty bad. Still, he’s so smooth it’s worth a watch.

Blake is your typical American middle child. He doesn’t really like school - a Christian Academy where his personal style is stifled and he is forced to obey ’silly’ rules. He is also shy and full of big dreams.

Blake happens to be good at Guitar Hero. Much better than your average joe, but not quite as good as the truly gifted. Blake has won a few tournaments and has snagged some chicken sandwhiches as prizes, but Blake is not on the level of  iamchris4life. Regardless, Blake bugs his parents until they let him drop out of school to pursue a career in guitar hero. The conditions of the agreement were Peeble was to be home schooled.

Not to be harsh, but that is downright idiotic. Not because he is bad at Guitar Hero, but because there is no future in GH. Half the fanboys in the audience want to kill me right now, so I’ll say it again. GH is doomed to eventually die. I’m not saying that rhythm games will eventually die, as I doubt they will. I’m just saying that the general trend in rhythm games does not purport a future in one subgenre.

For any remaining skeptics out there, look at

The History of Rhythm Gaming.

The first modern rhythm game released was PaRappa the Rapper, released for the original Playstation. It set the trend all other rhythm games would follow - you timed a button input to a cue on the screen set to music. More accurate presses with fewer missed cues would net you a higher score.

Bemani, arguably the king of 90’s rhythm gaming followed by releasing a slew of games, the most notable being Dance Dance Revolution and Beatmania. DDR was the infamous ‘dance simulation’ where button presses were made by the feet. Beatmania was the ‘DJ simulation’ featuring 5 or 7 buttons and a turntable. Spinoffs followed, thus Pump it Up and In The Groove were born.

Dance games managed to corner the market until around 2003. From 2003-2005, we saw Amplitude, Karaoke Revolution, Donkey Konga, etc. No game could manage to corner the market the same way DDR did.

Then Guitar Hero was released. Something about making an ass of yourself while pretending to be a rockstar struck a serious chord with the American public. Instant success followed the release of the game. After a few sequels and a quibble between Activision and Harmonix, Rock Band was released.

Currently Rock Band and Guitar Hero dominate the music industry.

As you can see, there have been quite a few turnovers in the rhythm industry. Even the most popular series couldn’t stand the test of time. Very few people still compete in DDR or IIDX in comparison to the prime of either.

The Trend

There is a definite reason for all the turnovers. There is a trend in the rhythm game industry. A trend which DDR and Beatmania followed. Rock Band and Guitar Hero are headed in the same direction.

All rhythm games have a similar motivation to keep players playing: the desire execute more control over the input device. New players are hooked by the short learning curve from beginner to intermediate; advanced and elite players keep playing to ‘master’ the hardest songs. Songs which get harder and harder each time a new iteration of the game is released.

When a successful rhythm game released, a large number of people are hooked and a few rise to ‘elite’ status. The elite eventually master the hardest difficulty level. To prevent losing their elite players, the rhythm game must release harder and harder songs each sequel. Elite difficulty evolves, becoming harder and harder; intermediate players are left in the dust.

Eventually the difficulty level becomes too hard - the input device has been pushed to the absolute limit. A ceiling on human capacity is reached and only a select few can continue reaching the new difficulty levels.

Once the elite level reaches this phase, the intermediate level has become saturated. The stagnation of the intermediate level has left the intermediate players bored. This saturation coupled with the growing gap between intermediate and elite players eventually leads to the downfall of the game. Saturation leads to public boredom and the difficulty level prevents the majority of players from becoming elite.

DDR is the perfect example of this. A few years in, the hardest song was Max 300 with easy rhythm patterns and 555 steps. A few releases later, MaxX Unlimited, Legend of Max, and Max.(period) all increased the difficulty. Then they put all those songs together in a quartet. Finally, ITG introduced songs like Pandemonium with over 800 steps and complicated rhythm patterns. Shortly after Pandemonium, the dance simulation scene fell apart.

The elite difficulty had become too difficult for the average joe to aspire to and the intermediate difficulty had become saturated and thus stagnated. Everyone got sick of DDR and the industry moved on.

(Someone with a similar view on this topic can be read here)

The Problem

We have wandered extremely far from our original topic. To return to why Blake Peeble has no future in Guitar Hero: Guitar Hero will follow the same trend other rhythm games have. It may not be soon, but it will happen. It will eventually die. When it does, Peeble will be stuck with a completely useless skillset.

Rhythm game skillsets do not transfer between rhythm games. The same way instrument skillsets do not transfer from one instrument to another. Su re, music theory may be universal, but the skills required to play an instrument are almost entirely unique to a given instrument.

That is Peeble’s problem. What will he do in X years when Guitar Hero dies and he has no education, no life skills, and no qualifications for a decent job? He will have no future. Like a washed up child movie star, Peeble will have no where to go. Take a look at all the elite DDR players, very few besides iamchris4life managed to make the transition to Guitar Hero.

Basing your entire future off professional gaming is a ludicrous risk. Basing your entire future off rhythm gaming is another thing entirely. Even if you manage to get off the ground, your career will entirely end within the decade. Stay in school, everyone.

The source engine netcode is a little squirrelly. It always has been and it always  will be. One of the questions I am bombarded with is ‘How do I fix XYZ to make the game run better?’ In order to make the universe a slightly better place, I’m going to try and help all of you.

Articles in this series will include:

1. The basics of how source netcode works
2. How the source engine compensates for an imperfect environment
3. Understanding the Netgraph
4. Optimization Guide
5. Everything else advanced and so far not covered (You are Here)

What’s left?

There are mountains of things left, in all honesty. Source is not a simple or shallow topic. Most of the topics left are either worthless or impossible to understand without access to the source of the source engine.

The two remaining topics of the most instrumental value are cl_interp_ratio and Server FPS.

One is relatively useable and the other is good information, considering there are huge misconceptions running around about it.

cl_interp_ratio

A long time ago, the dilapidated cl_interp command was replaced with cl_interp_ratio. This change was welcome, considering cl_interp was defaulted for cl_updaterate 20. No one was using cl_updaterate 20 anymore and the information on how to set cl_interp to make interpolation useful was not readily available. Accordingly, we got cl_interp_ratio.

For anyone who wants to know that old equation, it was

cl_interp = 2 / cl_updaterate

cl_interp_ratio does the work of setting interp based off of your cl_updaterate for  you. It works pretty well. You can optimize it if you are on a server which will allow you to, but most of the times cl_interp_ratio is forced to 1.

Regardless of the server you are on, here’s the important part:

If you adjust your cl_updaterate, your interp will also be adjusted. End of story.

The new equation is

cl_interp_ratio/cl_updaterate = Interpolation

Here are some tables from Whisper’’s Wiki to help anyone who wants to optimize their ratio.

For anyone who is running  cl_interp_ratio != 1 Whisper’s Wiki has some other great tables to help you.

Server FPS

Oh dear. This topic is one of the least understood and most debated topics in the source community. The problem coming from the fact that no one really knows how this all works, they all just make the best educated guess they can based off documentation and inference.

I’ll lay it down flat with as much legitimate proof as I can muster.

The Explanation

Returning to the basic netcode: Everything that happens in a CS:S server is calculated by frames. These frames are the snapshots that we discussed earlier. The more frames a server can calculate per second, the more accurate the data will be.

This is where the ‘1000fps is best’ mentality comes from. If you look at it just from this perspective, it makes sense.  At 1000fps the server will calculate the world at 1 frame/millisecond. Compare that to 100fps which is 1 frame/10 milliseconds. (Credit: Meat Factory)

Much higher, right? Yes, but the client runs at a much slower rate due to the limit of server tickrate.

Unlike other games where server FPS directly translates to tickrate, Source has a tickrate independent of server FPS. As mentioned earlier in the series, the tickrate defines the maximum amount of updates per second a client can receive. This is where the client/tickrate come into play vs server fps.

The server may be able to calculate the world every millisecond, but the client is only sending/receiving updates every 10 milliseconds. Meaning, the server is making calculations based off old client data 9/10 times at 1000fps.

To summarize what we have to far: 1000fps servers can calculate their world at a much faster rate than 100fps servers, but clients only send data at the rate of the 100fps server. Meaning the extra calculations on the 1000fps server are based off of the same amount of data as the 100fps server.

I asked Laws from HiDef about this subject and I’ll paraphrase what he had to say.

What 1000fps is doing is making more calculations than necessary on the server side, so when the data is sent to the client it is the most accurate as possible. With a 100fps server, it will make the necessary number of calculations to play the game at near optimal performance assuming fps never dips and a bunch of other variables never fluctuate. The 1000fps server gives you that TINY fraction of a percent chance that the server will make a more accurate calculation based off of the same data.

The Good

A 1000fps server will reduce the possibility for a skewed update because of how many extra calculations it does.

The Bad

We need to consider more than just the netcode here. We don’t live in a perfect world, remember? Everything up until this point is assuming that there are NO fluctuations in any variables and we have unlimited server resources.

That is not the case.

Here is where 1000fps doesn’t look so good. It runs so fast and demands so much CPU that it can easily overload a server. Whenever anything happens in game - firefights, smoke grenades, etc. - the server is taxed. At a higher FPS, this may be too much for the server to handle and the outcome is never good.

Once overloaded, the server FPS may dive. The game server is unstable. That minute chance of a more accurate calculation is gone because the fps dropped.

The game server may also screw up the scheduling of the CPU causing all sorts of good lag spikes, etc.

End of story - 1000fps is not as stable as lower fps.

The Ugly

Now you have the readers digest version of server fps. It is time to weigh in the pros and cons.

Higher FPS (600+)

Pros:

• More calculations per second - you are less likely to end up with a skewed update. Updates will the ‘most’ accurate as possible.

Cons:

• MUCH harder on server resources.
• May cause instability issues.
• Expensive

Medium FPS (333-500)

Pros:

• Provides adequate headroom for variable fluctuation without introducing tendency for instability. (Remember, choke will occur if the the server FPS drops lower than the rate of data demanded by updaterate or rate.)
• Provides more calculations per second than low fps.
• Stable (this also depends on the server host)

Cons:

• Not as many calculations as 1000fps
• More expensive than lower FPS.

Low FPS (300-)

Pros:

• Cheapest
• If no variables fluctuate, it provides almost the exact same performance as Medium/High FPS server.

Cons:

• Fewest number of calculations. Larger possibility for inaccurate data.
• If ANYTHING fluctuates and/or goes wrong you will dip below the 100fps. Thus, susceptible to a different type of instability.

The Verdict

Recommendations are personal opinion based off my knowledge on this subject.

What should I buy?

Public  Server: 333FPS (Preferred) or 500FPS

With all the mods and addons most public servers run, having a server higher than 333fps is likely to cause instability. Although, if you are in an adequate server environment, you can 500FPS with little to no problems.

Private Server: 500fps

Private servers tend to be less demanding on server resources than public servers. You should be able to easily get away with 500fps without causing instability issues.500fps is the best combination of price and performance from most server hosts.

Do not buy a higher fps server from a worse quality server host over a lower fps server from a higher quality server host. Good hardware which has not been overloaded will produce much better results at a lower fps than an overloaded box at higher fps.

There’s Nothing Left

Thanks for reading. If you want me to cover another topic, just let me know.

The source engine netcode is a little squirrelly. It always has been and it always  will be. One of the questions I am bombarded with is ‘How do I fix XYZ to make the game run better?’ In order to make the universe a slightly better place, I’m going to try and help all of you.

Articles in this series will include:

1. The basics of how source netcode works
2. How the source engine compensates for an imperfect environment
3. Understanding the Netgraph
4. Optimization Guide (You Are Here)
   
5. Everything else advanced and so far not covered

Choke/Loss

Before I get to actual optimization, we need to understand what choke is. Choke is the server trying to send you data when you cannot accept it.

Reasons for this are as numerous as there are blades of grass in the neighbor’s lawn. I’ll cover the most common one’s, which include:

Inconsistencies in

• Frame Rate and Frame Rate vs cl_cmdrate
• cl_cmdrate vs cl_updaterate

Failure to

• Sustain necessary bandwidth (May cause Loss)
• Correctly set your Steam ‘Internet’ setting

Optimization

The above list may be small, but it covers the majority of choke related problems. Almost all choke problems are related to ‘rate’ control variables being set incorrectly.

Here’s my list of choke fixing basics. If this does not solve your choke problems, you should be able to intuitively grasp what might be causing choke from the rest of the series or Whispers Wiki.

Make sure you have enabled ‘net_graph 3′ before any of this

1. Set your Steam Internet connection setting. Set it one setting higher than your actual internet setting. Most of you will set it to “Cable/Fiber < 10M” You find this in steam via

File -> Settings -> Downloads -> “Approximate speed of your Internet Connection”

2.  Make sure you do not have LOSS problems. If you do, check with your ISP and/or GSP to see if there is something wrong with your connection or routing. Then check your router, network card, and everything else you can think of. Loss cannot often be fixed by rate settings.

3. Set your cl_cmdrate and cl_updaterate to the server’s tickrate +1. Set rate to the sv_maxrate. Set your fps_max to your cl_cmdrate.

For our 100Tick server you would set

• • cl_cmdrate 101
  • cl_updaterate 101
  • rate 30000
  • fps_max 101

The idea behind this is that you will never dip below the max packets the server can send to you. Also, your FPS should match your cl_cmdrate consistently. This will effectively eliminate the aforementioned inconsistencies.

4. If you cannot consistently sustain the fps_max, drop your fps_max to a setting you can consistently maintain. Or decrease your graphics settings to raise your fps to the fps_max settings.

Match cl_cmdrate to the new fps_max setting.

Example: I can only sustain 80 fps.

• fps_max 81
• cl_cmdrate 81

5. Evaluate. Are you still getting choke? If so

6. Begin dropping your cl_updaterate in intervals of 5 until choke is reduced or eliminated.

For a 100 tick server:

Start with cl_updaterate 100, then 95, 90, 85 etc.

7. Evaluate again. Are you still getting choke? If so

8. Match cl_cmdrate and cl_updaterate. Match with whichever is lower.

9. Evaluate again. If you are still getting choke, it is more than likely another problem. Make sure you’re not being obsessive about choke. Some choke is to be expected. This is unavoidable and trying to eliminate it will drive you crazy.

It also may be the server, try a different server.

—

The concept this whole method is based on is that you use a cookie cutter setting which will allow you to achieve optimal communication with the server. Then, you will tweak your settings until you reach something that you can handle based on your computer and internet connection.

The ‘X’ Factor

It is important to understand that there are things beyond the client’s control which can cause choke. There are also server side factors to consider. All of the following will cause choke as a fault of the server: (Credit to Whisper’s Wiki)

• Failure to sustain tickrate
• Failure to sustain fps demanded by tickrate
• Failure to sustain the fps required by or failure to sustain the sv_minupdaterate
• Failure to sustain necessary bandwidth to support updaterate and sv_minupdaterate
• Any general failure of server resources to adequately sustain the SRCDS process

In summary: If the server cannot adequately support the demands of the SRCDS process in either bandwidth or resources, there will be problems. Sometimes these problems result in choke.

One More To Go

Well, folks, with the optimization guide out of the way, we only have the advanced stuff left to cover. I’ll be covering it tomorrow. Tune back in if you’re interested in the new cl_interp_ratio and what exactly server fps means.

The source engine netcode is a little squirrelly. It always has been and it always  will be. One of the questions I am bombarded with is ‘How do I fix XYZ to make the game run better?’ In order to make the universe a slightly better place, I’m going to try and help all of you.

Articles in this series will include:

1. The basics of how source netcode works
2. How the source engine compensates for an imperfect environment
3. Understanding the Netgraph (You Are Here)
   
4. Optimization Guide
5. Everything else advanced and so far not covered

The Netgraph: Friend or Foe?

net_graph 3 can be either your best friend or your worst enemy. It provides priceless data on exactly will either optimize your experience or drive you crazy. Understanding the netgraph is the key to the former and a little restraint is the key to avoiding the latter.

First things, first - What is the netgraph and how do I get to it?

To enable the netgraph,  open your console the via ‘~’ key and type net_graph 3. It’s that simple. In the bottom of the right hand corner, you should now see something that looks like this:

Looks rather daunting. Some of the numbers are self explanatory, but most are fairly cryptic.

Decrypting the Netgraph

To help understand the netgraph, I have borrowed the infamous labeled netgraph from Whisper’s Wiki

The numbers mean the following:

1. fps: Client side FPS. This is how many frames per second the game is producing at this giving moment in time. Anything above 60 is not important in a visual sense, due to monitor refresh rates and limitations of the human eye. But as I mentioned yesterday, client FPS limits your ‘out’ packets.

As you can see in #5, the FPS is limiting the out to 78.6packets/s even though cl_cmdrate is set higher.

2. ping: is the average time in milliseconds for round trip time for packets. Meaning, it is the time it takes for you to send and then receive a packet from the game server. Keep in mind this is just the raw time for you to the server. It does not includes any client or server calculation times.

Keep in mind net_graph ping differs from scoreboard ping. Scoreboard ping is a one way calculation, net_graph is roundtrip.

3. in: Size, in bytes, of the last incoming (server to you) packet (snapshot) received by the client.

out: Size, in bytes, of the last outgoing (you to server) packet (snapshot) sent by the client.

In all honesty, 3 is worthless. There is no way to effectively influence these numbers, so you might as well forget about them.

4. in: Average incoming bandwidth in kilobytes/sec

out: average outgoing bandwidth in kilobytes/sec

4 is also worthless. As long as these numbers look relatively proportionate to the numbers you see above, you have nothing to worry about.

5. in: Average packets (snapshots) being received (server to you) per second.

This number should be very close to your cl_updaterate setting. There are times when it will be different:

Good Examples

• When the server has a lower tickrate than your cl_updaterate
• When the server has a lower sv_maxupdaterate setting than your cl_updaterate

Bad Examples (Choke will be produced)

• Server or client cannot does not have adequate bandwidth - the client will not see all in packets.
• Server does not have enough resources to sustain the server fps and the server environment.

out: Average packets (snapshots) being sent (you to server) per second.

This number should be very close to your cl_cmdrate setting. There are a few times when it will be lower:

Good Examples

• sv_maxcmdrate is lower than cl_cmdrate
• When the server has a lower tickrate than your cl_cmdrate.

Bad Examples (Choke will be produced)

• Client FPS is lower than cl_cmdrate
• Any of the aforementioned bad examples

6. Loss: Any packets (snapshots) that are lost somewhere between the server to you. This almost always results from a problem with routing, your network connection, your ISP, your router, etc. Rarely is a problem with the game.

7. Choke: In its purest form, choke is the game engine trying to send more data than it can. Expect a full look at this in the explanation guide.

Net_graph 2

For anyone who likes to use net_graph 2. Here is an explanation from the developer’s wiki.

Under the net graph, the first line shows your current rendered frames per second, your average latency, and the current value of cl_updaterate. The second line shows the size in bytes of the last incoming packet (snapshots), the average incoming bandwidth, and received packets per second. The third line shows the same data just for outgoing packets (user commands).

That’s all folks

That covers the comprehensive and in depth view of the net_graph. Expect more information on optimization this Sunday. I’m out of town tomorrow, so you’ll have to wait a few days. Sorry.

The source engine netcode is a little squirrelly. It always has been and it always  will be. One of the questions I am bombarded with is ‘How do I fix XYZ to make the game run better?’ In order to make the universe a slightly better place, I’m going to try and help all of you.

Articles in this series will include:

1. The basics of how source netcode works
2. How the source engine compensates for an imperfect environment (You Are Here)
   
3. Understanding the Netgraph
4. Optimization Guide
5. Everything else advanced and so far not covered

An Imperfect World

As I mentioned in part 1, the environment in which servers operate is not perfect. Server resources, bandwidth limitation, connection diversity,  player location vs server location, etc all contribute to an environment which is less than ideal. Accordingly, methods to compensate for these imperfections are necessary.

Source makes use of three main compensation methods: Interpolation, Input Prediction, and Lag Compensation. Throughout the rest of the article, I will be discussing the theory and practical implementation of the aforementioned.

Interpolation

The first method of compensation is entity interpolation, it also happens to be the hardest to understand. If you can make it through this section, the next two will be a piece of cake.

Servers send clients and clients send servers snapshots of their action at a rate of Xsnapshots/second. In a perfect world, this rate would be Infinitysnapshots/second. Considering we don’t live in a perfect world, it’s usually between 66-100snapshots/second. Thus, if the game engine were to only display  the received snapshots, then motion would appear jagged and choppy. In order to compensate for this problem, the source engine makes use of interpolation.

In its basic form: Interpolation is the server looking at snapshots A and C and creating a certain number of B snapshots so motion is smooth and continuous.

More advanced: The source engine goes back in time to interpolate. To understand this, you need to realize that Client Time with the server and Rendering time is offset depending on the interpolation value.

You receive a frame at client time A and then later at time C, the engine then goes back in time to just before time A and renders all the frames in between A and C. Thus your render time is usually between 10-100ms behind your client time.

Here’s an example directly from the Source Developer Wiki

The last snapshot received on the client was at tick 344 or 10.30 seconds. The client time continues to increase based on this snapshot and the client frame rate. If a new video frame is rendered, the rendering time is the current client time 10.32 minus the view interpolation delay of 0.1 seconds. This would be 10.22 in our example and all entities and their animations are interpolated using the correct fraction between snapshot 340 and 342.

So, interpolation will cause a render delay of Xmilliseconds (often 100).

For anyone who has followed me thus far, you may be wondering what happens if the packet containing frame A or frame C is dropped. Well, by default the game uses 3 packets for interpolation. That way, one packet may be dropped without issue. If more than one packet in a row is dropped, the engine will make use of Extrapolation - it takes a look at the two most recent packets and tries to make linear sense of the action between them.

That covers interpolation. Congratulations.

Practical Interp Commands

There are very few now. The old inerp system assumed a certain delay time and packet time, which was rarely used. Accordingly, problems were created by it. Ever since the interp update to the netcode, there has been very little reason to adjust interp settings as the game does a much better job of dynamically setting them for you.

Besides, most servers restrict manual configuration of the interp settings. So, if you’re one of those people who understands this enough to configure it yourself, you’re still probably out of luck.

Prediction

Next we have input prediction. Much, much easier to understand than interpolation.

Consider a player with 100ms latency (lag). Every time they input a command such as +FORWARD there is a 100ms delay from the time the user makes that command to the time the server receives it. Combine that with the added latency of the  server sending a new ’snapshot’ to all the players and you end up with a problem. All player input would be very delayed - it would start after you pressed the key and end after you let off.

To solve this problem, source uses prediction. Which is just as simple as it sounds. Using the same rules the server would use to process your commands, the game instantly predicts the results of your actions. Then that is sent to the server.

In effect, your position is ‘predicted.’ You are in effect sending the future to the server.

This is not an exact science, however, and there are occasional errors. Sometimes the server predicts your future position incorrectly. When this happens, errors are smoothed out over time via the cl_smooth command. Without this smoothing, the game would be very jerky every time an error occurred.

Keep in mind that prediction only works for you. You only predict your position, not other players’ positions.

Practial Prediction Commands

Same thing as interp. cl_smooth 0 used to make a lot of sense. After the netcode update, leaving things default does a much better job.

Lag Compensation

Lag is the basic ‘problem’ of all multiplayer games. You make an action and the server does not receive that action instantly. Rather, there is a latency period from the time you made the action and the time the server receives it. During this time, the server is still calculating the world. What you see happening is not what is really happening.

To action compensate for this problem, the source engine makes use of lag compensation. It keeps track of all player actions for 1 second and uses the following equation to estimate the time at when an took place.

Command Execution Time = Current Server Time - Packet Round-Trip-Time - Client View Interpolation

A fairly simple equation. It is flawed however. It is flawed because the server must make the decision based on client packets of action rather than just accepting client result packets.

This would explain why you may be hit by a bullet after you have ducked behind cover. The server estimated that you were still on the attacker’s screen at the  time the shot was fired. Sometimes this is the case, sometimes it is not.

• Why the room for error?
• Why calculate on the server rather than on the client?
• Why introduce the room for error, rather than make use of pixel perfect precision?

The answer to all of the above is the possibility to alter the packets. All clients must be assumed ‘clean’ for the aforementioned to make sense. Any hacking or abuse of the system would be very easy.

So, we must deal with inconsistencies and paradoxes of lag. Paradoxes created due to low packet speeds. Paradoxes avoidable in the real world due to light (the packets) traveling infinitely faster than our in-game packets.

Practical Lag Comp Commands

There aren’t any. You are entirely up to the mercy of the game engine on this one. This used to be a bad thing. If any of you remember the old lag comp videos, the lag comp engine when source was first released was horrible. There was a serious delay between rendered player position and actual player position.

Good news, that has been more or less taken care of. Huzzah!

There you have it!

That’s all for today folks. Hopefully it was a bit easier reading in comparison to yesterday.

Tomorrow should get even better. Expect a comprehensive look at the netgraph. The best and worst thing to ever happen to source.