andrew
99595ef87c
Implement host-authoritative time/weather sync across server and clients. Adds a new worldState packet (and worldStateHost for host assignment) and server-side host tracking/reassignment to the lowest remaining playerId when the host disconnects. Plugin-side changes introduce F4T::WorldStateSync (new header + implementation), polling/apply hooks in the game-thread main loop, and Networking support to send/receive/parse worldState/worldStateHost packets. The server validates host-only sends, relays worldState to peers, broadcasts worldStateHost on host handoff, and augments logging/stats. Protocol and documentation files updated (protocol/world-state.md, docs/*) and server/fake_client.py extended to track/print host world-state snapshots.
1.3 KiB
1.3 KiB
World Sync
Fallout 4 assumes a single player owns the world state. Multiplayer requires deciding which client or server controls each piece of world state.
Implemented (MVP)
Host-authoritative time and weather sync is implemented via the worldState
packet. See world-state.md for the field spec.
- Host: tracked by
worldStateHostPlayerId(first connected client; reassigned to lowest remainingplayerIdon host disconnect) - Synced fields:
gameHour,gameDaysPassed, optionalweatherFormId - Weather apply: exterior cells only on non-host clients
- Server: pass-through relay with host-only send guard
World State Examples
World state can include:
- Doors
- Containers
- Pickups
- NPC deaths
- Physics objects
- Quest stages
- Workshop objects
- Terminal states
- Dialogue state
Early Approach
The first prototype should avoid world sync as much as possible.
Recommended early restrictions:
- Use a custom test cell
- Avoid lootable containers
- Avoid quests
- Avoid doors
- Avoid terminals
- Avoid persistent world changes
Later Ideas
Possible future approaches:
- Host-controlled world state
- Server-authoritative world state
- Cell-specific state tracking
- Limited interaction whitelist
- Resettable test environments