polserver / polserver / 35912421022

82%

Build Type

push

github

Committed by web-flow

Commit Message

Load boat components into the slots of their shape (#966)

* Load boat components into the slots of their shape

A boat moves its components by pairing its component list, index by
index, with the component lines of its boats.cfg shape. A save that
lists a component twice, or out of order, therefore sends every
component after it to another one's offset on every step and turn,
and leaves the last one behind.

Such saves exist: before components were refused as travellers, a
component moved as an ordinary item was saved under both Traveller and
Component, read into the list twice, and written back that way by every
later save. A live shard had a small boat saved with its tillerman
listed twice, which put the tillerman at the port plank's offset, the
planks one slot further on, and left the hold where it was.

readProperties now rebuilds the list against the shape: each slot takes
the first loaded component of its objtype in saved order, duplicates
collapse, a missing component leaves its slot empty instead of letting
the next one slide in, and a component with no slot is kept as before.

boat_load_test loads hand-written saves with a duplicate, a component
also listed as a traveller, a missing component and a well-formed list,
steps the boat and checks every component's offset. Without the fix 11
of its 13 checks fail.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01KT1aLLutCuJ4cUGsGmhLMs

* Keep a duplicated boat component in its last place

A component listed twice is always read with the extra copy first: it
comes from the travellers, which readProperties reads ahead of the
components. Keeping the first occurrence was harmless for the unique
components, but on a shape with several components of one objtype
(ropes, wheels, hull pieces) it put the duplicate into the first slot of
its objtype and moved the others down one, and the next save would have
written that order out for good. ... (continued)

Coverage Stats

28 of 29 new or added lines in 1 file covered. (96.55%)

6 existing lines in 4 files now uncovered.

60247 of 73545 relevant lines covered (81.92%)

1659412.36 hits per line