Follow-up to #2573. That change made SmallBOD.EndCombine require a
player-crafted item, but it could only read provenance off BaseArmor,
BaseWeapon and BaseClothing, because those are the only three classes that
track it. Anything else a deed could request has no provenance at all, and
`armor?.PlayerConstructed ?? clothing?.PlayerConstructed ?? weapon?...`
had to enumerate the three by hand.
The gap is structural rather than cosmetic: PlayerConstructed is set inside
each base's OnCraft, so it can only ever reach types implementing ICraftable.
Most craftables do not -- the tinkering catalogue alone is largely plain Item
subclasses -- so a shard that adds any BOD, quest or vendor rule keyed on
"was this actually crafted" has nothing to key on for those types.
Provenance therefore moves to Item and is stamped centrally in CraftItem,
immediately after the item is constructed and before the ICraftable dispatch,
covering both the AOS and T2A craft paths. The three OnCraft overrides drop
their now-redundant assignment and inherit Item's property, so no call site
outside them changes -- Resmelt and SalvageBag still read
`armor.PlayerConstructed` and still compile unchanged. SmallBOD's three-way
null-coalescing chain collapses to `item.PlayerConstructed`.
Storage costs nothing. Item's SaveFlag word is written as a fixed-width int,
not an encoded one, so occupying bit 0x08000000 changes no record lengths.
Items that are not player-constructed serialize byte for byte as before, and
crafted ones differ by a single bit in a field already being written. Item
itself needs no version bump: a bare SaveFlag bit is self-describing, so
records written before it existed lack it and read false.
The three content classes do need one, since removing a serialized field
changes their layout:
BaseArmor 9 -> 10 field 24 removed (it was last, nothing renumbered)
BaseClothing 7 -> 8 field 7 removed, fields 8-10 shift down
BaseWeapon 10 -> 11 field 26 removed, fields 27-30 shift down
Each gets a MigrateFrom for its previous version that assigns the old bool
to the inherited property, so existing crafted armour, weapons and clothing
keep their provenance across the upgrade. Item.Deserialize runs first and
reads the (absent) bit as false, then the migration overwrites it -- the
generated Deserialize calls base.Deserialize before dispatching, so the
ordering holds. BaseWeapon had no migrations file and gains one.
Note the generator requires contiguous field ordering (SG3005), which is why
the removals renumber rather than leave a hole.
Verified: full solution builds with 0 errors and 0 warnings, 1516 tests pass.
3b440d7ba2