Harden runtime proxy adoption

Ignore deleted actors during proxy candidate selection, delete stale saved runtime proxies before spawning fresh ones, and promote proxies based on loaded 3D instead of camera visibility. Updated docs and changelog accordingly.
This commit is contained in:
2026-06-29 15:37:05 +12:00
parent b505477e08
commit d0649667f7
4 changed files with 148 additions and 15 deletions
+87
View File
@@ -9,6 +9,93 @@ failed experiments, successful tests, and next steps.
---
## 2026-06-29 - Stale Runtime Proxy Adoption Fix
### Summary
Fixed a regression where, after deleting a stale saved proxy, the proxy slot adopted the marked-deleted actor instead of the freshly spawned one, leaving a single uncontrolled proxy when client 2 reconnected.
### Files Changed
- `plugin/src/F4TProxyActorController.cpp`
- `changelog.md`
- `docs/dev-log.md`
### Details
- `MarkAsDeleted()` only flags the stale actor; it is not removed from the cell the same frame, so it remained eligible during PlaceAtMe candidate isolation.
- Because stale actors were intentionally excluded from the pre-spawn snapshot, the marked-deleted stale proxy still counted as a "new" candidate and could be isolated as the nearest one. The slot then drove the invisible deleted actor while the real spawn stood idle.
- Added a deleted-actor guard to `IsSlotSpawnCandidateActor` so deleted actors are never snapshotted, deleted again, or isolated; isolation can now only pick the live freshly spawned proxy.
### Testing
- Not run in-game in this session.
- Expected result: when client 2 reconnects, the single remaining proxy is controlled by client 1's runtime proxy slot.
- Recommended manual check: reproduce the reconnect case and confirm the proxy follows client 2's transform/animation; check `CommonwealthOnline.log` for a Stage 4 promotion/restoration on the live spawned actor (not a deleted FormID).
### Known Issues
- In-game confirmation still needed.
### Next Steps
- Re-run the two-client reconnect reproduction after a save/load cycle.
---
## 2026-06-29 - Stale Runtime Proxy Cleanup
### Summary
Added cleanup for old saved runtime proxy actors so a fresh PlaceAtMe spawn does not leave an uncontrolled duplicate visible in the cell.
### Files Changed
- `plugin/src/F4TProxyActorController.cpp`
- `changelog.md`
- `docs/dev-log.md`
### Details
- During Stage 4 pre-spawn candidate scanning, runtime-created custom `COPlayerProxy` actors that are not owned by any current slot are marked deleted before a fresh proxy is spawned.
- Kept the existing proxy spawning and control flow unchanged; the cleanup does not adopt or start controlling stale actors.
- Expanded assigned-proxy detection to include pending spawn handles and cached slot FormIDs so active or settling proxies are not deleted accidentally.
### Testing
- Not run in-game in this session.
- Expected result: if a previous saved game contains an old uncontrolled `COPlayerProxy`, it is deleted before the new runtime proxy for client 2 is spawned.
- Recommended manual check: load a client/save that previously showed two client-2 proxies, connect client 2, and confirm only the newly spawned proxy remains visible and controlled.
### Known Issues
- In-game confirmation is still needed to verify `MarkAsDeleted()` removes the stale actor immediately enough for the current loaded cell.
### Next Steps
- Run the two-client duplicate-proxy reproduction after a save/load cycle.
- Check `CommonwealthOnline.log` for `deleting stale saved runtime proxy candidate` before the fresh Stage 4 spawn.
---
## 2026-06-29 - Runtime Proxy Spawn Visibility Gate
### Summary
Fixed runtime proxy spawn promotion so a remote player proxy can be assigned once its 3D is loaded, even when the actor is outside the local camera frustum.
### Files Changed
- `plugin/src/F4TProxyActorController.cpp`
- `changelog.md`
- `docs/dev-log.md`
### Details
- Replaced the Stage 4 promotion readiness check that depended on `Actor::IsVisible()` with a loaded-3D readiness check.
- Kept the existing active visibility refresh and frustum nudge path after promotion so off-camera proxies can still be refreshed without blocking assignment.
- Updated diagnostic wording from "visible 3D" to "loaded 3D" for the spawn settle wait.
### Testing
- Not run in-game in this session.
- Expected result: when client 2 connects behind or outside client 1's current view, client 1 should receive and assign client 2's proxy without needing to rotate 360 degrees or face away.
- Recommended manual check: start the server, connect two Fallout 4 instances in the same playable cell, keep client 1 facing away from client 2's position while client 2 connects, and confirm client 2's proxy appears or becomes active without a camera-turn workaround.
- Recommended log check: confirm `CommonwealthOnline.log` shows Stage 4 proxy promotion/restoration without repeated "waiting for loaded 3D" messages once the spawned actor has loaded 3D.
### Known Issues
- In-game confirmation is still needed to verify Fallout 4 reliably loads 3D for the PlaceAtMe proxy when spawned off-camera.
### Next Steps
- Run the two-client connection test in `F4TTestCell01` or the current multiplayer test cell.
- Verify outgoing transform packets, server relay, remote state parsing, runtime proxy restoration, and visible proxy movement still behave normally.
---
## 2026-06-29 - `COVault109` Solo Cell
### Summary