ships.Function.resolveBlueprintForModule

@elite-dangerous-almanac/core / ships / resolveBlueprintForModule

Function: resolveBlueprintForModule()

resolveBlueprintForModule(symbol, fdname): string

Defined in: src/ships/blueprint-journal.ts:119

The blueprint whose numbers a module actually rolls when a journal names blueprint on it — the same id back, except where the game spells two different recipes alike.

One BlueprintName, two recipes. Long Range and Wide Angle are offered on the internal sensor suite and on the KWS/manifest/wake scanners, and the game writes the same id for both families. The two roll different stats, in opposite directions:

On a sensor suite	On a utility scanner
Long Range: Mass ×1.20, ScannerRange +0…15%	Long Range: PowerDraw ×1.10, ScannerRange +0…24%
Wide Angle: PowerDraw ×1.10, ScannerRange −4%	Wide Angle: Mass ×1.20, ScannerTimeToScan +10%

(Grade 1 shown; both pairs share their SensorTargetScanAngle leg.) BLUEPRINTS keys the scanner side under Scanner_LongRange / Scanner_WideAngle, which is the spelling the scanner menus list — so on a scanner this resolves Sensor_LongRange to Scanner_LongRange, and folding the id as written would charge the build mass where the game charges power draw.

One BlueprintName, two recipes — again, on the multi-cannons. The game writes Weapon_Overcharged for every weapon's Overcharged, but a multi-cannon's also cuts the clip — 3% at grade 1 falling to 15% at grade 5 — which the recipe the other weapons take does not. BLUEPRINTS keys the multi-cannon side under MC_Overcharged, the spelling the multi-cannon menus list, so on a multi-cannon this resolves Weapon_Overcharged to MC_Overcharged and folding the id as written would report a clip the build does not have. This is the common case of the three: 70 of the build corpus's 1902 declared entries go through it, against one for the scanners.

The clip penalty is folded only when a module's engineering menu offers the multi-cannon recipe. Anti-xeno multi-cannons have no ordinary engineering menu, so their journal id stays unchanged. Cannons, fragment cannons and plasma accelerators take no clip leg either: journal captures of a large gimballed cannon at grade 5, of a medium fragment cannon at grade 4 and of a medium plasma accelerator at grade 1, each rolled under this id, report no AmmoClipSize modifier. See data/ships/SOURCES.md § "Multi-cannon Overcharged" for the captures.

The pairing is global, not repeated per menu. A purpose-specific catalogue maps each of the three recipe ids to the colliding id the journal writes. This function supplies the half only a menu knows, by asking which mapped recipe this module is offered. Keeping one global map avoids repeating aliases on every scanner or multi-cannon group and silently forgetting the next one.

Only the module can settle it, which is why this takes one. It resolves into a menu and never out of one: a sensor suite's Sensor_LongRange is already its own menu's id and comes back unchanged, and asking for Scanner_LongRange on a sensor suite returns it unchanged too — unchanged is not the same as offered, and getBlueprintsForModule still says a suite does not take it.

Only the numbers differ, not the price. All three pairs cost the same materials at every grade, so getBlueprintCost from ships/blueprint-costs needs no module and either spelling bills correctly; cross-catalogue tests hold upstream to that. It is the stat block that has to be resolved.

Not a generic-spelling resolver. A generic Misc_* id — Misc_Shielded where a life support's menu says LifeSupport_Shielded — comes back as it went in. That pair is one recipe under two spellings, both published with their own numbers, so the id a caller names is the one to roll. This function exists for the case where the id names no recipe the module has: the game never rolls a sensor suite's Long Range on a scanner.

Parameters

symbol

string

A module symbol, e.g. "Hpt_CloudScanner_Size0_Class5".

fdname

string

A blueprint catalogue or journal id, matched case-insensitively and trimmed. Colliding journal spellings are resolved against symbol.

Returns

string

The id to join to BLUEPRINTS, in that catalogue's spelling when a journal name resolved, and otherwise fdname exactly as it was passed — byte for byte, so a caller who never meets the collision never sees their own spelling rewritten.

Throws

If fdname is not a string, including when it is missing — this returns an id rather than reporting whether one is known, so there is no miss for a nullish one to be. A nullish symbol is a miss: an unknown module offers no menu, and fdname comes back unchanged.

Example

import { resolveBlueprintForModule } from '@elite-dangerous-almanac/core/ships/blueprint-journal';

// A wake scanner's Long Range is the scanner recipe, whichever way the build spells it.
resolveBlueprintForModule('Hpt_CloudScanner_Size0_Class5', 'Sensor_LongRange');
// -> 'Scanner_LongRange'
resolveBlueprintForModule('Hpt_CloudScanner_Size0_Class5', 'Scanner_LongRange');
// -> 'Scanner_LongRange'

// The sensor suite keeps its own, and every other module keeps whatever it was given.
resolveBlueprintForModule('Int_Sensors_Size4_Class5', 'Sensor_LongRange');
// -> 'Sensor_LongRange'
resolveBlueprintForModule('Int_Hyperdrive_Size5_Class5', 'FSD_LongRange');
// -> 'FSD_LongRange'

// A multi-cannon's Overcharged is the multi-cannon recipe, clip penalty and all.
resolveBlueprintForModule('Hpt_MultiCannon_Fixed_Medium', 'Weapon_Overcharged');
// -> 'MC_Overcharged'
resolveBlueprintForModule('Hpt_BeamLaser_Fixed_Small', 'Weapon_Overcharged');
// -> 'Weapon_Overcharged'