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
Copy file name to clipboardExpand all lines: com.unity.netcode.gameobjects/CHANGELOG.md
+19-5Lines changed: 19 additions & 5 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -10,15 +10,32 @@ Additional documentation and release notes are available at [Multiplayer Documen
10
10
11
11
### Added
12
12
13
-
- Added a `WebSocketPath` field to `UnityTransport.ConnectionData` (which also shows up in the inspector if "Use WebSockets" is checked) that controls the path clients will connect to and servers/hosts will listen on when using WebSockets. (#3901)
14
-
-`NetworkTransport.EarlyUpdate` and `NetworkTransport.PostLateUpdate` are now public. For the vast majority of users, there's really no point in ever calling those methods directly (the `NetworkManager` handles it). It's only useful if wrapping transports outside of NGO. (#3890)
15
13
16
14
### Changed
17
15
18
16
19
17
### Deprecated
20
18
21
19
20
+
### Removed
21
+
22
+
23
+
### Fixed
24
+
25
+
26
+
### Security
27
+
28
+
29
+
### Obsolete
30
+
31
+
32
+
## [2.11.0] - 2026-03-19
33
+
34
+
### Added
35
+
36
+
- Added a `WebSocketPath` field to `UnityTransport.ConnectionData` (which also shows up in the inspector if "Use WebSockets" is checked) that controls the path clients will connect to and servers/hosts will listen on when using WebSockets. (#3901)
37
+
-`NetworkTransport.EarlyUpdate` and `NetworkTransport.PostLateUpdate` are now public. For the vast majority of users, there's really no point in ever calling those methods directly (the `NetworkManager` handles it). It's only useful if wrapping transports outside of NGO. (#3890)
38
+
22
39
### Removed
23
40
- Removed un-needed exceptions on `NetworkObject.cs`. (#3867)
24
41
@@ -28,9 +45,6 @@ Additional documentation and release notes are available at [Multiplayer Documen
28
45
- NestedNetworkVariables initialized with no value no longer throw an error. (#3891)
29
46
- Fixed `NetworkShow` behavior when it is called twice. (#3867)
30
47
31
-
### Security
32
-
33
-
34
48
### Obsolete
35
49
-`NotListeningException` is now marked as obsolete as it is no longer used internally. (#3867)
Copy file name to clipboardExpand all lines: com.unity.netcode.gameobjects/Documentation~/advanced-topics/message-system/rpc-compatibility.md
+5-5Lines changed: 5 additions & 5 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -36,11 +36,11 @@ However, the RPC signature hash doesn't change when the names of the parameters
36
36
37
37
When the RPC signature changes, it directs to a different invocation code path that has different serialization code. This means that the RPC method with the new signature doesn't invoke previous versions of that RPC method (for example, an RPC method from an older build).
| Cross-Build Compatibility |<iclass="fp-check"></i>| As long as the RPC method signature is kept the same, it will be compatible between different builds. |
42
-
| Cross-Version Compatibility |<iclass="fp-check"></i>| As long as the RPC method signature is kept the same, it will be compatible between different versions. |
43
-
| Cross-Project Compatibility |<iclass="fp-x"></i>| The exact same RPC method signature can be defined in different projects. This is because the project name or project-specific token isn't part of RPC signature. Cross-project RPC methods aren't compatible with each other. |
39
+
| Compatibility || Description |
40
+
| -- |--| -- |
41
+
| Cross-Build Compatibility |**Yes**| As long as the RPC method signature is kept the same, it will be compatible between different builds. |
42
+
| Cross-Version Compatibility |**Yes**| As long as the RPC method signature is kept the same, it will be compatible between different versions. |
43
+
| Cross-Project Compatibility |No| The exact same RPC method signature can be defined in different projects. This is because the project name or project-specific token isn't part of RPC signature. Cross-project RPC methods aren't compatible with each other. |
Copy file name to clipboardExpand all lines: com.unity.netcode.gameobjects/Documentation~/advanced-topics/networkobject-parenting.md
+19-8Lines changed: 19 additions & 8 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -1,15 +1,15 @@
1
1
# NetworkObject parenting
2
2
3
-
###Overview
3
+
## Overview
4
4
5
-
If you aren't completely familiar with transform parenting in Unity, then it's highly recommended to [review over the existing Unity documentation](https://docs.unity3d.com/Manual/class-Transform.html) before reading further to properly synchronize all connected clients with any change in a GameObject component's transform parented status, Netcode for GameObjects requires that the parent and child GameObject components have NetworkObject components attached to them.
5
+
If you aren't familiar with transform parenting in Unity, then it's recommended that you [review the existing Unity documentation](https://docs.unity3d.com/Manual/class-Transform.html) before reading further. To properly synchronize all connected clients with any change in a GameObject component's transform parented status, Netcode for GameObjects requires that the parent and child GameObject components have NetworkObject components attached to them. Otherwise, you can use the [AttachableBehaviour](../components/helper/attachablebehaviour.md) and [AttachableNode](../components/helper/attachablenode.md) helper components to synchronize other types of parenting.
6
6
7
-
###Parenting rules
7
+
## Parenting rules
8
8
9
9
- Setting the parent of a child's `Transform` directly (that is, `transform.parent = childTransform;`) always uses the default `WorldPositionStays` value of `true`.
10
10
- It's recommended to always use the `NetworkObject.TrySetParent` method when parenting if you plan on changing the `WorldPositionStays` default value.
11
11
- Likewise, it's also recommended to use the `NetworkObject.TryRemoveParent` method to remove a parent from a child.
12
-
- When a server parents a spawned NetworkObject component under another spawned NetworkObject component during a Netcode game session this parentchild relationship replicates across the network to all connected and future latejoining clients.
12
+
- When an [authority](../terms-concepts/authority.md) parents a spawned NetworkObject component under another spawned NetworkObject component during a Netcode game session, this parent-child relationship replicates across the network to all connected and future late-joining clients.
13
13
- If, while editing a scene, you place an in-scene placed NetworkObject component under a GameObject component that doesn't have a NetworkObject component attached to it, Netcode for GameObjects preserves that parenting relationship.
14
14
- During runtime, this parent-child hierarchy remains true unless the user code removes the GameObject parent from the child NetworkObject component.
15
15
-**Note**: Once removed, Netcode for GameObjects won't allow you to re-parent the NetworkObject component back under the same or another GameObject component that with no NetworkObject component attached to it.
@@ -35,15 +35,26 @@ If you aren't completely familiar with transform parenting in Unity, then it's h
> If you are dealing with more than one generation of nested children where each parent and child have scale values other than `Vector3.one`, then mixing the `WorldPositionStays` value when parenting and removing a parent will impact how the final scale is calculated! If you want to keep the same values before parenting when removing a parent from a child, then you need to use the same `WorldPositionStays` value used when the child was parented.
40
41
41
-
### Only a server (or a host) can parent NetworkObjects
42
+
### Who can parent NetworkObjects
43
+
44
+
#### Under a spawned NetworkObject
45
+
46
+
The [owner](../terms-concepts/ownership.md) of a NetworkObject can always parent that NetworkObject under any other spawned NetworkObject. This works regardless of who owns the other NetworkObject.
47
+
48
+
#### Under other GameObjects
49
+
50
+
By default, only the [authority](../terms-concepts/authority.md) of a NetworkObject can parent a NetworkObject under a non-networked object. This means in a client-server game, only the server (or host) can control NetworkObject component parenting. In a distributed authority game the [owner](../terms-concepts/ownership.md) of the object can always parent the object.
51
+
52
+
To allow the [owner](../terms-concepts/ownership.md) to parent their owned NetworkObject in a client-server game, use the [`NetworkObject.AllowOwnerToParent`](https://docs.unity3d.com/Packages/com.unity.netcode.gameobjects@latest?subfolder=/api/Unity.Netcode.NetworkObject.html#Unity_Netcode_NetworkObject_AllowOwnerToParent) property.
42
53
43
-
Similar to [Ownership](../basics/networkobject#ownership), only the server (or host) can control NetworkObject component parenting.
> If you run into a situation where your client must trigger parenting a NetworkObject component, one solution is for the client to send an RPC to the server. Upon receiving the RPC message, the server then handles parenting the NetworkObject component.
57
+
> If you run into a situation where your client must trigger parenting a NetworkObject component, one solution is for the client to send an RPC to the authority. Upon receiving the RPC message, the authority then handles parenting the NetworkObject component.
47
58
48
59
### Only parent under a NetworkObject Or nothing (root or null)
Copy file name to clipboardExpand all lines: com.unity.netcode.gameobjects/Documentation~/basics/object-spawning.md
+1-3Lines changed: 1 addition & 3 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -30,9 +30,7 @@ When using a [server authoritative networking model](../terms-concepts/authority
30
30
31
31
To spawn a network prefab, you must first create an instance of the network prefab and then invoke the spawn method on the NetworkObject component of the instance you created. In most cases, you will want to keep the NetworkObject component attached to the root GameObject of the network prefab.
32
32
33
-
By default, a newly spawned network prefab instance is owned by the authority unless otherwise specified.
34
-
35
-
See [Ownership](networkobject.md#ownership) for more information.
33
+
Refer to [NetworkObject ownership](../advanced-topics/networkobject-ownership.md) for more information.
36
34
37
35
The following is a basic example of how to spawn a network prefab instance:
Before reading these docs, ensure you understand the concepts of [ownership](../terms-concepts/ownership.md) and [NetworkObject ownership](./networkobject-ownership.md). It's also important to be familiar with the [NetworkBehaviour](./networkbehaviour.md)
4
+
5
+
The owner of each NetworkBehaviour in your game is decided by the owner of that NetworkBehaviour's NetworkObject. The NetworkObject is found as a property on the NetworkBehaviour: [`NetworkBehaviour.NetworkObject`](https://docs.unity3d.com/Packages/com.unity.netcode.gameobjects@latest?subfolder=/api/Unity.Netcode.NetworkBehaviour.html#Unity_Netcode_NetworkBehaviour_NetworkObject).
6
+
7
+
## Helpful properties
8
+
9
+
> [!NOTE]
10
+
> The following properties are only valid if the NetworkBehaviour has been spawned. Use [`NetworkBehaviour.IsSpawned`](https://docs.unity3d.com/Packages/com.unity.netcode.gameobjects@latest?subfolder=/api/Unity.Netcode.NetworkBehaviour.html#Unity_Netcode_NetworkBehaviour_IsSpawned) to check the spawned status of the NetworkBehaviour
11
+
12
+
To identify whether the local client is the owner of a NetworkBehaviour, you can check the[`NetworkBehaviour.IsOwner`](https://docs.unity3d.com/Packages/com.unity.netcode.gameobjects@latest?subfolder=/api/Unity.Netcode.NetworkBehaviour.html#Unity_Netcode_NetworkBehaviour_IsOwner) property.
13
+
14
+
To identify whether the server owns a NetworkBehaviour, you can check the [`NetworkBehaviour.IsOwnedByServer`](https://docs.unity3d.com/Packages/com.unity.netcode.gameobjects@latest?subfolder=/api/Unity.Netcode.NetworkBehaviour.html#Unity_Netcode_NetworkBehaviour_IsOwnedByServer) property.
15
+
16
+
To identify whether the local client has authority of a NetworkBehaviour, you can check the[`NetworkBehaviour.HasAuthority`](https://docs.unity3d.com/Packages/com.unity.netcode.gameobjects@latest?subfolder=/api/Unity.Netcode.NetworkBehaviour.html#Unity_Netcode_NetworkBehaviour_HasAuthority) property.
17
+
18
+
## Detecting ownership changes
19
+
20
+
There are three functions that can be implemented to detect ownership changes on a NetworkBehaviour. These functions are invoked in the order they are listed here.
When using a [client-server network topology](../../terms-concepts/client-server.md)`OnLostOwnership` is invoked on both the server any time a connected client loses ownership of this NetworkBehaviour. It is also invoked on the game client who just lost ownership.
25
+
26
+
In a [distributed authority network topology](../../terms-concepts/distributed-authority.md)`OnLostOwnership` is invoked on all connected game clients.
When using a client-server network topology `OnGainedOwnership` is invoked on the server any time ownership is gained. It is also be invoked on the game client who just gained ownership.
40
+
41
+
In a distributed authority network topology `OnGainedOwnership` is invoked on all connected game clients.
42
+
43
+
`OnGainedOwnership` is invoked after `OnLostOwnership`.
Whenever you want notification on any and all ownership changes, implement the `OnOwnershipChanged` method. `OnOwnershipChanged` is invoked on all connected game clients whenever the ownership of the NetworkBehaviour it is implemented on changes.
58
+
59
+
`OnOwnershipChanged` is invoked after `OnLostOwnership` and `OnGainedOwnership`.
Copy file name to clipboardExpand all lines: com.unity.netcode.gameobjects/Documentation~/components/core/networkbehaviour.md
+4-3Lines changed: 4 additions & 3 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -1,4 +1,4 @@
1
-
# NetworkBehaviour spawning and despawning
1
+
# NetworkBehaviour
2
2
3
3
[NetworkBehaviour](https://docs.unity3d.com/Packages/com.unity.netcode.gameobjects@latest?subfolder=/api/Unity.Netcode.NetworkBehaviour.html) is an abstract class that derives from [MonoBehaviour](https://docs.unity3d.com/ScriptReference/MonoBehaviour.html) and is primarily used to create unique netcode or game logic. To replicate any netcode-aware properties or send and receive RPCs, a [GameObject](https://docs.unity3d.com/Manual/GameObjects.html) must have a [NetworkObject](networkobject.md) component and at least one NetworkBehaviour component.
4
4
@@ -38,6 +38,7 @@ The diagram above represents how the spawn process works for two NetworkBehaviou
38
38
NetworkObjects go through three states during the spawn process:
39
39
40
40
**Spawn states**
41
+
41
42
- Prespawning: Before any netcode-related properties have been set.
42
43
- Spawning: Netcode-related properties have been set.
43
44
- Spawned: All NetworkBehaviour components have completed their spawn logic.
@@ -98,7 +99,7 @@ private void Update()
98
99
99
100
Alternatively, you can leverage the [NetworkUpdateLoop](../../advanced-topics/network-update-loop-system/index.md) system by making a NetworkBehaviour implement the `INetworkUpdateSystem` interface and register each instance for a specific `NetworkUpdateStage` during the `OnNetworkSpawn` or `OnNetworkPreSpawn` invocations, and then use your own script logic to determine which instance should be updating.
100
101
101
-
This can be useful when you want only the owner, authority, or non-authority to be updating and can help to remove checks like the above. It can also reduce the performance cost of all instances that do not register for the update stage (depending upon how many instances are spawned).
102
+
This can be useful when you want only the [owner](../../terms-concepts/ownership.md), [authority](../../terms-concepts/authority.md), or non-authority to be updating and can help to remove checks like the above. It can also reduce the performance cost of all instances that do not register for the update stage (depending upon how many instances are spawned).
102
103
103
104
### Dynamically spawned NetworkObjects
104
105
@@ -189,4 +190,4 @@ Similar to the [spawn process and invocation order section above](#spawn-process
0 commit comments