Per the documented turn order (game/rules.txt "Последовательность
действий"), no ship should dodge the pre-departure battle by slipping
into hyperspace. MakeTurn now runs merge -> battle -> load+launch routed
groups -> fly -> merge -> battle, so:
- ships ordered to depart (Launched) and ships being upgraded now take
part in the pre-departure battle at their planet (CollectPlanetGroups /
FilterBattleGroups); only survivors then enter hyperspace;
- routed transports are loaded and launched AFTER that battle, so they
fight empty and cannot escape it.
A just-launched group has no stored hyperspace position, so moveShipGroup
starts its first leg from the origin planet; the previous code read the
nil launch coordinate and would panic.
Because upgrading groups can now lose ships in the battle, the pending
upgrade cost is recomputed from the group's current ship count instead of
the value stored when the order was validated.
Rules: reordered "Последовательность действий" and rewrote the combat
note that ordered/routed ships skip the battle.
Tests: launched-group move from origin, launched/upgrade groups taking
part in battle, upgrade cost tracking ship losses.
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
The battle engine diverged from the documented combat model
(game/rules.txt "Сражения") in three ways:
- the destruction roll was inverted (rand >= p), so a near-certain hit
destroyed its target only ~(1-p) of the time;
- a whole group fired as a single ship (Armament shots per round)
regardless of its ship count, so fleet size never affected offence;
- the defending mass used the whole group's full mass instead of one
target ship's, weakening grouped ships' shields by ~Number^(1/3).
SingleBattle now resolves ship by ship: every living ship fires once per
round in random order across all groups, each gun targets a random enemy
ship (weighted by group size), and the destruction roll matches the
documented probability. FilterBattleOpponents evaluates per-ship mass.
Also fixes opponent-map initialisation in ProduceBattles that kept only
an attacker's last opponent.
The rules already describe this model, so no documentation change is
needed. Tests: per-ship one-sided wipe, destruction-roll direction, and
the updated per-ship-mass probability expectation.
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Legacy reports list the same `(race, className)` pair across several
roster rows; the engine likewise creates one ShipGroup per arrival.
Both the legacy parser and `TransformBattle` were keyed on shipClass
without summing — only the last row / group's counts survived, so a
protocol's destroy count appeared to exceed the recorded initial
roster. The UI worked around this with phantom-frame logic.
Both parser and engine now SUM `Number`/`NumberLeft` across rows /
groups sharing the same class; the phantom-frame workaround is gone.
KNNTS041 turn 41 planet #7 reconciles: `Nails:pup` 1168 initial −
86 survivors = 1082 destroys.
The engine's previously latent nil-map write on `bg.Tech` (would
have paniced on any group with non-empty Tech) is fixed in the same
patch — it blocked the aggregation regression test.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Ilia Denisov