Skip to content

Add COMMAND tag to military-unit entries under data/universe/commands/ #331

@HammerGS

Description

@HammerGS

Problem

The data/universe/commands/ directory contains ~170 files representing military formations within faction structures — e.g. DC.AL (Arkab Legions, Draconis Combine), FS.CrMM (Crucis March Militia, FedSuns), MERC.KH (Kell Hounds), SL.R (Star League Royal), WOB.PM (Protectorate Militia), and one entry per command per parent faction.

These all load into the same Factions2 registry as political-state factions and have no tag distinguishing them from "real" origin choices. As a result, MekHQ's origin-faction pickers treat "Arkab Legions" or "Kell Hounds" as semantically equivalent to "Draconis Combine" or "Mercenary" when asking the user where a character is from.

That's a category error — a person's origin faction should be the political state they're a citizen of, not a specific military unit. Surfaced during mm-data #328 / PR #330 review when looking at why CLAN.HW, CLAN.IS, BAN.HW, BAN.IS (the umbrella aggregates) needed SPECIAL tags.

Example

In MekHQ Customize Person → Origin Faction picker today, every unit-level command appears in the dropdown alongside its parent faction:

Federated Suns [FS]
Crucis March Militia [FS.CrMM]
Davion Light Guards [FS.DLG]    ← unit, not a real origin
Davion Heavy Guards [FS.DHG]    ← unit, not a real origin
... etc

A player is unlikely to want their character's origin faction to be "Davion Heavy Guards" — that's a current-affiliation question, not a birth/citizenship one. The parent FS is the right grain of choice for origin.

Proposed fix

Two-part — data side and code side, ideally landed together:

Data side (this repo)

Add a new COMMAND tag to every entry under data/universe/commands/ that represents a military formation rather than a geographic region or aggregate umbrella. Specifically:

  • Apply COMMAND to all <FactionKey>.<UnitKey> style entries that represent actual military commands (DC., FS., LA., CC., FWL., MERC., WOB., CS., the various Clan unit entries, etc.)
  • Skip the geographic Periphery.* entries (Capellan Marches, Hyades Rim, Marik Expanses, etc.) — those are regional groupings, not military units, and stay as-is
  • Skip the umbrella aggregates already covered by SPECIAL: CLAN.HW, CLAN.IS, BAN.HW, BAN.IS, Periphery.Deep — these get SPECIAL for the same reason and don't need both tags

Estimated scope: ~160-170 yml files under data/universe/commands/.

Code side (MekHQ)

Extend the existing origin-picker HIDDEN/SPECIAL filter to also exclude COMMAND-tagged factions. Specifically CustomizePersonDialog.getFactionsComboBoxModel(...) and any other consumer that calls Factions.getInstance().getFactions() for an origin-style picker.

Two implementation options:

  • Add COMMAND alongside HIDDEN/SPECIAL in the existing skip clause — simplest, narrow change
  • Introduce a positive ORIGIN_ELIGIBLE predicate that returns true only for political-state factions — broader cleanup, aligns with the "origin faction is a strict subset" direction noted on MekHQ #8936

The first option is the minimum viable fix. The second is the longer-term direction.

Implementation notes

  • Schema: just adding to the existing tags: block; no new YAML structure needed
  • The MekHQ Faction parser already reads tags into EnumSet<FactionTag> — adding COMMAND requires one new enum entry on the MegaMek side (megamek.common.universe.FactionTag or wherever the tag enum lives)
  • Easy to scope per-faction: one bulk PR per parent faction (DC.* commands as one PR, FS.* as another, etc.) if reviewers want smaller chunks
  • Verify by loading any save in MekHQ after the data lands, opening Customize Person, and confirming unit names no longer appear in the Origin Faction dropdown

Background

Surfaced 2026-05-03 during mm-data #328 / PR #330 review. Same conceptual gap as MekHQ #8936 (Quick Start company generator nonsense origins) — the Faction registry conflates political states, era-bounded historical states, meta umbrellas, geographic regions, and now military commands without any tag-based way for consumers to distinguish them. SPECIAL/HIDDEN handles the worst offenders; a COMMAND tag closes the gap on the unit-level entries.

Cross-references:

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type
    No fields configured for issues without a type.

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions