[UE5, Chaos Vehicles] ServerUpdateState permanently rejected ("No owning connection for actor") after manual delayed Possess()

Development Programming & Scripting Multiplayer & Networking
1

[UE5, Chaos Vehicles] ServerUpdateState permanently rejected (“No owning connection for actor”) after manual delayed Possess() — Owner/Controller/Role all correct

Engine version: UE5.8.1 (Chaos Vehicles plugin) Networking: Listen server + 2 remote clients (also reproduces with dedicated server)

Summary

Full disclosure, this report was written by an LLM. I’m a relatively new unreal programmer and I would have never been able to state all the things I tested so well on my own:

After a player-owned ChaosWheeledVehicleMovementComponent pawn is spawned and possessed slightly after BeginPlay (i.e. not via AutoPossessPlayer, but via an explicit Possess() call a moment later), the vehicle’s ServerUpdateState RPC is permanently rejected by the network driver for every remote client, even though Owner, Controller, and network Role are all independently verified correct at the moment of possession. The host’s own locally-controlled tank is unaffected.

Repro steps

  1. GameMode spawns a pawn (custom ACharacter/APawn subclass using UChaosWheeledVehicleMovementComponent) via SpawnActorFromClass, with Owner set to the target PlayerController at spawn time.
  2. A moment later (same function, after the spawn call returns), call Possess(PlayerController, Pawn) explicitly. (AutoPossessPlayer is Disabled — possession is always manual.)
  3. Repeat for each of N players in a ForEachLoop (each player possessing their own separate vehicle instance).
  4. Observe the output log for each remote client’s vehicle:
LogNet: Warning: UNetDriver::ProcessRemoteFunction: No owning connection for actor BP_TANK_V3_C_1. Function ServerUpdateState will not be processed.
LogNet: Warning: UNetDriver::ProcessRemoteFunction: No owning connection for actor BP_TANK_V3_C_2. Function ServerUpdateState will not be processed.

This warning fires every tick, indefinitely, for the entire session — it is not a transient startup race.

What’s been verified as correct (ruled out)

  • Owner — explicitly set at spawn time to the correct PlayerController, confirmed via printing PlayerState->GetPlayerName() for the exact controller reference used in the spawn/possess call; each of 3 players’ controllers resolves to their own correct name, no duplication or staleness.
  • Controller / possession — Possess() is called correctly and succeeds; GetControlledPawn() and PlayerState->GetPawn() both correctly report the new pawn post-possession.
  • Network Role — printed GetRemoteRole() on the pawn immediately after Possess(): shows ROLE_AutonomousProxy for both remote clients’ tanks and ROLE_SimulatedProxy for the host’s own tank — exactly the expected distribution for correct ownership.
  • MustSpectate — overrode AGameMode::MustSpectate to always return false (ruling out spectator-only gating); no change in behavior.
  • Match state — confirmed InProgress at time of spawn/possess.
  • Component-level flags — bReplicates, bAutoActivate, bAutoRegisterUpdatedComponent on the vehicle movement component are all correctly true. bRequiresControllerForInputs toggled to false post-possession — no effect. ResetVehicle() called post-possession — no effect.
  • Player controller identity — confirmed each PlayerController reference used is the genuine, single, connected instance for that player (via PlayerState-based name comparison), not a stale/duplicate object.
  • Timing/race — adding a short delay between each player’s spawn+possess in the loop did not resolve it (and in fact broke spawning entirely for other reasons related to Custom Event parameter scoping — separate issue, not relevant here). The warning is persistent, not a one-frame startup race that resolves itself.

What I suspect

UChaosVehicleMovementComponent (or its PawnOwner/locally-controlled state) appears to evaluate whether it has a valid controlling connection once, early — likely during BeginPlay/component initialization, which runs as part of the atomic SpawnActorFromClass call, before our explicit Possess() call a moment later ever executes. If this evaluation is cached rather than re-checked, the component would never register as eligible for server RPC processing for that instance again, regardless of Owner/Role being corrected immediately afterward — which would explain every data point above.

True deferred spawning (Begin Spawning Actor from Class / Finish Spawning Actor, which would let us call Possess() before BeginPlay runs) does not appear to be exposed as a Blueprint node in this engine version — only the atomic SpawnActorFromClass is available, and the RestartPlayerAtTransform/SpawnDefaultPawnAtTransform override path did not provide a usable workaround either (see below).

Secondary dead end (may still be useful context)

I also tried routing possession through AGameModeBase::RestartPlayerAtTransform (with a SpawnDefaultPawnAtTransform override providing the custom pawn), hoping its internal ClientRestart() call would fix client-side initialization. Verbose logging (LogGameMode VeryVerbose) confirms RestartPlayerAtTransform is entered correctly for all 3 players (LogGameMode: Verbose: RestartPlayerAtTransform <PlayerName>), and all of MustSpectate (forced false), the pawn-existence check, and match state are confirmed passing/correct — yet execution never reaches SpawnDefaultPawnAtTransform (its own print statement never fires) and no pawn is ever spawned (confirmed zero BP_TANK_V3 instances in the world via World Outliner). No engine warning/error is logged explaining the silent stop. I was unable to identify what’s gating this — happy to file this as a separate report if useful, but reverted to the manual-Possess approach above since it at least produces working (if RPC-broken) pawns.

Question

Is there a known way to either: (a) force the Chaos vehicle movement component to re-evaluate its controller/connection eligibility after a delayed Possess(), or (b) achieve true deferred actor construction in current Blueprint (spawn → assign controller → THEN run BeginPlay) without dropping to C++?

Any pointers — especially from anyone who’s hit this exact warning with Chaos Vehicles specifically — much appreciated. Happy to provide the full Blueprint graphs / additional logs on request.