diff --git a/plan/battle-armor.md b/plan/battle-armor.md index 02a9b77..3f4bcf4 100644 --- a/plan/battle-armor.md +++ b/plan/battle-armor.md @@ -1640,6 +1640,34 @@ estimate is overpriced. - Whether a vehicle sheds a swarmer at all, and by what route. The probe's flat 5 is not trustworthy for a chassis that cannot go prone. +## Why no battle armor scenario would play, and it was never battle armor + +A scenario with a squad in it stalled in deployment and never reached a +decision. It reproduced with Princess on both sides and our bot not in the +match at all, which cleared the bot, the candidates and every branch; it was +`EquipmentType.initializeTypes()`, never called in a seat's JVM. + +`BattleArmor`'s static initialiser asks for an armour type name, which reaches +`ArmorType.initializeTypes()` past the guard that creates +`EquipmentType.lookupHash`, so the class fails to initialise. A client loads +`BattleArmor` when `ObjectInputStream` reads the entity list, so the error kills +`AbstractClient$ConnectionHandler` - and a seat with no connection handler is +connected, running and deaf. It never sees a turn, so it never deploys. +`docs/UPSTREAM.md` entry 14 has the stack and what a MegaMek-side fix would be. + +Two things made it read as a battle armor problem when it is a seat problem. +Only battle armor reaches the wire through `ArmorType`, so nothing else showed +it. And the seat is a process, so the host's stall dump - its own threads, +waiting - could not see the exception that was in the same log file. + +Both are addressed rather than just the first: the seat exits when its +connection thread dies, and the host names each seat and says whether it is +still alive when it dumps a stall. + +`scenarios/ba/ba-squad-duel.mms` and `scenarios/ba/ba-mixed-arms.mms` now reach +victory in 8 and 11 rounds. On `ba-squad-duel` the squad seat answered its +deployment and every firing decision and took no default. + ## Open questions for jmm - Is the single-Basic-Manipulator acceptance a MegaMek bug we should expect to