@elite-dangerous-almanac/core 0.2.6 → 0.2.8

package/PROVENANCE/ships/SOURCES.md

@@ -16,6 +16,8 @@ Referred to throughout by source name; the pin is here, once.
 | EDCD/Coriolis — the application, for its formulas                                               | commit `68c042ca6e3db62372cbbb2077cf972345511712`                                                                                                                           | 2026-08-01 UTC |
 | msarilar/EDEngineer `EDEngineer/Resources/Data/blueprints.json`                                 | SHA-256 `787e6bd0579264d7b4615a281318792cb212285786f4ae07f61ec1cc464cdec0` — read from the branch tip, so pinned by digest                                                  | 2026-08-08 UTC |
 | Elite Dangerous in-game verification                                                            | game version `4.4.0.3`; direct in-game observation                                                                                                                          | 2026-08-14 UTC |
+| Elite Dangerous in-game purchase capture                                                        | no game version recorded; nine `ModuleBuyAndStore` journal entries from market `128666762`, 17:34-17:37, at a 10% and a 2.5% outfitting discount                            | 2026-08-30 UTC |
+| Elite Dangerous in-game outfitting observation                                                  | no game version recorded; direct in-game observation that outfitting offers no non-SCO size-8 frame shift drive                                                             | 2026-08-30 UTC |
 
 Every `eddb.js` derivation uses the baseline snapshot unless its catalogue note names
 the Vessel Hangar snapshot.
@@ -351,7 +353,7 @@ FDevIDs, stats from coriolis-data and EDSY, joined on `symbol`.
   `id,symbol,category,name,mount,guidance,ship,class,rating,entitlement`, supplemented
   for the six bundle-granted Vessel Hangars by the pinned CAPI response below.
 - **Identity derivation:** the acquired FDevIDs module records are kept in CSV order
-  within each category file. The catalogue contains 484 internal records and **1199**
+  within each category file. The catalogue contains 484 internal records and **1194**
   records across all four categories. The CSV's numeric `id`
   column is dropped — modules are keyed by `symbol` — and rows marked `removed` are
   excluded because they are not current outfitting modules. `class` is FDevIDs' `class` — the
@@ -384,7 +386,7 @@ FDevIDs, stats from coriolis-data and EDSY, joined on `symbol`.
     II's `Int_MkIIAgileBoost_Engine_*` thrusters.
   - **A fuel tank is the one module built for two kinds of mount:** it is `fuelTank`
     and also fits any optional slot large enough, exactly as the game sells it.
-- **`kind` is the ordinary engineering-menu family.** The 1005 records mapped by
+- **`kind` is the ordinary engineering-menu family.** The 1000 records mapped by
   `engineering-options.jsonc` repeat that map's group key in the compact on-disk `kind`
   field. The remaining 194 records carry no `kind` because they have no ordinary
   engineering menu; this includes the five Enzyme/AX weapons, the fixed Mining Laser and
@@ -393,7 +395,7 @@ FDevIDs, stats from coriolis-data and EDSY, joined on `symbol`.
   Guardian families and coverage are documented under Engineering options below; this
   field is a projection of that map, not a separate classification source.
 - **`familyId` groups every outfitting list.** Every record in all four catalogues
-  carries the id of the family its outfitting list shows it under: 521 core modules in
+  carries the id of the family its outfitting list shows it under: 516 core modules in
   8 families, 484 internal modules in 32, 159 hardpoints in 25, and 35 utility fittings
   in 12. No family crosses an outfitting category. The ids and their canonical English
   names are `module-families.jsonc`, below; localized labels are
@@ -405,7 +407,7 @@ FDevIDs, stats from coriolis-data and EDSY, joined on `symbol`.
   family where their function differs. A core record's family follows from its `slot`,
   which is on every one of them, so the two never disagree.
 - **`supercruiseOvercharge` — the SCO drive line.** The 36
-  `Int_Hyperdrive_Overcharge_*` records carry `true`; the 36 plain drives of the same
+  `Int_Hyperdrive_Overcharge_*` records carry `true`; the 31 plain drives of the same
   sizes and ratings, and every other record in all four catalogues, omit it.
   - **Source:** FDevIDs `outfitting.csv`, which sells the two drive lines under distinct
     symbol families and names the Overcharge one `Frame Shift Drive (SCO)`. No registry
@@ -415,13 +417,44 @@ FDevIDs, stats from coriolis-data and EDSY, joined on `symbol`.
     above, and it is applied once here so that consumers read a datum instead of
     matching `Int_Hyperdrive_Overcharge` themselves — which a pre-engineered or fitted
     article's symbol does not always let them do. Stored as a sparse flag rather than a
-    `true`/`false` pair on all 72 drives, following `alwaysPowered` and
+    `true`/`false` pair on all 67 drives, following `alwaysPowered` and
     `guardianZoneResistance`.
   - **Nothing else is derived from it.** The two lines share every jump constant this
     catalogue carries (`optMass`, `maxFuel`, `fuelMul`, `fuelPower`, and the
-    size-determined `fsdHeatRate` above), so no calculation reads the flag; the
+    `fsdHeatRate`, which is a function of a drive's size alone — 10, 14, 18, 27, 37, 43
+    and 50 for sizes 2 to 8, identical on the plain and SCO lines at every size), so no
+    calculation reads the flag; the
     overcharged supercruise behaviour the drives are named for has no published figures
     and none are stored.
