Getting Started
This guide assumes you understand prediction version 1 already. Many instances of this guide will reference the version 1 guide. A better guide targeted to absolutely new prediction developers will be available in the future.
Example Script
Much like Prediction V1 you will create a Replicate and Reconcile method. However, in version 2 you will find these methods are easier to implement and understand, as well more flexible.
First we're going to create our datas. There's a good chance you will not need to change these compared to any V1 data containers you've already written.
Below are containers for replication and reconciliation of a rigidbody.
Learn more about using PredictionRigidbody.
Like version 1, we're going to subscribe to OnTick and OnPostTick using the OnStart and OnStopNetwork callbacks. Replicates will be run in OnTick and Reconciles OnPostTick. Only rigidbodies need to use OnPostTick to reconcile after the physics simulation; non-rigidbody controllers can replicate and reconcile using OnTick.
In this example the rigidbodies can 'jump'. One-time inputs still must be collected in update, though this is something we're looking to improve the work flow on. Here's fields to get the script started.
Similar to version 1 the jump input is collected in update.
OnTick will now be used to build our replicate data. Since this is a player controlled object only the owner needs to build the data. If not owner default is returned.
Notice prediction V2 uses a different attribute and method signature for replication.
On non-owned objects a number of replicates will arrive as ReplicateState Created, but will contain default values. This is our TimeManager.RedundancyCount feature working.
This is normal and indicates that the client or server had gracefully stopped sending states as there is no new data to send. This can be useful if you are Predicting States.
As expected OnPostTick will be used to build a reconcile data and send it to clients.
The Reconcile method also has a different signature and uses a different attribute.
NetworkObject Inspector Changes
PredictedObject is not used in version 2. Previously, in version 1, PredictedObject would try to guess an objects future state based on position and velocities. Now in version 2 input and world states are forwarded to clients, having no need for PredictedObject. The example just above of more advanced replicates is a demonstration of how to custom implement future or predicted states.
To activate prediction you must enable Use Prediction. You will find some options disabled as the alternative to them are not yet complete.
As before you must set the Graphical Object.
Owner interpolation is over how many ticks to interpolate the graphics when you own the object. Typically a value of 1 is fine; this will begin moving the object as soon as the input is given by the owner.
Enable Teleport will allow you to set distances which an object's movement must exceed in order for the smoothing to teleport rather than occur over time.
Adaptive Interpolation and Interpolation are both disabled at this time. Adaptive Interpolation will be primarily used for non-owned objects which are affected heavily by physics. The adaptive setting will use runtime values to regularly calculate the best way to smooth objects to reduce desynchronization artifacts. Once available additional adaptive options will be revealed when enabled.
With Adaptive Interpolation disabled a set interpolation interval will be used, just like Owner Interpolation. A set interpolation is ideal for objects which are not at all, or lightly influenced by physics. Examples are character controllers, or rigidbody controllers that set velocity rather than carry force.
Networked Non-Controlled Physics
Many games will require physics bodies to be networked, even if not controlled by players or the server. These objects can also work along-side the new state system using the same information above.
The code will be very similar to our example above, only removing input fields on the MoveData.
Last updated