From 0c44aacb5bf4c6ba0c477c4970c70fd756bacb0d Mon Sep 17 00:00:00 2001 From: Meta Vens Date: Mon, 14 Sep 2026 23:09:56 +0200 Subject: [PATCH] Describe loadouts as authored ship presets in the target and README The target's Loadouts section now describes catalog presets. They are authored in Studio or captured by the editor command, and spawners materialize them under availability, all-or-nothing, with no charge. It keeps the weapon-group rules and records hardpoint-configuration variants as future direction. The README no longer lists loadouts as player state. Co-Authored-By: Claude Opus 5 --- README.md | 2 +- docs/cultcache-migration-target.md | 43 ++++++++++++++++++------------ 2 files changed, 27 insertions(+), 18 deletions(-) diff --git a/README.md b/README.md index bc131d61e..5136180f9 100644 --- a/README.md +++ b/README.md @@ -69,7 +69,7 @@ There are two solutions in this repository. One is a Unity project containing th Client-Server communication is implemented using [LiteNetLib](https://github.com/RevenantX/LiteNetLib), a semi-reliable UDP transport library which we use to transmit [MessagePack](https://github.com/neuecc/MessagePack-CSharp) over the wire. -Game content lives in `GameData/Aetheria.cc`, a [CultCache](https://github.com/GameCult/CultLib) store that is read-only at runtime. Run state and player state (settings, bindings, loadouts) live in their own `.cc` stores in the same cache. Persistent data types carry MessagePack attributes; some also carry [JSON.Net](https://www.newtonsoft.com/json) attributes. +Game content lives in `GameData/Aetheria.cc`, a [CultCache](https://github.com/GameCult/CultLib) store that is read-only at runtime. Run state and player state (settings and bindings) live in their own `.cc` stores in the same cache. Persistent data types carry MessagePack attributes; some also carry [JSON.Net](https://www.newtonsoft.com/json) attributes. ### Programming Paradigms diff --git a/docs/cultcache-migration-target.md b/docs/cultcache-migration-target.md index f6dc4c671..3fecf4d0f 100644 --- a/docs/cultcache-migration-target.md +++ b/docs/cultcache-migration-target.md @@ -77,24 +77,33 @@ the cache and nothing else. ## Loadouts -A loadout is a portable ship build. It stores item designs only: the hull design, -and for each hull cell a rotation and an `EquippableItemData` design. It names no -manufacturer and no product, and it lives in the player store, so it outlives -runs and works in any galaxy. +A loadout is an authored ship preset, a variant in the MechWarrior sense. Players +do not see loadouts in the MVP. Spawners use them to build ships. -`Loadouts.Materialize` is the single owner of turning a loadout into a ship: -validity, availability, affordability and the charge. - -- Each design is built by the first available product for that design, in - record-key order, under `LoadoutGenerator.IsAvailable`. -- The price is the sum of the design prices. -- It is all-or-nothing. On any failure it lists every failure, returns no ship - and charges nothing. It charges only on success. -- Weapon groups are indices into the slots. Every index must name a slot whose - design is a weapon. -- A loadout may have at most `WeaponGroupCount` groups; more is a failure. The - ship always gets exactly `WeaponGroupCount` groups, and missing groups are - added empty. +- **Content.** A loadout stores item designs only: the hull design, and for each + hull cell a rotation and an `EquippableItemData` design. It names no + manufacturer and no product, so it works in any galaxy. +- **Home.** Loadouts live in the catalog. They are authored in CultCache Studio, + or captured in play with the editor-only console command + `capturepreset "" [replace]`, and they are only read at runtime. +- **Capture.** The editor opens the catalog writable, in the same single cache. + `Loadouts.Commit` keys a preset by its name. It replaces an existing preset + only when `replace` is given. The commit is conditional on that key, so it + writes only this one record onto the file as it is on disk. +- **Materialize.** `Loadouts.Materialize` is the only way to build a ship from a + loadout, and it charges nothing. + - Each design is built by the first available product for that design, in + record-key order, under the availability predicate. The game passes + `LoadoutGenerator.IsAvailable`. + - It is all-or-nothing. On any failure it lists every failure and returns no + ship, so a spawner can pick another preset. +- **Weapon groups.** Weapon groups are indices into the slots, and every index + must name a slot whose design is a weapon. A loadout may have at most + `WeaponGroupCount` groups; more is a failure. The ship always gets exactly + `WeaponGroupCount` groups, and missing groups are added empty. +- **Future direction.** Variants will also differ by hardpoint configuration: + one hull with alternative hardpoint layouts. This is not built yet. Nothing + consumes presets yet either; ship spawning still uses `LoadoutGenerator`. ## Target state: CultLib