Skip to content

fix: instantiate, spawn, and parent when spawning #3401

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged

Conversation

NoelStephensUnity
Copy link
Collaborator

@NoelStephensUnity NoelStephensUnity commented Apr 14, 2025

This PR resolves the issue where instantiating and spawning a NetworkObject (A) during another NetworkObject's spawn process (B) and then parenting the newly spawned NetworkObject (A) under the NetworkObject (B) would end up causing the parenting message to not properly defer the parenting message until the parent (B) was fully spawned on other already connected and synchronized clients (it would properly parent if another client late joined shortly after).

MTTB-1209

fix: #3100

Changelog

  • Fixed: Issue where during a NetworkObject spawn if you instantiated, spawned, and parented another network prefab under the currently spawning NetworkObject the parenting message would not properly defer until the parent NetworkObject was spawned.

Testing and Documentation

  • Includes new integration ParentingDuringSpawnTests test.
  • No documentation changes or additions were necessary.

Backport

This requires a backport to v1.x as the ParentSyncMessage does not defer the message if the parent NetworkObject is not spawned yet.

This resolves the issue where instantiating, spawning, and parenting a child NetworkObject during a to-be parent's OnNetworkSpawn or OnNetworkPostSpawn would not defer the parenting message properly if the parent had yet to be spawned.
test that validates this fix.
Adding change log entry.
clearing network manager list before starting test.
@NoelStephensUnity NoelStephensUnity marked this pull request as ready for review April 14, 2025 15:21
@NoelStephensUnity NoelStephensUnity requested a review from a team as a code owner April 14, 2025 15:21
@NoelStephensUnity NoelStephensUnity enabled auto-merge (squash) April 14, 2025 15:31
NoelStephensUnity added a commit that referenced this pull request Apr 14, 2025
This PR resolves the issue where instantiating and spawning a
`NetworkObject` (A) during another `NetworkObject`'s spawn process (B)
and then parenting the newly spawned `NetworkObject` (A) under the
`NetworkObject` (B) would end up causing the parenting message to not
properly defer the parenting message until the parent (B) was fully
spawned on other already connected and synchronized clients (it would
properly parent if another client late joined shortly after).

[MTTB-1209](https://jira.unity3d.com/browse/MTTB-1209)

## Changelog

- Fixed: Issue where during a `NetworkObject` spawn if you instantiated,
spawned, and parented another network prefab under the currently
spawning `NetworkObject` the parenting message would not properly defer
until the parent `NetworkObject` was spawned.

## Testing and Documentation

- Includes new integration ParentingDuringSpawnTests test.
- No documentation changes or additions were necessary.

<!-- Uncomment and mark items off with a * if this PR deprecates any
API:
### Deprecated API
- [ ] An `[Obsolete]` attribute was added along with a `(RemovedAfter
yyyy-mm-dd)` entry.
- [ ] An [api updater] was added.
- [ ] Deprecation of the API is explained in the CHANGELOG.
- [ ] The users can understand why this API was removed and what they
should use instead.
-->

## Backport

#3401
@NoelStephensUnity NoelStephensUnity merged commit f2e776e into develop-2.0.0 Apr 14, 2025
28 checks passed
@NoelStephensUnity NoelStephensUnity deleted the fix/instantiate-spawn-and-parent-when-spawning branch April 14, 2025 17:42
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
port:1.x-needed This issue needs to be ported to 1.X branch
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants