Prediction

Prediction is the notion of the client predicting the effects of the local player's actions without waiting for the server to confirm them, minimizing the impact of latency. When the response does arrive from the server, the client's predicted simulation is checked against the actual data.

In the vast majority of cases the client's prediction is correct, and it continues happily as if there was no latency to the server. If it is incorrect, which is rare if the prediction code is written correctly, the client goes back and re-simulates all of the commands it ran with bad data. This will cause a very noticeable hitch in the player's position and state, and possibly the state of the world too.

Prediction is closely linked to lag compensation, but is separate from interpolation.

Note:Because only players are lag compensated, attempts to hit other entities (not least func_movelinear) do not benefit from prediction - you still have to lead your aim.

Implementation

To predict an entity:

1. The entity should be manipulable by the local player. Otherwise, what is the point in predicting it?
2. The functions that are to be predicted must exist and be identical on both the client and server. This is achieved by making them shared code.
3. The entity must make the call SetPredictionEligible(true), preferably in its constructor.
4. The entity must have two functions that return true for frames in which it should be predicted:
   • bool ShouldPredict(), on the client
   • bool IsPredicted(), on the server
5. Any variables that must be synchronised between the client and server must be both networked and present in the entity's prediction table.

Prediction tables

Todo: What is the effect of a variable being in a prediction table?

The prediction table describes the data in your entity that should be the same between the client and the server when the client speculatively simulates a command. It is a list of the variables that are networked and their types. If a value is allowed to vary slightly from the server's value (as in the case of a floating point number that you've sent with a reduced number of bits), then you can specify how much the value is allowed to vary. In the code below, this is done with the DEFINE_PRED_FIELD_TOL macro.

Tip:The prediction table only needs to exist in the client DLL, so you can wrap the whole thing with an #ifdef CLIENT_DLL.

#ifdef CLIENT_DLL
BEGIN_PREDICTION_DATA( CBaseCombatWeapon )
	DEFINE_PRED_FIELD( m_nNextThinkTick, FIELD_INTEGER, FTYPEDESC_INSENDTABLE ),
	DEFINE_PRED_FIELD( m_hOwner, FIELD_EHANDLE, FTYPEDESC_INSENDTABLE ),
	DEFINE_PRED_FIELD_TOL( m_flNextPrimaryAttack, FIELD_FLOAT, FTYPEDESC_INSENDTABLE, TD_MSECTOLERANCE ),	
END_PREDICTION_DATA()
#endif

Suppressing networkdata

Most weapons have shared code, the same code for client and server. This will allow the client to predict things. Non-critical things like weapon effects can be entirely done at the client, without the server sending the effectdata to all clients. In this case suppressing the data is a good idea, which results in less bandwidth usage.

The interface IPredictionSystem is meant for this. When IPredictionSystem::SuppressHostEvents(pPlayer) is called, all networkdata to that player is halted. Sending NULL again will stop the suppressing. For example:

if ( pPlayer->IsPredictingWeapons() )
	IPredictionSystem::SuppressHostEvents( pPlayer );

pWeapon->CreateEffects();

IPredictionSystem::SuppressHostEvents( NULL );

Troubleshooting

If you add functionality to weapons and forget to follow the steps above, then an entity may jerk around or animate strangely. You can use cl_predictionlist and cl_pdump to debug this. Changing cl_pred_optimize can also help sometimes.

Now let's say you see a variable that turns red in the cl_pdump panel from time to time. Now you know that somehow the client is producing a different value for this variable than the server is. This can usually be traced down to one of the following problems:

1. The client is not running some code that the server is running. This would be the case if you had an #ifdef GAME_DLL or an #ifndef CLIENT_DLL around a piece of code that could affect the value of the variable that's turning red.
2. Another variable that can wind up affecting the value of the red variable is not being transmitted via the data table. In this case, the client's value for that variable would always be wrong (since the server never transmitted it).
3. It's also possible that you just forgot to add in the appropriate tolerance using the DEFINE_PRED_FIELD_TOL macro. For example, if you're transmitting a floating point variable with a value range of 0.0 - 255.0, and you only give it 4 bits of precision, then you're going to need a tolerance of about 17.0, or else the prediction system will think the variable's value is wrong when it is actually just different because the variable was compressed into 4 bits before sending it to the client.

Tracking down prediction problems is usually a matter of walking through any code that can affect the values that are turning red, and noticing which other variables affect their values. It can be tedious at first, but once you get the hang of it, you can track down prediction problems quickly.

See also

• Networking Entities
• Lag compensation