AC: predictions before the active-contents workload
Written before the game was started. Records one correction to lane L3 up front: the turn-15 save already has a trade sector with tsnumflt=1 (the AI's), so 'any freighter anywhere' is already falsified as the gate for the trade callees.
This commit is contained in:
alex
parent
16b1e65fa3
commit
7e726b9074
1 changed files with 140 additions and 0 deletions
140
docs/AC-predictions.md
Normal file
140
docs/AC-predictions.md
Normal file
|
|
@ -0,0 +1,140 @@
|
||||||
|
# Lane AC — predictions, written before the workload was built
|
||||||
|
|
||||||
|
Rule 2. Committed before the game was started, before the first End Turn, and before any probe
|
||||||
|
counter was read. Guest VM141 (`sots-re-win10-b`, `192.168.10.143`), starting from lane L3's
|
||||||
|
`human-turn15-spyprogram.sav`.
|
||||||
|
|
||||||
|
The question: **does the strategic-turn tail draw RNG when the trade and spy containers hold
|
||||||
|
*active* contents rather than merely present ones?** Lane L3 retired lane W3's risk for populated
|
||||||
|
containers; the residual condition it named is freighters in service (`tsnumflt > 0`) and a
|
||||||
|
deployed spy (`spyon != 0`).
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## 0. One fact from the save that changes the prior before anything is run
|
||||||
|
|
||||||
|
Lane L3's §3.5 says *"every trade sector has `tsnumflt = 0` — no freighters in service"*. Read out
|
||||||
|
of the save L3 shipped, that is **not true**. `human-turn15-spyprogram.sav`, `trdmgr`, sector
|
||||||
|
`TradeID 816` (`tsgridID 5`):
|
||||||
|
|
||||||
|
```
|
||||||
|
tssec 2 tsct 2 tsnumflt 1 tsflt 2736
|
||||||
|
```
|
||||||
|
|
||||||
|
and the fleet with id `2736` is `Freighters`, `PID 32` — the **AI**'s. Its six member systems
|
||||||
|
(`tssys` 192, 288, 304, 336, 352, 464 → indices 9, 15, 16, 18, 19, 26) are all AI-owned. The
|
||||||
|
single serialized route record `trdmgr.rt` (`tro 32, trfow 1, trto 16, trtow 1, trfr 18, trtc 10`)
|
||||||
|
is likewise the AI's.
|
||||||
|
|
||||||
|
So across L3's seven instrumented turns the game **already had a trade sector with a freighter in
|
||||||
|
service and an active route**, and `TradeManager::Slot13RngCalleeA/B` were entered **0** times
|
||||||
|
anyway. The five sectors with `tsnumflt = 0` are the ones the human player owns or shares.
|
||||||
|
|
||||||
|
This does not make the experiment pointless — it sharpens it. It rules out "any freighter anywhere"
|
||||||
|
as the gate before I spend a turn, and it means the surviving trade-side hypotheses are narrower:
|
||||||
|
a per-player gate, a count threshold, a route-*state* condition (`TROUTESTATUS_*` is
|
||||||
|
Inactive/New/Developing/Established/Shutting Down), or the raid-candidate list being the thing that
|
||||||
|
is empty rather than the roll being un-taken.
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## 1. Predictions
|
||||||
|
|
||||||
|
### P1 — the trade half (primary)
|
||||||
|
|
||||||
|
**Freighters in service on the human player's own trade sectors will NOT make
|
||||||
|
`TradeManager::Slot13RngCalleeA` (0x00820ca0) or `Slot13RngCalleeB` (0x0088b440) fire.** Both stay
|
||||||
|
at `calls = 0` on every instrumented End Turn, while `ServerTradeManagerImpl::vslot13` (0x0088ef80)
|
||||||
|
and `vslot15` (0x0082cca0) stay at exactly 1.
|
||||||
|
|
||||||
|
Confidence: **moderate-to-high**, and it rests on §0 rather than on L3's stated reason. An AI
|
||||||
|
freighter has already failed to trip it for seven turns; the only way a human freighter trips it is
|
||||||
|
if the gate is per-player, which is possible (`vslot13` may loop players) but is not the simplest
|
||||||
|
reading of "entered once per turn".
|
||||||
|
|
||||||
|
*Falsification and its symptom.* If A or B reports `calls >= 1` on the first turn after
|
||||||
|
`tsnumflt` goes non-zero on a human sector, P1 is dead and the answer to the lane's question is
|
||||||
|
"yes, the tail draws under active contents". Symptom: a non-zero `calls` in the `probe_entries`
|
||||||
|
table on the post-turn `Autosave` record, with `installed = true` on that row.
|
||||||
|
|
||||||
|
### P2 — the trade half, second order
|
||||||
|
|
||||||
|
If P1 holds, then either (a) the gate is not "a freighter exists" at all, or (b) it is a threshold
|
||||||
|
above 1. **I predict (a).** Falsifier: if the callees fire only once the human side reaches
|
||||||
|
`TRADE_ROUTE_MAX_FREIGHTERS = 5` on a sector, (b) is right and P2 is wrong; symptom is a step
|
||||||
|
change in `calls` exactly at the turn `tsnumflt` reaches 5.
|
||||||
|
|
||||||
|
### P3 — the spy half
|
||||||
|
|
||||||
|
**A deployed spy (`spyon != 0`, `tdep >= 0`, `spyat` set) WILL make
|
||||||
|
`SpyManager::Slot13RngCallee` (0x008408e0) fire, at 1 entry per turn per deployed spy.**
|
||||||
|
|
||||||
|
Confidence: **low-to-moderate**, and deliberately opposite in sign to P1. The reason to split them
|
||||||
|
is that the spy path has a per-turn stochastic element the trade path does not obviously have —
|
||||||
|
`sdet` ("spy detection", −1 in the save) and `deat` are per-spy fields that a deployed spy must
|
||||||
|
have rolled for each turn, and a detection roll is exactly the shape of thing
|
||||||
|
`Slot13RngCallee` would be. `cbh`, `cm`, `cmo`, `ncp` are all still zero on the undeployed spy.
|
||||||
|
|
||||||
|
*Falsification.* If a spy reaches `spyon != 0` and `Slot13RngCallee` still reports `calls = 0` on
|
||||||
|
the following End Turn, P3 is dead and both containers are confirmed inert at every reachable
|
||||||
|
state — which closes lane W3's risk outright. Symptom: `calls = 0` with `installed = true` on that
|
||||||
|
row while the save shows `spyon != 0`.
|
||||||
|
|
||||||
|
### P4 — `spies2`
|
||||||
|
|
||||||
|
**`spies2` will become non-empty in exactly the system a spy is deployed at, and nowhere else.**
|
||||||
|
i.e. `spies2` *is* a per-system spy list and it fills only for a **deployed** spy. That is the
|
||||||
|
second of the two readings L3 left open, and it is the one I expect.
|
||||||
|
|
||||||
|
Confidence: moderate. `spies2` sits on `ServerSystem`, and a built-but-docked spy has no system to
|
||||||
|
belong to (`tdep = -1`, `spyat = 0`), so a container keyed by system cannot hold it.
|
||||||
|
|
||||||
|
*Falsification.* If a spy is deployed and `spies2` is still `0` in all 28 systems, then `spies2` is
|
||||||
|
**not** the spy list and the first reading is right; the rule-6 flags on `spies2`, `SysMem` and
|
||||||
|
`mts` stay up and the field needs a different explanation. Symptom: post-deploy save parses with
|
||||||
|
`spies2` count 0 everywhere while `spymgr.spy.spyon != 0`.
|
||||||
|
|
||||||
|
### P5 — reachability of the active spy state at all
|
||||||
|
|
||||||
|
**Deploying a spy in this save may be unreachable, and if so I will say so rather than infer.**
|
||||||
|
The engine's own refusals require a system that is *not mine*, has *no enemy fleet present*, has
|
||||||
|
*no spy already*, and **has an asteroid belt**. `ARes2` on `ServerSystem` is the asteroid-resource
|
||||||
|
field (its non-zero values 1703–2531 sit inside `SYSTEM_MIN/MAX_ASTEROID_RESOURCES` 1500–3000).
|
||||||
|
In the turn-15 save only five of 28 systems have `ARes2 > 0`:
|
||||||
|
|
||||||
|
| idx | id | name | `ARes2` | owner |
|
||||||
|
|---|---|---|---|---|
|
||||||
|
| 1 | 64 | Ka'Palum | 2061 | unowned |
|
||||||
|
| 4 | 112 | Regulus | 1703 | unowned |
|
||||||
|
| 10 | 208 | Kam'Tara | 1948 | unowned, **AI fleet present** (Omikron Fleet II, 4 ships) |
|
||||||
|
| 12 | 240 | Downbelow | 2172 | **mine** |
|
||||||
|
| 27 | 480 | Hitomi | 2531 | player 576, `AFlags 128`, position (0,0,0) |
|
||||||
|
|
||||||
|
**No AI-owned system has an asteroid belt.** So the textbook target — an enemy colony with a belt —
|
||||||
|
does not exist here. I predict the reachable routes are, in order: deploy at an **unowned** belt
|
||||||
|
system (Regulus is 9.01 ly from the tender's berth at Epsilon Eridani against a hull range of 9.0,
|
||||||
|
so this is marginal and node travel may or may not save it); or wait for the AI to colonize
|
||||||
|
Kam'Tara, where it already has a fleet, and deploy once its fleet leaves.
|
||||||
|
|
||||||
|
*Falsification.* If the Special menu offers `Deploy Spy` at an unowned belt system, P5's pessimism
|
||||||
|
is wrong and the path is short. Symptom: the menu entry is enabled and the action is accepted.
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## 2. What would make me wrong about the whole framing
|
||||||
|
|
||||||
|
- **The outer callees may not iterate the containers that were measured.** `vslot13`/`vslot15` are
|
||||||
|
entered once per turn regardless of container contents, which is equally consistent with their
|
||||||
|
loop being over *players* or over *encounters* and the trade/spy containers being read further in.
|
||||||
|
If so, "active contents" is the wrong axis entirely and no workload on these two vectors will ever
|
||||||
|
trip the inner callees. Symptom: a static read of the gate shows a predicate on neither container.
|
||||||
|
- **The instrument may not be armed.** `probes=11` is L3's config and is line-for-line comparable
|
||||||
|
with lane H, but lane H bisected `probes=11` as **not** determinism-neutral (the detour on probe
|
||||||
|
index 8, `GenerateTradeRaidEncounters`, suppresses a draw elsewhere). `probes=8` is the largest
|
||||||
|
proven byte-neutral configuration and it still installs indices 0–7, i.e. **all four outer callees
|
||||||
|
and all three inner ones**. I will take the primary reading at `probes=8` for that reason and
|
||||||
|
cross-check at `probes=11` for comparability, and I will report `installed=` for every row rather
|
||||||
|
than a bare zero (rule 20; and lane L3's own `hooks=off watch=on` defect is the worked example of
|
||||||
|
a config that reports a confident nothing).
|
||||||
|
- **A control that does not agree with itself is not a control** (rule 26). The `watch=on`/`watch=off`
|
||||||
|
pair goes on `ref-turn2.sav` in two fresh processes before any workload number is trusted.
|
||||||
Loading…
Add table
Reference in a new issue