+- **`cabinCapacity` — a passenger cabin's berths.** The 23 `passengerCabins` records
+  carry it; every other record in all four catalogues omits it, and no cabin carries a
+  zero. It is the module's own seat count, not the ship's.
+  - **Source:** coriolis-data
+    `modules/internal/{economy,business,first,luxury}_passenger_cabin.json` (`passengers`)
+    and EDSY `eddb.js` (`cabincap`, whose `fdattr` is the journal's `CabinCapacity`), from
+    the snapshots pinned above. The two agree on every one of the 14 Mk I cabins, so
+    neither is preferred; the nine Mk II cabins rest on EDSY alone, which is where their
+    masses come from as well. FDevIDs publishes no capacity column.
+  - **Values:** Mk I economy 2/4/8/16/32 by size 2–6, business 3/6/10/16 by size 3–6,
+    first 3/6/12 by size 4–6 and luxury 4/8 by size 5–6. Mk II economy 3/6/12/24/48 by
+    size 2–6 and Mk II business 4/9/15/24 by size 3–6 — half again the Mk I cabin of the
+    same class and size, bar the size-3 business cabin, whose 3 berths become 4 rather
+    than 4.5.
+  - **Stored per record rather than derived from size and rating.** A Mk II cabin runs one
+    rating better than the Mk I cabin of the same class — Mk II economy is `D` where Mk I
+    economy is `E`, and Mk II business `C` where Mk I business is `D` — so one
+    size-and-rating rule cannot produce both lines.
+  - **The four passenger classes are not carried as a field, and are not lost.** EDSY
+    publishes one (`cabincls`, values `E`/`B`/`F`/`L`), which this catalogue does not
+    copy: the symbol already states the class, uniformly across both lines. The symbol's
+    `_ClassN` suffix — not the `class` field, which is the slot size — is 1/2/3/4 for
+    economy/business/first/luxury on all 23 records, which is what the English `name` and
+    EDSY's `cabincls` both agree with; the `rating` field is what does not state it, for
+    the reason above. The Mk I line runs all four, the Mk II line economy and business
+    only.
+  - **EDSY's five `Int_PassengerCabin_Size{2..6}_Class0` "Prisoner Cells" rows are not
+    carried**, capacity or otherwise: EDSY has them commented out with a null `fdid`, and
+    the inclusion rule below excludes an identity no registry offers to players.
 - **`grantOnly` — the articles that arrive granted rather than sold.** Fifteen records
   carry `true`: the nine `*_free` starter fittings (power plant, thrusters, drive, life
   support, distributor, sensors, fuel tank, shield generator, cargo rack) and the six
@@ -439,12 +472,11 @@ FDevIDs, stats from coriolis-data and EDSY, joined on `symbol`.
     twin bar the price (§Prices), so a screen offering both would show one article twice,
     once unpriced.
   - **It is not a statement about price, and the flag is not extended on a missing one.**
-    Eleven further records carry no `cost` — the five size-8 drives, the three Mk II
-    Vessel Hangars, the two unsold Corrosion Resistant Cargo Racks and the 1B shield
-    generator — and none is flagged. The two racks are the closest case and still fail
-    the rule: no source states them as a hull or bundle grant, and each is its own
-    identity at a capacity no other rack carries, not a second identity for something a
-    station already sells.
+    Three further records carry no `cost` — the two unsold Corrosion Resistant Cargo
+    Racks and the 1B shield generator — and none is flagged. The two racks are the
+    closest case and still fail the rule: no source states them as a hull or bundle
+    grant, and each is its own identity at a capacity no other rack carries, not a second
+    identity for something a station already sells.
 
 ### `module-families.jsonc` — the family ids and their English names
 
@@ -457,8 +489,7 @@ FDevIDs, stats from coriolis-data and EDSY, joined on `symbol`.
   `Manifest Scanners`, `Torpedo Pylons` is `Torpedoes` and `Mine Launchers` is `Mines`.
   The remaining 19 keep the Almanac's own descriptive name, because the outfitting
   screen does not name them separately. Each id is the camelCase form of its English
-  name with punctuation removed, which `modules.test.ts` asserts, so an id and its
-  label cannot drift apart.
+  name with punctuation removed.
 - **Merged families.** Where the game lists several Almanac families under one category,
   they are one family here: the operations, rescue, universal and xeno multi-limpet
   controllers are `multiLimpetControllers`; mining volley repeaters and seismic charge
@@ -598,14 +629,11 @@ Thirteen stored fields supply the base values referenced by engineering recipes:
 - **`EnergyPerRegen` needs no stored value.** All 57 shield generators carry
   `distributorDraw`, and EDSY (`genpwr`) and coriolis (`distdraw`) both confirm it is the
   same stat under the journal's other name.
-- **Nine figures no third-party registry lists, derived from the family rule.** Eight
-  records: the three `*_free` starter fittings (thrusters, drive, sensors — the sensors
-  contribute both a `scannerRange` and a `scanAngle`) and the five plain size-8 drives.
+- **Four figures no third-party registry lists, derived from the family rule.** Three
+  records: the `*_free` starter fittings (thrusters, drive, sensors — the sensors
+  contribute both a `scannerRange` and a `scanAngle`).
   Each `*_free` record is byte-identical to its priced twin apart from the missing
-  `cost`, so it takes that twin's value. A drive's heat rate is a function of its **size
-  alone** across all 66 records EDSY does carry — 10, 14, 18, 27, 37, 43 for sizes 2 to
-  7, identical between the plain and SCO lines at every size — and the size-8 SCO drives
-  are 50, so the size-8 plain drives take 50. Stated as derivation, not as a reading.
+  `cost`, so it takes that twin's value. Stated as derivation, not as a reading.
   The Mk II supercharge-optimised size-8 SCO drive is **not** among them: EDSY publishes
   its `fsdheat: 50` outright, spelling the symbol
   `Int_Hyperdrive_Overcharge_Size8_Class5_Overchargebooster_MkII` where the outfitting
@@ -656,8 +684,8 @@ Two starter capacities are derived rather than read:
 2^size across all eight sizes of both families, with no exception.
 
 **In-game coverage, stated separately from registry coverage.** In-game verification
-covers **1193/1199** catalogue identities. Numeric verification covers **952/1199**
-non-armour modules, and the other **241/1199** verified identities are the ship-specific
+covers **1188/1194** catalogue identities. Numeric verification covers **947/1194**
+non-armour modules, and the other **241/1194** verified identities are the ship-specific
 armour modules; their class, mass, hull boost and resistances retain their registry
 provenance rather than being described as game-verified. The six bundle-granted Vessel
 Hangars rely on the public registry and CAPI evidence below. Their stats match their
@@ -665,8 +693,8 @@ ordinary twins, but they have not been independently checked in the module panel
 
 Every numeric field available through in-game verification was compared. Exact
 full-field coverage includes `powerDraw`
-831/837, `bootTime` 827/833, power-plant output and efficiency 43/43 each, every FSD
-field 72/72, every thruster heat-rate record 40/40, all six distributor fields 49/49,
+826/832, `bootTime` 822/828, power-plant output and efficiency 43/43 each, every FSD
+field 67/67, every thruster heat-rate record 40/40, all six distributor fields 49/49,
 sensor range and angle 41/41, shield mass/strength curves 57/57, shield regeneration
 57/57, shield-cell timing/reinforcement/heat 40/40, fuel-scoop rate 40/40,
 interdictor range/facing 20/20, cargo capacity 16/16, fuel capacity 9/9, hull
@@ -674,7 +702,7 @@ reinforcement 30/30, module protection 20/20, shield addition 10/10, Guardian ju
 boost 5/5, weapon armour piercing 157/157, burst rounds 18/18, burst rate 16/16 and
 rounds per shot 19/19. `powerDraw` and `bootTime` have no discrepancies at all.
 
-In-game verification did not yield the 1173 store prices, hardpoint reserve ammo (120),
+In-game verification did not yield the 1176 store prices, hardpoint reserve ammo (120),
 projectile speed (111), rail-gun charge time (3), or the 23 hardpoint scanners'
 range/angle/time fields. Twenty-one hardpoint maximum-range values, ECM heat and reload,
 the 241 armour modules, blueprint grade rolls and crafting costs remain unverified too.
@@ -731,8 +759,8 @@ external readings of an unmodified weapon's folded figure. On a beam laser the f
 trivial because `damage` is already per second; the huge and medium gimballed beams have
 no separate journal `Damage` reading.
 
-**Every module in every catalogue carries at least one stat** (1199/1199), and no
-record holds only a lone `mass`. 244 of the 833 `bootTime` values are `0` (every hardpoint
+**Every module in every catalogue carries at least one stat** (1194/1194), and no
+record holds only a lone `mass`. 244 of the 828 `bootTime` values are `0` (every hardpoint
 among them); they are stored rather than omitted, because an absent field means
 absent.
 
@@ -827,8 +855,7 @@ damage for the small 1D cannon and **38.5** for the medium 2B cannon. Those read
 settle the registry disagreement in favour of coriolis-data's 22 / 38.5 rather than
 EDSY's 40 / 70. The catalogue stores the displayed values without further derivation and
 applies the same correction to their exact thermal and anti-xeno components. The two
-records are pinned in `fixtures/ships/module-stats.jsonc`. A panel reading has no upstream
-immutable revision.
+panel readings have no upstream immutable revision.
 
 **Values that look wrong and are not.** Three records break the pattern their family
 follows and are confirmed outright by EDSY. Recorded so the "breaks its family's curve"
@@ -842,7 +869,7 @@ heuristic does not keep rediscovering them:
   distributor integrity otherwise tracks 0.80× the A-rated standard ladder, which would
   put size 5 near 85; EDSY states 99 for both sizes. The duplicate is in the game data.
 - **`Int_DroneControl_Recon_Size5_Class1` `bootTime` really is 9.85** — the only
-  non-integer boot time in all 1199 records, where its three family siblings are exactly 10.
+  non-integer boot time in all 1194 records, where its three family siblings are exactly 10.
   EDSY gives `boottime:9.85`.
 
 ### Prices — `cost` on modules, `hullCost` / `retailCost` on hulls
@@ -857,18 +884,22 @@ the Lynx Highliner, which has no coriolis entry.
 Ship-specific **armour** is priced from each hull's `bulkheads` upstream, joined on hull
 and bulkhead name because those records carry no symbol upstream.
 
-- **All 48 hulls are priced. 1173 of 1199 modules are.** The 26 without a price are the
-  fifteen grant/starter `*_free` variants, the five size-8 frame shift drives, the three Mk II
-  Vessel Hangars, the two unsold Corrosion Resistant Cargo Racks (both Community Goal
-  rewards) and `Int_ShieldGenerator_Size1_Class4` — no registry publishes a figure for
-  them. **`cost` is omitted, never set to 0**: `0` is a real price (the starter
+- **All 48 hulls are priced. 1176 of 1194 modules are.** The 18 without a price are the
+  fifteen grant/starter `*_free` variants, the two unsold Corrosion Resistant Cargo Racks
+  (both Community Goal rewards) and `Int_ShieldGenerator_Size1_Class4` — no registry
+  publishes a figure for them. The three Mk II Vessel Hangars are no longer among them:
+  they are priced from an in-game purchase capture, below.
+  **`cost` is omitted, never set to 0**: `0` is a real price (the starter
   Lightweight Alloy bulkhead costs nothing), while omission means unknown.
 - **Sixteen duplicated symbols take the first occurrence's price.** Where coriolis-data
   holds a symbol twice, the "first occurrence wins" rule that governs `mass` governs
   `cost` too; taking the _second_, unpriced record would leave them at `0`. The sixteen:
-  `Hpt_HeatSinkLauncher_Turret_Tiny` 3500 — confirmed independently against a real
-  journal, which prices the fitted module at 3071 = 3500 less the 12.25% outfitting
-  discount that export was taken at; `Int_Hyperdrive_Size5_Class5` 5 103 953;
+  `Hpt_HeatSinkLauncher_Turret_Tiny` 3500 — confirmed independently against Frontier's
+  own journals, which price the fitted module at 3072 at a 12.25% discount
+  (`journal-the-deep-black.jsonc` and `journal-caspian-explorer.jsonc`, twice each). The
+  **3071** in `slef-the-deep-black.jsonc` is an EDSY export's own arithmetic over its own
+  cost table, not a game reading, and the two disagree by a credit here; §Prices read from
+  an in-game purchase capture turns on the difference; `Int_Hyperdrive_Size5_Class5` 5 103 953;
   `Int_CargoRack_Size5_Class1` 111 566 and `_Size6_Class1` 362 591;
   `Int_DetailedSurfaceScanner_Tiny` 250 000; `Hpt_MultiCannon_Fixed_Medium` 38 000;
   `Hpt_Railgun_Fixed_Medium` 412 800; `Hpt_BasicMissileRack_Fixed_Medium` 512 400;
@@ -884,8 +915,11 @@ and bulkhead name because those records carry no symbol upstream.
   registries price they agree exactly (`_Size1_Class1` 6250, `_Size4_Class1` 94 330), and
   the only corrosion racks FDevIDs `outfitting.csv` lists at all are those two plus
   `_Size1_Class2` itself — so it is the last of the purchasable ones. It is certainly not
-  free: the Deep Black's journal buys the size-4 at 82 775 = 94 330 less that export's
-  12.25% discount.
+  free: `journal-the-deep-black.jsonc` carries the size-4 at `Value: 82 774` under a
+  12.25% discount. (That reading sits a credit below what 94 330 predicts under the
+  step-wise discount rule in §Prices read from an in-game purchase capture, and is
+  recorded there as a known residual. Earlier revisions of this file quoted **82 775**
+  here as a journal reading; it is the arithmetic, not the capture.)
   - **Read that 12 560 as a 10-granular figure, not a to-the-credit one.** EDSY publishes
     module costs at **10-credit granularity**, which is measured rather than assumed. Two
     observations, both scoped to `eddb.module` — EDSY's outfitting table, where module
@@ -915,9 +949,13 @@ and bulkhead name because those records carry no symbol upstream.
     where both registries publish a multiple of 10 still differ by 10
     (`Int_FighterBay_Size{6,7}_Class1`, `Int_PassengerCabin_Size6_Class1`), which no
     rounding explains: whatever the real price is, at least one of the two registries is
-    wrong about it by five credits or more, and neither says which. So treat 12 560 as the
-    best published figure at 10-credit resolution, not as an accuracy guarantee; only an
-    in-game reading settles the last digits. Every EDSY-sourced price in this catalogue
+    wrong about it by five credits or more, and neither says which. In-game readings
+    settle two of the three, with coriolis exactly right in both:
+    `Int_FighterBay_Size7_Class1` is 2 369 320 and `Int_FighterBay_Size6_Class1` is
+    1 869 340, so EDSY's 2 369 330 is the wrong member of that pair (see "Prices read from
+    an in-game purchase capture" below). So treat 12 560 as
+    the best published figure at 10-credit resolution, not as an accuracy guarantee; only
+    an in-game reading settles the last digits. Every EDSY-sourced price in this catalogue
     carries the same granularity, so this record is no less exact than the rest of them.
 - **The size-5 and size-6 Corrosion Resistant Cargo Racks have no list price to
   publish**, and their absent `cost` means _no list price exists_, not _none has been
@@ -965,9 +1003,84 @@ and bulkhead name because those records carry no symbol upstream.
   thermal −0.2, explosive 0.5, draw 0.6. The cargo hatch (`ModularCargoBayDoor`) takes
   the 0.6 MW draw Coriolis hard-codes for it (`ModuleUtils.cargoHatch`), since it is
   fitted to every hull and cannot be removed.
-- **Not modelled:** passenger capacity and fighter-bay/rebuild counts. The
-  **Merc-Coin** price of the pre-engineered variants is carried, but on the variant
-  rather than the module — see `mercCoinCost` in the pre-engineered section.
+- **Not modelled:** fighter-bay/rebuild counts. The **Merc-Coin** price of the
+  pre-engineered variants is carried, but on the variant rather than the module — see
+  `mercCoinCost` in the pre-engineered section.
+
+### Prices read from an in-game purchase capture
+
+Nine `ModuleBuyAndStore` journal entries, all from market `128666762` within four minutes
+on **2026-08-30 UTC** and supplied by the repository owner, price three module records no
+registry carries and confirm or correct six that were already priced. The capture was
+taken at a **10% and a 2.5% discount**, so each `BuyPrice` is the list price with both
+discounts applied. A journal `BuyPrice` is what the commander was actually charged, which
+is the objection that disqualifies a `Loadout` `Value` of unknown provenance (§the size-5
+and size-6 racks): here the discount is stated rather than solved for.
+
+- **The game subtracts a truncated discount at each step; it does not truncate the
+  product.** Each discount takes `floor(price x rate)` off the running price, so
+  `paid = ceil(ceil(list x 0.9) x 0.975)`, and the two orders give the same answer for
+  every row here. This is measured, not assumed: scored against **every** `Loadout`
+  `Value` in `fixtures/ships/journal-*.jsonc` that a catalogue price and a standard
+  discount can reproduce (455 readings), the step-wise rule matches 304, a single
+  `ceil(list x 0.8775)` 275, `round` 230 and `floor` 92. Restricting to 2.5%-only
+  readings gives the same ordering. **Do not derive a price from a single control**: two
+  readings were originally used here and both were unrepresentative, which is how an
+  earlier revision of this section published a truncation rule and eight wrong figures.
+- **`Hpt_HeatSinkLauncher_Turret_Tiny` is the reading that settles the last credit.** Its
+  list price is 3500, both registries agree, and `3500 x 0.8775 = 3071.25`. Frontier's own
+  journals read **3072** — `fixtures/ships/journal-the-deep-black.jsonc` and
+  `journal-caspian-explorer.jsonc`, twice each — which excludes truncation and
+  round-to-nearest alike. The **3071** quoted elsewhere in this file is not a game reading:
+  it comes from `fixtures/ships/slef-the-deep-black.jsonc`, an EDSY SLEF export whose
+  `Value`s are EDSY's own arithmetic. The two documents disagree wherever they overlap
+  (3071/3072, 82 775/82 774, 195 191/195 195), so a third-party export is not admissible
+  as evidence of what the game charged.
+
+| Symbol                                   | Paid       | List price | Was                   |
+| ---------------------------------------- | ---------- | ---------- | --------------------- |
+| `Int_FighterBayMk2_Size5_Class1`         | 697 076    | 794 387    | unpriced              |
+| `Int_FighterBayMk2_Size6_Class1`         | 2 263 678  | 2 579 689  | unpriced              |
+| `Int_FighterBayMk2_Size7_Class1`         | 2 869 128  | 3 269 661  | unpriced              |
+| `Int_FighterBay_Size7_Class1`            | 2 079 079  | 2 369 320  | 2 369 320 (confirmed) |
+| `Int_Hyperdrive_Overcharge_Size8_Class1` | 6 000 827  | 6 838 548  | 6 838 550 (EDSY)      |
+| `Int_Hyperdrive_Overcharge_Size8_Class2` | 18 002 479 | 20 515 645 | 20 515 650 (EDSY)     |
+| `Int_Hyperdrive_Overcharge_Size8_Class3` | 18 002 479 | 20 515 645 | 20 515 650 (EDSY)     |
+| `Int_Hyperdrive_Overcharge_Size8_Class4` | 18 002 479 | 20 515 645 | 20 515 650 (EDSY)     |
+| `Int_Hyperdrive_Overcharge_Size8_Class5` | 54 007 436 | 61 546 935 | 61 546 940 (EDSY)     |
+
+- **Seven of the nine readings pin one integer; two do not, and are settled by other
+  evidence.** A one-credit band of paid price spans `400/351 = 1.14` credits of list price,
+  so a reading admits one or two candidates.
+  - `Int_FighterBayMk2_Size5_Class1` is pinned at 794 387 by the capture **and**
+    independently by a second reading this repository already held: `Value: 774 528` at
+    2.5%, in both `journal-the-deep-black.jsonc` and `journal-caspian-explorer.jsonc`. Two
+    captures at different discounts, one answer.
+  - `Int_FighterBayMk2_Size6_Class1` admits 2 579 689 and 2 579 690. It takes **2 579 689**
+    from the family rule below, which is a derivation and not a reading.
+  - `Int_FighterBay_Size7_Class1` admits 2 369 319 and 2 369 320, and **keeps coriolis's
+    2 369 320** — the reading confirms the published figure rather than moving it, and
+    settles one of the three registry pairs §Prices flags as differing by 10. Its sibling
+    `Int_FighterBay_Size6_Class1` (1 869 340) is confirmed outright by four corvette
+    readings at two different discounts.
+- **The Mk II bays are `floor(Mk I x 1.38)` at every size.** The rule reproduces both
+  independently pinned values exactly — `floor(575 643 x 1.38) = 794 387` and
+  `floor(2 369 320 x 1.38) = 3 269 661` — which is what licenses it to choose 2 579 689 for
+  the size-6 bay. Stated as derivation for that one record, and as an observation for the
+  other two.
+- **The size-8 SCO drives are priced identically to their size-7 siblings.** All four
+  distinct readings land exactly on coriolis's size-7 figures (6 838 548, 20 515 645,
+  61 546 935), and EDSY's size-8 numbers are those same figures rounded to 10. The
+  catalogue carries the exact readings rather than EDSY's rounded figures.
+- **A known residual.** `Int_CorrosionProofCargoRack_Size4_Class1` at 94 330 predicts
+  82 775 under this rule where `journal-the-deep-black.jsonc` reads **82 774**. It is one
+  of a minority of records whose catalogue list price appears to sit a credit or two above
+  the game's, and it is recorded here rather than explained away — it is not evidence for
+  truncation, which the corpus rejects 304 to 92.
+- **What would supersede these figures:** a purchase or outfitting reading at 0% discount,
+  which needs no model at all. Until then they are readings through one measured
+  arithmetic rule, which is a weaker claim than a direct quote and a stronger one than a
+  registry's rounded figure.
 
 ### Armour, and the fields kept deliberately
 
@@ -1057,7 +1170,11 @@ Records not in coriolis-data / FDevIDs at the acquired revisions:
   bays at half the mass (10/20/30 t, integrity 60/80/120, power
   0.25/0.35/0.35 MW). The three Mk I **Fighter Hangar** records are named **Mk I Vessel
   Hangar** (same symbols and stats; the Operations update renamed them and let them
-  deploy the Nomad).
+  deploy the Nomad). Their prices — which no registry carries, EDSY having no record of
+  the Mk II bays at all — are read from the in-game purchase capture in §Prices: 794 387,
+  2 579 689 and 3 269 661. Each Mk II bay is `floor(Mk I x 1.38)`; that is an observation
+  about the size-5 and size-7 figures, whose readings pin them outright, and the
+  derivation that settles the size-6 figure, whose reading admits two candidates.
   - **Six bundle-granted variants are separate identities.** The pinned CAPI response
     lists `Int_FighterBay{,Mk2}_Size{5,6,7}_Class1_Free` as modules with `bundle: true`
     and the grant tokens `ELITE_V_MKIFIGHTERBAY_FREE` / `ELITE_V_MKIIFIGHTERBAY_FREE`.
@@ -1070,8 +1187,10 @@ Records not in coriolis-data / FDevIDs at the acquired revisions:
     zero is the bundle charge, not a standard purchase price for a separately sold
     module.
 - **Mk II passenger cabins** (`Int_MkII_PassengerCabin_Size{2..6}_Class{1,2}`) — identity
-  records from FDevIDs, with mass added (2.5/5/10/20/40 t by size) and the two size-6
-  records' `class` corrected from 5 to 6.
+  records from FDevIDs, with mass (2.5/5/10/20/40 t by size) and `cabinCapacity` added
+  from EDSY, the only registry that publishes stats for them — coriolis-data carries no
+  record at all — and the two size-6 records' `class` corrected from 5 to 6. The
+  capacities and how they relate to the Mk I cabins' are under `cabinCapacity` above.
 - **Corrosion Resistant Cargo Racks** `Int_CorrosionProofCargoRack_Size{5,6}_Class1`
   (capacity 32/64) and the built-in **Cargo Hatch** `ModularCargoBayDoor` (power 0.6 MW)
   — live EDSY records (not commented out, unlike the 1B shield generator below) that the
@@ -1087,6 +1206,34 @@ Records not in coriolis-data / FDevIDs at the acquired revisions:
     carries it `cost: NaN` annotated "never released". A variant that never reached
     players is not a player-facing outfitting record, so it goes the way of the other
     non-purchasable internal variants that rule excludes.
+- **Plain size-8 Frame Shift Drives are not carried: outfitting does not sell them.**
+  `Int_Hyperdrive_Size8_Class{1..5}` are excluded on direct in-game observation
+  (2026-08-30 UTC, §the pinned sources) that no non-SCO size-8 drive is offered. The five
+  `Int_Hyperdrive_Overcharge_Size8_Class{1..5}` records are the size-8 drives the game
+  does sell. Only one hull in the catalogue carries a size-8 frame-shift mount at all —
+  the Caspian Explorer (`Explorer_NX`), every other size-8-capable hull including the
+  Panther Clipper Mk II mounting a size 7 — and `default-loadouts.jsonc` ships that hull
+  with `Int_Hyperdrive_Overcharge_Size8_Class1`, so the one stock size-8 drive in the
+  data is an SCO drive.
+  - **The case rests on the observation, not on the registries, and is weaker than the
+    precedent it follows.** FDevIDs `outfitting.csv` does carry these five rows — which is
+    why they were in the catalogue, and it means the Inclusion rule below, read literally,
+    admits them. What overrides it is this catalogue's own rule that in-game verification
+    governs where a registry disagrees. The other two registries are consistent but not
+    probative: coriolis-data has no record, which is also true of the Mk II Vessel Hangars
+    and the size-5/6 Corrosion Resistant Cargo Racks that _are_ carried; EDSY carries the
+    five commented out, which is also true of `Int_ShieldGenerator_Size1_Class4` below,
+    carried as real. `Int_CorrosionProofCargoRack_Size2_Class1` is the stronger case — no
+    FDevIDs row at all and an explicit EDSY "never released" — so this exclusion is the
+    same _kind_ of judgement on thinner evidence, and a contrary in-game reading should
+    reverse it.
+  - **The 2026-08-14 in-game audit's totals counted these five as verified, and are
+    restated.** That audit reported `identityMatches` 1193 of 1199 with 952 non-armour
+    modules checked numerically, and "every FSD field 72/72" — figures that could not have
+    been true of five records the game does not offer. The corrected accounting is 1188
+    identity matches, 947 non-armour modules and 67/67 FSD fields, with
+    `registryOnlyIdentities` at 6. Those are the standing audit figures; the source
+    capture itself has not changed.
 - **1B Shield Generator** (`Int_ShieldGenerator_Size1_Class4`) — a gap in FDevIDs, not
   in the game: every other shield-generator size carries all five ratings, and size 1
   ran E/D/C/A with **B missing**. The module is real, so the record is carried with the
@@ -1484,13 +1631,13 @@ up straight through with no disambiguation at all. Both paths are evidence that
 - **Availability is a property of the module, not of the blueprint.** A Pulse Laser and a
   Rail Gun both take the Efficient blueprint but offer different experimental effects, so
   "which experimentals go with blueprint X" has no single answer. Modules are therefore
-  grouped (48 groups covering 1005 ordinary engineering menus) and each group lists the
+  grouped (48 groups covering 1000 ordinary engineering menus) and each group lists the
   `blueprints` and `experimentals` it offers.
 - **A group carries no display name.** The grouping is this repository's own partition of
   the modules sharing one menu; the game publishes no engineering-group label, heading
-  each menu with the module's outfitting family instead. EDSY's `mtype-*` strings, which
-  this file previously stored as group names, are outfitting labels reached by a name
-  join — which is why they disagreed with `module-families.jsonc` in 22 places on wording
+  each menu with the module's outfitting family instead. EDSY's `mtype-*` strings are
+  outfitting labels reached by a name join and disagree with `module-families.jsonc` in
+  22 places on wording
   (`cannons` Russian "Пушки" against the family's "Орудия", `moduleReinforcements`
   Brazilian Portuguese title case against the family's sentence case). Consumers name a
   group by joining a module's `familyId` to `module-families.jsonc`. The two partitions
@@ -1504,7 +1651,7 @@ up straight through with no disambiguation at all. Both paths are evidence that
   `modifications/modules.json`, which carries the same per-group lists keyed by the
   journal `BlueprintName`s this catalogue joins on.
 - **Coverage: every retained group EDSY's `mtype` table gives a `blueprints:` key.** After
-  the corrections below, that is 48 groups over 1005
+  the corrections below, that is 48 groups over 1000
   modules, including
   bulkheads (the 241 ship armour records), life
   support, sensors, the Detailed Surface Scanner, refineries, AFMUs, fuel
@@ -1597,13 +1744,12 @@ up straight through with no disambiguation at all. Both paths are evidence that
     fixed Expanded Cargo Rack reward identity. Four Operations keys _are_ named by a
     group, because they are recipes a player applies — see "Four Operations recipes are
     listed by a menu" below.
-  - **14 modules are bound by the family rule, not by a source row.** EDSY has no live
-    entry for `Int_Hyperdrive_Size8_Class{1..5}` or `Int_ShieldGenerator_Size1_Class4`
-    (both present but commented out, and both naming their `mtype` — `cfsd` and `isg`),
-    nor for eight of the `*_free` starter fittings. Each takes its family's group, on the
-    same rule the stats above use: a `*_free` variant is its priced twin bar the price,
-    and a size-8 drive is a drive. `Int_FuelTank_Size1_Class3_free` is not bound because
-    fuel tanks are not engineerable.
+  - **9 modules are bound by the family rule, not by a source row.** EDSY has no live
+    entry for `Int_ShieldGenerator_Size1_Class4` (present but commented out, and naming
+    its `mtype` — `isg`), nor for eight of the `*_free` starter fittings. Each takes its
+    family's group, on the same rule the stats above use: a `*_free` variant is its priced
+    twin bar the price. `Int_FuelTank_Size1_Class3_free` is not bound because fuel tanks
+    are not engineerable.
 - **Corpus evidence does not override `noblueprints`.** Two corpus builds declare
   `Weapon_Efficient` on the Mk II Plasma Shock Accelerator, while EDSY denies that module
   every blueprint (`noblueprints: {'*'}`). Coriolis publishes only the group-level menu
@@ -1660,7 +1806,7 @@ up straight through with no disambiguation at all. Both paths are evidence that
   five module mappings and the corresponding projected `kind` fields in
   `modules-hardpoint.jsonc`.
 - **An empty experimental menu is still distinct from no menu.** 27 of the 48 groups offer
-  no experimental at all, so 368 of the 1005 grouped modules have an empty experimental
+  no experimental at all, so 368 of the 1000 grouped modules have an empty experimental
   list while retaining blueprints.
 - **Key form:** the Anti-Guardian blueprint is listed under `GuardianModule_Sturdy`, the id
   a Loadout writes and the one EDSY uses — the same and only spelling `blueprints.jsonc`
@@ -1747,6 +1893,29 @@ up straight through with no disambiguation at all. Both paths are evidence that
 
 ## Pre-engineered modules
 
+### A tech-broker unlock may be sold under its own name
+
+Nineteen of the tech-broker variants are not sold as the plain base module. Each carries
+one of three markers, supplied by repository-owner in-game verification (2026-08-30 UTC);
+no registry publishes them, and the game exposes no immutable identifier for its
+outfitting strings.
+
+| Marker | Variants | Name |
+| --- | ---: | --- |
+| `Sirius` | 1 + 2 | Sirius Heat Sink Launcher, Sirius AX Missile Rack |
+| `Azimuth` | 2 | Azimuth Enhanced AX Multi-Cannon |
+| `Modified` | 2 + 2 + 2 | Modified Guardian Plasma Charger / Gauss Cannon / Shard Cannon |
+| `V1` | 6 + 1 + 1 | Frame Shift Drive (SCO) V1, Detailed Surface Scanner V1, Seeker Missile Rack V1 |
+
+`Sirius` and `Azimuth` are the manufacturers that sell the unlock; `V1` marks a first
+fixed revision. The marker is a property of the **tech-broker** route, not of the module:
+`Hpt_Guardian_ShardCannon_Fixed_Medium` is a Modified Guardian Shard Cannon bought from a
+broker and a plain Guardian Shard Cannon earned from a community goal, and the two rows
+differ only by `acquisition`. The same holds for `Hpt_BasicMissileRack_Fixed_Medium`,
+whose thermal-cascade tech-broker row is a Seeker Missile Rack V1 while its three
+community-goal rows are plain. Two tech-broker rows carry no marker at all and keep their
+base module's name: the Mining Laser and the size-5 Frame Shift Drive.
+
 ### Festive variants
 
 - **File:** `pre-engineered.jsonc`. Three grade-5 records pair

package/README.md

@@ -140,12 +140,13 @@ data-free leaf modules under `ships/jump-range`, `ships/power`, `ships/shields`,
 `ships/resistances`.
 
 `build.validation()` reports validity and operational completeness. `cargoCapacity`,
-`fuelCapacity` and `unladenMass` always have an answer, because no article the
-catalogue cannot weigh reaches a build; the eight metrics that depend on build state
-(`mobilityMetrics`, `mobilityCapacitorMetrics`, `shieldMetrics`,
-`shieldCapacitorMetrics`, `shieldRecovery`, `heatMetrics`, `distributorMetrics` and
-`standardLoad`) are nullable and each has a `…Result` counterpart naming what is
-missing, switched off, shed or unpowered. `parseSlef`
+`passengerCapacity`, `fuelCapacity` and `unladenMass` always have an answer, because no
+article the catalogue cannot weigh reaches a build. The eight build-state methods
+(`mobilityMetricsResult`, `mobilityCapacitorMetricsResult`, `shieldMetricsResult`,
+`shieldCapacitorMetricsResult`, `shieldRecoveryResult`, `heatMetricsResult`,
+`distributorMetricsResult` and `standardLoadResult`) return a diagnostic result whose
+value is either complete or `null`, with issues naming what is missing, unresolved,
+switched off, shed or invalid. `parseSlef`
 is strict; `inspectSlef` is the tolerant importer for mixed files and returns indexed
 diagnostics instead of silently dropping entries.
 
@@ -172,16 +173,30 @@ import {
     getMicroResourceName,
     getModuleName,
     getOutfittingFamilyName,
+    getPersonalModificationName,
+    getSuitName,
 } from '@elite-dangerous-almanac/core/i18n';
 
 getModuleName('Int_Hyperdrive_Size6_Class5', 'de-DE'); // -> "Frameshiftantrieb"
 getBlueprintName('FSD_LongRange', 'fr-FR'); // -> "Portée FSD améliorée"
 getMaterialName('GridResistors', 'de'); // -> "Gitterwiderstände"
 getMicroResourceName('graphene', 'fr'); // -> "Graphène"
+getSuitName('explorationsuit_class3', 'de'); // -> "Artemis-Anzug"
+getPersonalModificationName('suit_nightvision', 'fr'); // -> "Vision nocturne"
 getOutfittingFamilyName('shieldGenerators', 'de'); // -> "Schildgeneratoren"
 getOutfittingFamilyName('xenoScanners', 'de'); // -> null
 ```
 
+Display prose the game shows a player — a suit's or a handheld weapon's blurb, what an
+experimental effect or an engineer's modification does — has its own lookups in the same
+`i18n` area, each on its own subpath, complete in all six locales:
+
+```ts
+import { getSuitDescription } from '@elite-dangerous-almanac/core/i18n/suits';
+
+getSuitDescription('utilitysuit', 'en')?.slice(0, 20); // -> "The Maverick suit is"
+```
+
 The functions return an explicit source value verbatim, so a source-backed spelling may
 happen to equal English; the library itself never supplies an English fallback. The
 catalogues carry English, French, German, Portuguese, Russian and Spanish, each stored

package/THIRD_PARTY_NOTICES.md

@@ -161,7 +161,10 @@ a verbatim copy produced at build time — edit this file, never the copy.
   with its [announcement](https://x.com/EliteDangerous/status/1812792503776489745).
   Frontier's own **in-game localisation** supplies the outfitting category labels behind
   the module families and their German, Spanish, French, Brazilian Portuguese and Russian
-  display text, and the engineering modification names in the six stored locales.
+  display text, the engineering modification names in the six stored locales, and the
+  personal-equipment display text in `data/i18n/`: the suit names and descriptions, the
+  handheld-weapon descriptions, and the names and descriptions of the engineer-applied
+  suit and weapon modifications.
   Values read directly from the running game are Frontier's too — see the notice below.
 - **A [community description](https://www.reddit.com/r/EliteDangerous/comments/1uk2zhp/plasma_laser_theorycrafting_following_new/)
   by u/Techno3020** — linked only as corroboration that the Operations Plasma conversion's

package/dist/{chunk-AAU7OM47.js → chunk-2OBUSQA7.js}

@@ -1 +1 @@
-import{requireFiniteNonNegative}from"./chunk-65FZECUX.js";import{journalRateOfFire}from"./chunk-EFQOUATZ.js";function combinedRateOfFire(weapon){return journalRateOfFire(weapon.burstInterval,weapon.burstRounds,weapon.burstRateOfFire)}var ZERO_SPLIT={kinetic:0,thermal:0,explosive:0,absolute:0,antiXeno:0};function splitDamage(damage,distribution){if(!distribution)return Object.freeze({...ZERO_SPLIT,absolute:damage});return Object.freeze({kinetic:damage*(distribution.kinetic??0),thermal:damage*(distribution.thermal??0),explosive:damage*(distribution.explosive??0),absolute:damage*(distribution.absolute??0),...(distribution.unclassified??0)===0?{}:{unclassified:damage*distribution.unclassified},antiXeno:damage*(distribution.antiXeno??0)})}function splitComponents(damage,components){const unclassified=(components.unclassified??[]).reduce((sum,value)=>sum+value,0);const conventional=(components.kinetic??0)+(components.thermal??0)+(components.explosive??0)+(components.absolute??0)+unclassified;if(conventional<=0)return Object.freeze({...ZERO_SPLIT,absolute:damage});const scale=damage/conventional;return Object.freeze({kinetic:(components.kinetic??0)*scale,thermal:(components.thermal??0)*scale,explosive:(components.explosive??0)*scale,absolute:(components.absolute??0)*scale,...unclassified===0?{}:{unclassified:unclassified*scale},antiXeno:(components.antiXeno??0)*scale})}function sustainedFireFactor(weapon){const rateOfFire=weapon.rateOfFire;const clip=weapon.clipSize===void 0?void 0:Math.ceil(weapon.clipSize);if(!rateOfFire||!clip||clip<=0)return 1;const burst=weapon.burstRounds&&weapon.burstRounds>0?weapon.burstRounds:1;const burstRate=weapon.burstRateOfFire&&weapon.burstRateOfFire>0?weapon.burstRateOfFire:1;const reload=weapon.reloadTime??0;const cycle=(clip-burst)/rateOfFire+(burst-1)/burstRate+reload;if(cycle<=0)return 1;const sustainedRate=clip/cycle;return Math.min(1,sustainedRate/rateOfFire)}function damagePerSecond(weapon){const damage=weapon.damage??0;const rounds=weapon.roundsPerShot&&weapon.roundsPerShot>0?weapon.roundsPerShot:1;return damage*rounds*(weapon.rateOfFire??1)}function sustainedDamagePerSecond(weapon){return damagePerSecond(weapon)*sustainedFireFactor(weapon)}function energyPerSecond(weapon){return(weapon.distributorDraw??0)*(weapon.rateOfFire??1)}function heatPerSecond(weapon){return(weapon.thermalLoad??0)*(weapon.rateOfFire??1)}function damageFalloff(weapon,metres){const maximum=weapon.maximumRange;if(maximum!==void 0&&metres>maximum)return 0;const falloff=weapon.falloffRange;if(falloff===void 0||maximum===void 0||metres<=falloff)return 1;const taper=maximum-falloff;if(taper<=0)return 1;return Math.max(0,1-(metres-falloff)/taper)}function armourPiercingFactor(armourPiercing,hardness){requireFiniteNonNegative("armourPiercingFactor","armour piercing",armourPiercing);requireFiniteNonNegative("armourPiercingFactor","hardness",hardness);if(hardness===0)return 1;return Math.min(1,armourPiercing/hardness)}function weaponMetrics(weapon){const continuous=weapon.rateOfFire===void 0;const rateOfFire=weapon.rateOfFire??1;const factor=sustainedFireFactor(weapon);const dps=damagePerSecond(weapon);const sdps=dps*factor;const eps=energyPerSecond(weapon);const hps=heatPerSecond(weapon);const rounds=weapon.roundsPerShot&&weapon.roundsPerShot>0?weapon.roundsPerShot:1;return Object.freeze({damagePerShot:(weapon.damage??0)*rounds,rateOfFire:rateOfFire,sustainedRateOfFire:rateOfFire*factor,damagePerSecond:dps,sustainedDamagePerSecond:sdps,energyPerSecond:eps,sustainedEnergyPerSecond:eps*factor,heatPerSecond:hps,sustainedHeatPerSecond:hps*factor,thermalLoad:weapon.thermalLoad??0,powerDraw:weapon.powerDraw??0,damageByType:weapon.damageComponents?splitComponents(dps,weapon.damageComponents):splitDamage(dps,weapon.damageDistribution),sustainedDamageByType:weapon.damageComponents?splitComponents(sdps,weapon.damageComponents):splitDamage(sdps,weapon.damageDistribution),continuous:continuous})}function sumWeaponMetrics(metrics){const damageByType=emptyDamageSplitAccumulator();const sustainedDamageByType=emptyDamageSplitAccumulator();let damagePerSecond2=0;let sustainedDamagePerSecond2=0;let energyPerSecond2=0;let sustainedEnergyPerSecond=0;let heatPerSecond2=0;let sustainedHeatPerSecond=0;let thermalLoad=0;let powerDraw=0;for(const metric of metrics){damagePerSecond2+=metric.damagePerSecond;sustainedDamagePerSecond2+=metric.sustainedDamagePerSecond;energyPerSecond2+=metric.energyPerSecond;sustainedEnergyPerSecond+=metric.sustainedEnergyPerSecond;heatPerSecond2+=metric.heatPerSecond;sustainedHeatPerSecond+=metric.sustainedHeatPerSecond;thermalLoad+=metric.thermalLoad;powerDraw+=metric.powerDraw;addDamageSplit(damageByType,metric.damageByType);addDamageSplit(sustainedDamageByType,metric.sustainedDamageByType)}return Object.freeze({damagePerSecond:damagePerSecond2,sustainedDamagePerSecond:sustainedDamagePerSecond2,energyPerSecond:energyPerSecond2,sustainedEnergyPerSecond:sustainedEnergyPerSecond,heatPerSecond:heatPerSecond2,sustainedHeatPerSecond:sustainedHeatPerSecond,thermalLoad:thermalLoad,powerDraw:powerDraw,damageByType:finishDamageSplit(damageByType),sustainedDamageByType:finishDamageSplit(sustainedDamageByType)})}function emptyDamageSplitAccumulator(){return{kinetic:0,thermal:0,explosive:0,absolute:0,unclassified:0,antiXeno:0}}function addDamageSplit(total,split){total.kinetic+=split.kinetic;total.thermal+=split.thermal;total.explosive+=split.explosive;total.absolute+=split.absolute;total.unclassified+=split.unclassified??0;total.antiXeno+=split.antiXeno}function finishDamageSplit(total){const{unclassified:unclassified,...classified}=total;return Object.freeze(unclassified===0?classified:{...classified,unclassified:unclassified})}export{armourPiercingFactor,combinedRateOfFire,damageFalloff,damagePerSecond,energyPerSecond,heatPerSecond,splitDamage,sumWeaponMetrics,sustainedDamagePerSecond,sustainedFireFactor,weaponMetrics};//# sourceMappingURL=chunk-AAU7OM47.js.map
+import{journalRateOfFire}from"./chunk-EFQOUATZ.js";import{requireFiniteNonNegative}from"./chunk-65FZECUX.js";function combinedRateOfFire(weapon){return journalRateOfFire(weapon.burstInterval,weapon.burstRounds,weapon.burstRateOfFire)}var ZERO_SPLIT={kinetic:0,thermal:0,explosive:0,absolute:0,antiXeno:0};function splitDamage(damage,distribution){if(!distribution)return Object.freeze({...ZERO_SPLIT,absolute:damage});return Object.freeze({kinetic:damage*(distribution.kinetic??0),thermal:damage*(distribution.thermal??0),explosive:damage*(distribution.explosive??0),absolute:damage*(distribution.absolute??0),...(distribution.unclassified??0)===0?{}:{unclassified:damage*distribution.unclassified},antiXeno:damage*(distribution.antiXeno??0)})}function splitComponents(damage,components){const unclassified=(components.unclassified??[]).reduce((sum,value)=>sum+value,0);const conventional=(components.kinetic??0)+(components.thermal??0)+(components.explosive??0)+(components.absolute??0)+unclassified;if(conventional<=0)return Object.freeze({...ZERO_SPLIT,absolute:damage});const scale=damage/conventional;return Object.freeze({kinetic:(components.kinetic??0)*scale,thermal:(components.thermal??0)*scale,explosive:(components.explosive??0)*scale,absolute:(components.absolute??0)*scale,...unclassified===0?{}:{unclassified:unclassified*scale},antiXeno:(components.antiXeno??0)*scale})}function sustainedFireFactor(weapon){const rateOfFire=weapon.rateOfFire;const clip=weapon.clipSize===void 0?void 0:Math.ceil(weapon.clipSize);if(!rateOfFire||!clip||clip<=0)return 1;const burst=weapon.burstRounds&&weapon.burstRounds>0?weapon.burstRounds:1;const burstRate=weapon.burstRateOfFire&&weapon.burstRateOfFire>0?weapon.burstRateOfFire:1;const reload=weapon.reloadTime??0;const cycle=(clip-burst)/rateOfFire+(burst-1)/burstRate+reload;if(cycle<=0)return 1;const sustainedRate=clip/cycle;return Math.min(1,sustainedRate/rateOfFire)}function damagePerSecond(weapon){const damage=weapon.damage??0;const rounds=weapon.roundsPerShot&&weapon.roundsPerShot>0?weapon.roundsPerShot:1;return damage*rounds*(weapon.rateOfFire??1)}function sustainedDamagePerSecond(weapon){return damagePerSecond(weapon)*sustainedFireFactor(weapon)}function energyPerSecond(weapon){return(weapon.distributorDraw??0)*(weapon.rateOfFire??1)}function heatPerSecond(weapon){return(weapon.thermalLoad??0)*(weapon.rateOfFire??1)}function damageFalloff(weapon,metres){const maximum=weapon.maximumRange;if(maximum!==void 0&&metres>maximum)return 0;const falloff=weapon.falloffRange;if(falloff===void 0||maximum===void 0||metres<=falloff)return 1;const taper=maximum-falloff;if(taper<=0)return 1;return Math.max(0,1-(metres-falloff)/taper)}function armourPiercingFactor(armourPiercing,hardness){requireFiniteNonNegative("armourPiercingFactor","armour piercing",armourPiercing);requireFiniteNonNegative("armourPiercingFactor","hardness",hardness);if(hardness===0)return 1;return Math.min(1,armourPiercing/hardness)}function weaponMetrics(weapon){const continuous=weapon.rateOfFire===void 0;const rateOfFire=weapon.rateOfFire??1;const factor=sustainedFireFactor(weapon);const dps=damagePerSecond(weapon);const sdps=dps*factor;const eps=energyPerSecond(weapon);const hps=heatPerSecond(weapon);const rounds=weapon.roundsPerShot&&weapon.roundsPerShot>0?weapon.roundsPerShot:1;return Object.freeze({damagePerShot:(weapon.damage??0)*rounds,rateOfFire:rateOfFire,sustainedRateOfFire:rateOfFire*factor,damagePerSecond:dps,sustainedDamagePerSecond:sdps,energyPerSecond:eps,sustainedEnergyPerSecond:eps*factor,heatPerSecond:hps,sustainedHeatPerSecond:hps*factor,thermalLoad:weapon.thermalLoad??0,powerDraw:weapon.powerDraw??0,damageByType:weapon.damageComponents?splitComponents(dps,weapon.damageComponents):splitDamage(dps,weapon.damageDistribution),sustainedDamageByType:weapon.damageComponents?splitComponents(sdps,weapon.damageComponents):splitDamage(sdps,weapon.damageDistribution),continuous:continuous})}function sumWeaponMetrics(metrics){const damageByType=emptyDamageSplitAccumulator();const sustainedDamageByType=emptyDamageSplitAccumulator();let damagePerSecond2=0;let sustainedDamagePerSecond2=0;let energyPerSecond2=0;let sustainedEnergyPerSecond=0;let heatPerSecond2=0;let sustainedHeatPerSecond=0;let thermalLoad=0;let powerDraw=0;for(const metric of metrics){damagePerSecond2+=metric.damagePerSecond;sustainedDamagePerSecond2+=metric.sustainedDamagePerSecond;energyPerSecond2+=metric.energyPerSecond;sustainedEnergyPerSecond+=metric.sustainedEnergyPerSecond;heatPerSecond2+=metric.heatPerSecond;sustainedHeatPerSecond+=metric.sustainedHeatPerSecond;thermalLoad+=metric.thermalLoad;powerDraw+=metric.powerDraw;addDamageSplit(damageByType,metric.damageByType);addDamageSplit(sustainedDamageByType,metric.sustainedDamageByType)}return Object.freeze({damagePerSecond:damagePerSecond2,sustainedDamagePerSecond:sustainedDamagePerSecond2,energyPerSecond:energyPerSecond2,sustainedEnergyPerSecond:sustainedEnergyPerSecond,heatPerSecond:heatPerSecond2,sustainedHeatPerSecond:sustainedHeatPerSecond,thermalLoad:thermalLoad,powerDraw:powerDraw,damageByType:finishDamageSplit(damageByType),sustainedDamageByType:finishDamageSplit(sustainedDamageByType)})}function emptyDamageSplitAccumulator(){return{kinetic:0,thermal:0,explosive:0,absolute:0,unclassified:0,antiXeno:0}}function addDamageSplit(total,split){total.kinetic+=split.kinetic;total.thermal+=split.thermal;total.explosive+=split.explosive;total.absolute+=split.absolute;total.unclassified+=split.unclassified??0;total.antiXeno+=split.antiXeno}function finishDamageSplit(total){const{unclassified:unclassified,...classified}=total;return Object.freeze(unclassified===0?classified:{...classified,unclassified:unclassified})}export{armourPiercingFactor,combinedRateOfFire,damageFalloff,damagePerSecond,energyPerSecond,heatPerSecond,splitDamage,sumWeaponMetrics,sustainedDamagePerSecond,sustainedFireFactor,weaponMetrics};//# sourceMappingURL=chunk-2OBUSQA7.js.map