Harden base progression and cleanup; validate finite physical resupply

This commit is contained in:
2026-09-19 10:39:39 +02:00
parent 40a474934c
commit 7c53b4bb81
377 changed files with 51882 additions and 92 deletions
+6 -2
View File
@@ -10,7 +10,7 @@ Only actual child transport benches of the registered Mi8 are selectable. The se
## Ownership and commit boundary
A stock `MoveInVehicle` request may retry for missing replicated vehicle entities. This service does not invoke that method or queue callbacks. It uses a successor-specific controller handshake:
A stock `MoveInVehicle` request may retry for missing replicated vehicle entities. This service does not invoke that method or queue movement retries. It uses a successor-specific controller handshake:
1. Action completion passes live server checks and reserves a bench. The target's controller receives a prepare request identifying the actual mode instance and ticket. Preparation cannot move anyone.
2. The target owner validates its current body/phase, starts a three-second local `System.GetTickCount` lease, and sends ready. The server accepts ready only from the ticket's exact controller/body and revalidates identity, current physical state, settled duration, reservation and a five-second preparation deadline.
@@ -19,7 +19,7 @@ A stock `MoveInVehicle` request may retry for missing replicated vehicle entitie
An already committed native movement is not rolled back if conditions subsequently change. A false resolution means loading was not confirmed by this service, not that a committed native command was magically revoked. Terminal/identity changes are also rechecked on the owner; replication ordering under real latency remains a required multiplayer test. The service removes only a reservation still owned by the same surviving target reference, never another player's reservation. Native reservation cleanup after entity deletion also requires explicit runtime verification.
The mode adapter owns Tick/Stop/roster subscriptions and replicates only the current extraction-aircraft reference for client action presentation. Roster events run cleanup even when the ordinary mission tick returns early on an empty server. PREPARING roster callbacks are no-ops and cannot permanently stop the service. Terminal/explicit Stop latches before notifying subscribers, releases owned tickets and removes subscriptions. No new persistent settings, public entity-selection RPC, automatic spawning or original Escapists resource is introduced.
The mode adapter owns Tick/Stop/roster subscriptions and replicates only the current extraction-aircraft reference for client action presentation. Roster events run immediate cleanup. While tickets remain pending, one service-owned 250 ms callback observes only those tickets, so the full eight-second committed reservation expires even after the last player disconnects and the ordinary mission tick returns early. This callback never issues another owner command, refreshes a lease or samples settlement. It is removed when the last ticket resolves and on Stop. PREPARING roster callbacks are no-ops and cannot permanently stop the service. Terminal/explicit Stop latches before notifying subscribers, releases owned tickets and removes subscriptions. No new persistent settings, public entity-selection RPC, automatic spawning or original Escapists resource is introduced.
## Integration and checks
@@ -46,3 +46,7 @@ The real local controller takes the server/local fast path; this does not exerci
The separate [stock removal fixture](native-casualty-remove.md) passes in [080058](evidence/native-2026-09-19-080058/report.json): the helicopter's inherited door action removes a test-owned casualty from a real bench, leaving it living and incapacitated beside the authored exit with the seat vacant and accessible. This supplements loading with a local native removal path. It is not the production service's real-player/remote handshake, held action input, or a new extraction-result calculation.
The source-local regression in `test_casualty_reservation_death.py` also executes the actual pending-observation and callback ownership methods without ordinary round ticks: it retains a committed seat just before eight seconds, resolves it once at expiry, cancels the callback, and checks duplicate scheduling, uncommitted expiry, Stop and reentrant request scheduling. This is deterministic scheduling evidence, not a native network timing claim.
[Native regression 102037](evidence/native-2026-09-19-102037/report.json) passes 101 assertions with zero captured errors after the pending-maintenance fix: real owner handshake, physical incapacitated-player loading exactly once, reservation release and idempotent Stop remain correct. The established fixture still uses an explicit helper-only membership adapter; it is not a real empty-server/disconnect or multiplayer session.