[#266] Tags for fuel nozzles and mining lasers - #280
Conversation
Stealrull
changed the title
Stealrull
added
Enhancement
|
@claude review |
Osiris-DevWorks
left a comment
Osiris-DevWorks
left a comment
There was a problem hiding this comment.
The feature itself is correct and respects the invariants: fuel nozzles get a Type-only [FN] tag and mining lasers a Type+Size tag, both gated on the existing Components → Type toggle and wired into Blueprint Tracker bullet matching. Importantly the DataForge coverage invariant is satisfied, not violated — enhancements_bare_type_tags reads only loc/base.ini (exempt, like medical consumables) and mining-laser tagging rides the existing weapons subtree walk, so no new CATEGORY_SUBTREES / DATAFORGE_KEEP_SUBPATHS entry is needed. Test coverage is present. Two things before merge:
Scope / description
The PR checklist ticks "scoped to one concern," but the diff carries the whole 2.2.1 bug-fix bundle (#251/#261/#255/#267/#273/#281) beyond #266 — your own added test-plan section even names it. That work is now on release via #289, so please rebase onto the current tip; the diff should collapse to just the fuel-nozzle/mining-laser tagging.
Re-verify against the now-merged #290
#290 merged and edits blueprint_meta.py mining-laser handling (the Mining_Head → "Other" carve-out). Your PR also touches mining-laser classification/aliasing there. There's no textual conflict against the current tip, but after rebasing please confirm no double-classification/double-tagging of the mining heads and that the aliases still resolve.
Minor: test_plan.py section title says "2.2.1 bug-fix bundle" while the branch is 2.3.0; and generate_enhancements_ini.py's build_scitem_lookups computes is_mining_laser then re-runs the same _find in _mining_laser_component_tag (cheap, but redundant).
Generated by Claude Code
Fuel nozzles carry no Size:/Class:/Grade: of their own, so the existing component tagger could never produce a tag for them; adds a dedicated base.ini-only pass keyed by loc-key prefix that forces the Type element on. Mining lasers live in ships/weapons/ and have a real Size but no damage breakdown, so the ship-weapon name-tag factory skipped them outright; they now fall back to the same component Type+Size shape instead of going untagged. Both respect the user's configured Tag Builder styles (short/medium/long) rather than using a fixed string.
…siris-DevWorks#266) Both were force-showing their tag regardless of the user's Type element setting, since Type is disabled by default and neither item has any other tag source. Reworked so they respect the same enabled/disabled toggle as every other DEFAULT_COMPONENT_TYPE_MAPPING entry (Shield Generator, Cooler, ...) -- opt-in via the Tag Builder UI, not force-shown. Mining laser's Size also now rides along only if the user's Size element is itself enabled, instead of always being forced on.
…ix (Osiris-DevWorks#266) Fuel nozzles ship under at least two different loc-key naming conventions per manufacturer -- item_fuelnozzle_MISC_Standard_* for MISC's RN-7s, but Nozzle_FuelGiver_GRIN_* / Nozzle_FuelGiver_SHIN_* for Greycat's and Shubin's nozzles. Matching only the item_fuelnozzle_ prefix silently skipped every Nozzle_FuelGiver_* entry ("only some fuel nozzles worked"). Detection now reads the paired _Desc entry's own "Item Type: Fuel Nozzle" line instead, which every manufacturer's description carries regardless of key naming.
…is-DevWorks#266) The Blueprint Tracker's tagged_name is read straight from whatever item_Name/vehicle_Name value is loaded, joined by normalized item name. Fuel nozzles and mining lasers don't follow that item_Name<code>/ vehicle_Name key convention at all (manufacturer-specific item_fuelnozzle_*/Nozzle_FuelGiver_* prefixes for nozzles, a bare size-coded key with no _Name marker for mining lasers), so Pass 1 never recognised their key as a Name entry -- tagged_name silently fell back to the untagged bare name even though the enhancement generator's output (and the String Editor) had the real tag correctly applied.
…, not just item names Two independent tag-weaving paths exist: enhancements_bare_type_tags/ _ship_weapon_name_tag_factory tag an item's OWN item_Name (what shows in the String Editor and a ship's loadout screen), while build_scitem_lookups' entity_name_tags feeds build_blueprint_pool_lookup, which weaves the same tag into a mission's POTENTIAL BLUEPRINTS bullet list -- the text a player actually reads before accepting a contract. Only the first path was updated for Osiris-DevWorks#266, so Fuel Nozzle, Scraper Module, and ship-mounted Mining Laser tags never appeared in-game despite showing correctly in the app. Root cause was structural, not a missed case: Fuel Nozzle/Scraper Module have no Size:/Grade:/Class:, so _component_name_tag always returned None for them regardless of UUID resolution; Mining Laser lives under a "weapons" parent dir that's unconditionally excluded (guard from Osiris-DevWorks#220, to keep combat weapons from picking up nonsense component-style tags). Extracts _build_mining_laser_tag_cfg/_mining_laser_component_tag (shared with _ship_weapon_name_tag_factory) and _bare_type_tag_from_desc (shared with enhancements_bare_type_tags) so both tagging paths render from the same logic and can't drift apart, then wires a Mining Laser carve-out into the weapons-dir exclusion and a bare-type fallback into the non-weapons branch.
… tier Live report: fuel nozzle mission text shows correct names (Bendix, Ezra, Harkin, Lindstrom, Marlin, Norfield, RN-7s, Torrez -- the Osiris-DevWorks#281 fix working) but is missing the [FN] tag, even though the tag shows correctly in Smart Citizen's own String Editor/Tag Builder. Ours, not CIG's -- a direct consequence of the same Osiris-DevWorks#281 root cause. entity_name_tags is built from an entity's __ref + Description alone (build_scitem_lookups), independent of whether its Name attribute ever resolved -- so a fuel nozzle can miss both tier-1 (UUID) and tier-2 (filename) name resolution, landing on the tier-3 filename fallback, while still having a perfectly valid tag entry sitting in entity_name_tags. The old code only ever checked that dict inside the tier-1 branch on the assumption that a tier-1 miss meant no tag data either -- true for most components, false for bare-type ones whose tag derivation never depended on Name resolution. Moved the tag lookup outside the tier branching so it applies to whichever tier supplied the name.
…ris-DevWorks#266) Second half of the missing-[Fuel Nozzle]-in-mission-text fix. The first attempt moved the entity_name_tags lookup outside the tier branching, but that dict is keyed by entity __ref -- and for fuel nozzles the blueprint's entityClass UUID doesn't link to any scanned entity at all (the same broken linkage behind Osiris-DevWorks#281's garbled names), so no amount of tier reshuffling can find a tag that was never derivable from entity XML in the first place. The String Editor tags these items fine because its path (enhancements_bare_type_tags) derives the tag purely from base.ini Name/Desc pairs, no entity XML involved. New bare_type_name_tag_lookup reshapes that same derivation as display-name -> tag, and build_blueprint_pool_lookup falls back to it whenever the UUID-keyed tag lookup misses -- so a tier-3 alias name like "Norfield" finally gets its [FN] in the generated mission text, matching what the app shows. Gated on the same Components > Type toggle and the same annotate-mission-descs setting as every other tag path. Also bumps blueprint_pools' _LOOKUP_VERSIONS to v13: the pools bake tags in and are cached against the DataForge fingerprint + tag config, neither of which changes on a code-only fix -- without the bump, a regen against an unchanged extraction reuses stale pre-fix pools and the mission text stays untagged (exactly what the live re-test hit).
…ase/2.3.0 tip Collapsed the diff to just the tagging feature per review feedback -- the original branch carried the whole 2.2.1 bug-fix bundle plus a Scraper Module tag that was added then retired within the same branch (net zero, so both were dropped rather than replayed and reverted) and a duplicate of the already-merged Osiris-DevWorks#281 fuel-nozzle-name fix (patch-id matches 70fba73/7d5eb82, both on release via Osiris-DevWorks#283 already). Fixed a conflict-resolution slip during the rebase: an early pass at resolving the src/utils/blueprint_meta.py conflict on _EXTRA_NAME_KEY_PREFIXES accidentally dropped three unrelated definitions that happened to sit inside the same HEAD-side conflict hunk (MANUAL_BLUEPRINT_ITEMS, _key_slug, _BULLET_NAME_ALIASES) -- caught immediately by the resulting NameErrors in tests/test_blueprint_meta.py, restored verbatim from tip. Re-verified against Osiris-DevWorks#290's mining-head classification carve-out (item_NameMining_Head_S00_* -> "Other", not "Ship Weapon"): this PR's Type+Size mining-laser tag operates on a different entity shape (SEntityComponentMiningLaserParams, ship-mounted weapon slot) than Osiris-DevWorks#290's Mining_Head loc-key carve-out (mining tool heads), and test_blueprint_type_mining_head_family_not_ship_weapon plus test_build_metadata_mining_head_family_lands_in_other both still pass, so there's no double-classification. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
746fbd1 to
8d5b553
Compare
|
Collapsed the diff down to just the fuel-nozzle/mining-laser tagging feature per the review. The original branch also carried the whole 2.2.1 bug-fix bundle (now already on release via #289), a Scraper Module tag that was added then retired within the same branch's own history (net zero, so both commits were dropped rather than replayed and reverted), and a duplicate of the already-merged #281 fuel-nozzle-name fix (patch-id matches Re-verified against #290's mining-head classification carve-out: this PR's Type+Size mining-laser tag operates on a different entity shape ( Full test suite passes. |
3 participants
Summary
item_fuelnozzle_*,Nozzle_FuelGiver_*,item_mining_mininglaser_*) so a generated tag actually shows up joined to the right blueprint bullet, not just in the String Editor.[SCM]tag originally in this PR was retired per the maintenance-mode direction — scraper module names stay untagged everywhere. A components-config migration strips the stale mapping row from tester configs that already saved it, the lookup cache versions are bumped so a regen can't reuse pickles baked with[SCM]tags, and a negative regression test locks scraper modules out of the bare-type tagging path. The scraper-module ITEM recognition fixes (tier headers, "(Salvage Mod)" annotations) are unchanged.Fix blueprint bullet parsing: reputation-tier sub-headers + category annotations) that the scraper-module item regression test depends on — it's a duplicate of a commit already in [#266] Fix general Blueprint Tracker bullet-matching bugs #278 and will de-duplicate cleanly once that branch merges up to this one.Closes #266.
Testing Checklist
pytest tests/passes locally (full suite 1234 passed on this branch, 16 skipped)python src/main.pytests/release/2.3.0, the active feature branch, notmainCATEGORY_SUBTREESandDATAFORGE_KEEP_SUBPATHSboth updatedTesting performed
Automated: full test suite green on this branch and on the combined local
release/2.3.0integration branch. Manual in-app verification against a real Star Citizen install: fuel nozzle names and mining laser tags confirmed in-game by the user during 2.3.0 test builds; scraper modules verified untagged after the scope cut.🤖 Generated with Claude Code