You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
## [1.8.0] - 2025-08-17
### Added
* The Playmode Tool's Importance Visualizer drawer that helps visualize Importance Scaling outcomes.
* The `GhostDistancePartitioningSystem.AutomaticallyAddGhostDistancePartitionSharedComponent`, which allows you to opt-out of the default behaviour (of always adding a `GhostDistancePartitionShared` to all valid ghost instances), enabling you to filter your importance scaling on the existence of this shared component (without having to rip out the entire implementation).
* Test coverage of `GhostImportance.BatchScaleImportanceFunction` and `GhostImportance.ScaleImportanceFunction` has been improved (via NetcodeSamples tests), particularly in cases where the `GhostDistancePartitionShared` (or user-code equivalent) is only added to a subset of all ghosts (i.e. used as a filter).
* Support for Forced Input Latency via `ClientTickRate.ForcedInputLatencyTicks`, with new fields `NetworkTime.InputTargetTick` and `NetworkTime.EffectiveInputLatencyTicks`, and new input system `ApplyCurrentInputBufferElementToInputDataForGatherSystem<TInputComponentData, TInputHelper>` (which was needed to correctly handle `IInputComponentData` incremental values).
* `NetworkTime.NumPredictedTicksExpected` denotes the (un-batched) number of predicted ticks that the client is expected to run within this prediction loop update.
* [Experimental] Server and Client Profiler Modules for the Unity Profiler Window as an alternative to the web profiler. Adds new stats and includes per-component stats. Requires Unity 6 or newer. Set the script define NETCODE_PROFILER_ENABLED to enable this feature.
### Changed
* **Behaviour Breaking Change:** `GhostDistanceImportance` scale functions no longer multiply the `baseImportance` by 1000, as that is now performed automatically by the `GhostSendSystem` (see new `GhostSystemConstants.ImportanceScalingMultiplier` constant), removing the final importance 1000x discrepancy between ghost chunks that use importance scaling, and ones that don't.
* Input systems that write the `NetworkTime.ServerTick` into `AddCommandData` calls should instead use `InputTargetTick` for correctness. This value only differs from `ServerTick` when input latency is encountered (see `ForcedInputLatencyTicks` and `MaxPredictAheadTimeMS`).
* `NetworkTime.ToFixedString` output has been extended to reflect the new Forced Input Latency data.
* Updated com.unity.transport dependency to 2.5.3 from 2.4.0
### Fixed
* Instead of constantly mispredicting, `MaxPredictAheadTimeMS` will now correctly add forced input latency to the client when said clients RTT is higher than this value.
* A potential crash with buffers and prediction switching stripping when your prefab contained a non-zero sized IBufferElementData that was marked for prediction/interpolation only. When restoring any buffer to their prefab value, the wrong length was used, potentially leading to a memcpy overwriting memory.
Copy file name to clipboardExpand all lines: CHANGELOG.md
+28-5Lines changed: 28 additions & 5 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -2,6 +2,31 @@
2
2
uid: changelog
3
3
---
4
4
5
+
## [1.8.0] - 2025-08-17
6
+
7
+
### Added
8
+
9
+
* The Playmode Tool's Importance Visualizer drawer that helps visualize Importance Scaling outcomes.
10
+
* The `GhostDistancePartitioningSystem.AutomaticallyAddGhostDistancePartitionSharedComponent`, which allows you to opt-out of the default behaviour (of always adding a `GhostDistancePartitionShared` to all valid ghost instances), enabling you to filter your importance scaling on the existence of this shared component (without having to rip out the entire implementation).
11
+
* Test coverage of `GhostImportance.BatchScaleImportanceFunction` and `GhostImportance.ScaleImportanceFunction` has been improved (via NetcodeSamples tests), particularly in cases where the `GhostDistancePartitionShared` (or user-code equivalent) is only added to a subset of all ghosts (i.e. used as a filter).
12
+
* Support for Forced Input Latency via `ClientTickRate.ForcedInputLatencyTicks`, with new fields `NetworkTime.InputTargetTick` and `NetworkTime.EffectiveInputLatencyTicks`, and new input system `ApplyCurrentInputBufferElementToInputDataForGatherSystem<TInputComponentData, TInputHelper>` (which was needed to correctly handle `IInputComponentData` incremental values).
13
+
*`NetworkTime.NumPredictedTicksExpected` denotes the (un-batched) number of predicted ticks that the client is expected to run within this prediction loop update.
14
+
*[Experimental] Server and Client Profiler Modules for the Unity Profiler Window as an alternative to the web profiler. Adds new stats and includes per-component stats. Requires Unity 6 or newer. Set the script define NETCODE_PROFILER_ENABLED to enable this feature.
15
+
16
+
### Changed
17
+
18
+
***Behaviour Breaking Change:**`GhostDistanceImportance` scale functions no longer multiply the `baseImportance` by 1000, as that is now performed automatically by the `GhostSendSystem` (see new `GhostSystemConstants.ImportanceScalingMultiplier` constant), removing the final importance 1000x discrepancy between ghost chunks that use importance scaling, and ones that don't.
19
+
* Input systems that write the `NetworkTime.ServerTick` into `AddCommandData` calls should instead use `InputTargetTick` for correctness. This value only differs from `ServerTick` when input latency is encountered (see `ForcedInputLatencyTicks` and `MaxPredictAheadTimeMS`).
20
+
*`NetworkTime.ToFixedString` output has been extended to reflect the new Forced Input Latency data.
21
+
* Updated com.unity.transport dependency to 2.5.3 from 2.4.0
22
+
23
+
### Fixed
24
+
25
+
* Instead of constantly mispredicting, `MaxPredictAheadTimeMS` will now correctly add forced input latency to the client when said clients RTT is higher than this value.
26
+
* A potential crash with buffers and prediction switching stripping when your prefab contained a non-zero sized IBufferElementData that was marked for prediction/interpolation only. When restoring any buffer to their prefab value, the wrong length was used, potentially leading to a memcpy overwriting memory.
27
+
28
+
29
+
5
30
## [1.7.0] - 2025-07-29
6
31
7
32
### Added
@@ -12,9 +37,9 @@ uid: changelog
12
37
13
38
* Removed `ENABLE_HOST_MIGRATION` define which hid the host migration feature, it's now enabled by default. This also enables by default the `NetworkStreamIsReconnected` component which works without host migration.
14
39
* Refactor host migration API
15
-
* Removed `MigrateDataToNewServerWorld`/`ConfigureClientAndConnect` helper functions. They'll be in the docs and sample instead.
16
-
* Renamed `HostMigrationUtility`->`HostMigrationData` and in that class renamed `Get/SetHostMigrationData` to `Get/Set` (class only contains data methods) with parameters reflecting directionality of data buffer and world. Removed `TryGetHostMigrationData`, use `Get` instead (native list version).
17
-
* Removed `DataStorageMethod` as it no only has one enum value.
40
+
* Removed `MigrateDataToNewServerWorld`/`ConfigureClientAndConnect` helper functions. They'll be in the docs and sample instead.
41
+
* Renamed `HostMigrationUtility`->`HostMigrationData` and in that class renamed `Get/SetHostMigrationData` to `Get/Set` (class only contains data methods) with parameters reflecting directionality of data buffer and world. Removed `TryGetHostMigrationData`, use `Get` instead (native list version).
42
+
* Removed `DataStorageMethod` as it no only has one enum value.
18
43
* The ghost component serialization method in the host migration feature changed to a much better performing one.
19
44
20
45
### Fixed
@@ -23,8 +48,6 @@ uid: changelog
23
48
* Issue where `NetCodeConfig.EnableClientServerBootstrap` was not visible within the `NetCodeConfig`.
24
49
* Issue when running a webgl player where you could not connect or receive connections from non-webgl platform players.
Copy file name to clipboardExpand all lines: Documentation~/ghost-snapshots.md
+2-2Lines changed: 2 additions & 2 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -42,8 +42,8 @@ E.g. `NetworkTickRate:30Hz`, `MaxSendRate:45` means 30Hz is the actual maximum s
42
42
43
43
### __Optimization Mode__ options
44
44
45
-
*__Dynamic__: The ghost is optimized for a small snapshot size when both changing and not changing.
46
-
*__Static__: The ghost isn't optimized for a small snapshot size when changing, but isn't sent at all when it's not changing.
45
+
*__Dynamic__: This is the default setting. Use this when you expect the ghost to change often. The ghost is optimized for a small snapshot size when both changing and not changing.
46
+
*__Static__: Use this when you expect the ghost to change infrequently. The ghost isn't optimized for a small snapshot size when changing, but isn't sent at all when it's not changing.
Copy file name to clipboardExpand all lines: Documentation~/interpolation.md
+16-6Lines changed: 16 additions & 6 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -33,15 +33,25 @@ The term dead reckoning is also used in a similar context as extrapolation, but
33
33
34
34
## Timelines
35
35
36
-
Any given client has two timelines at the same time: the [predicted](intro-to-prediction.md) timeline that runs in your game's 'present', and the interpolated timeline that shows delayed (due to network latency) server values. Refer to the [time synchronization page](time-synchronization.md) for more details.
36
+
Clients operate on three different timelines simultaneously:
37
+
1. The client input target tick timeline (i.e. the 'present') - which must be ahead of the server to ensure that inputs you poll are sent to the server in time to be processed (by said server).
38
+
2. The [client predicted](intro-to-prediction.md) timeline - which is where the client non-authoritatively predicts its own future position - which typically runs on the same timeline as the input gathering timeline above, except when [Forced Input Latency](optimizations.md#using-forcedinputlatencyticks) is enabled.
39
+
3. The interpolated timeline - which runs behind the server authoritative simulation timeline, as it plays back interpolated `GhostField` values from received snapshots, and is therefore delayed by `RTT/2 + InterpolationTimeNetTicks`. Refer to the [time synchronization page](time-synchronization.md) for more details.
37
40
38
-
Server-side, there's only one timeline: the present timeline.
41
+
Server-side, there's only one timeline:
42
+
* The server authoritative simulation timeline (i.e. the 'present' from its POV).
39
43
40
-
In total, there are three timelines:
44
+
> [!NOTE]
45
+
> The server is the authority on the current time (& tick), as well as the rate at which time passes.
41
46
42
-
- The server's present timeline (`NetworkTime.ServerTick`)
43
-
- The client's predicted timeline (`NetworkTime.ServerTick`)
44
-
- The client's interpolated timeline (`NetworkTime.InterpolationTick`).
47
+
Therefore, in total, there are four timelines (or 3, if not using Forced Input Latency):
Use data compression to reduce bandwidth consumption, minimizing the likelihood that a player will experience gameplay issues as a result of bandwidth limitations.
4
+
5
+
> [!NOTE]
6
+
> Netcode for Entities defaults to a bandwidth-intensive snapshot send configuration to enable you to get up and running quickly. It's expected and recommended that you modify the default bandwidth consumption before releasing a game into production. Refer to the [optimizing performance page](../optimizations.md) for more information about ways to optimize your game.
7
+
8
+
## Quantization
9
+
10
+
Quantization involves limiting the precision of data for the sake of reducing the number of bits required to send and receive that data. A float takes up 32 bits, giving it an approximate range of `±1.5 x 10^−45 to ±3.4 x 10^38` with the IEC 60559 standard, which is more precision than most games need. For example, if you don't need millimeter precision, setting a quantization value of `100` cuts off all sub-millimeter noise from your floats, reducing the amount of bits required to send your float values.
11
+
12
+
Quantization can cause issues when used with client-side prediction. Refer to the [prediction edge cases page](../prediction-details.md) for more details.
13
+
14
+
### Compression model
15
+
16
+
Netcode's quantization is optimized for [Huffman delta compression](https://en.wikipedia.org/wiki/Huffman_coding) to be executed on top of it, which means that you'll get the most bandwidth gains by sending small values (including small deltas between values).
17
+
18
+
For example, sending `123456789.123456789` (for a new ghost spawn, for example, where delta compression will delta against a baseline of 0) with a quantization value of `10` would result in Netcode replicating a value of `1234567891`, which wouldn't produce much optimization at all, since the number of bits used to Huffman encode a delta of `1234567891` is large. Since the Netcode for Entities compression model uses buckets of values to compress, with lower values getting a lower bit count, you won't see much difference in compression between different high values, but you will with low values.
19
+
20
+
So sending `0.123456789` with a quantization value of `10` would send only the value `1`. Huffman compression would use only 3 bits for this. Quantization of `100` would use 7 bits, `1000` would use 13 bits etc. You can test this yourself using `StreamCompressionModel.Default.GetCompressedSizeInBits(some_uint_value)`. To test the size of `0.123456789` with Quantization of `100`, multiply 0.123456789 by 100, cast to uint (cut off the digits after the comma) and call `StreamCompressionModel.Default.GetCompressedSizeInBits(12)`.
21
+
22
+
## Delta compression
23
+
24
+
As mentioned above, sending smaller values results in smaller amount of bits needed for the same type. A 32 bit float can be sent using less than 8 bits if it only changes a little. Games are usually composed of objects moving in small steps (rather than constantly teleporting), and sending the delta between each value change instead of the absolute value each time results in great bandwidth optimization gains. Use the [`Composite` property on `GhostFieldAttribute`](https://docs.unity3d.com/Packages/com.unity.netcode@latest?subfolder=/api/Unity.NetCode.GhostFieldAttribute.html#Unity_NetCode_GhostFieldAttribute_Composite) to customize delta compression for a component.
25
+
26
+
Note that delta compression is calculated against a baseline. For [pre-spawned ghosts](../ghost-spawning.md#pre-spawned-ghosts), this baseline is updated against the ghost's initial value instead of zero.
0 commit comments