MegaMek / MegaMek/mm-data

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

Open
#331 0 comments 0 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

Dominant language
Module Management System
Stars
3
Forks
72
Avg merge
11h 8m
Merged PRs (30d)
36

Description

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:

  • mm-data #328 — original faction data audit (this issue is a follow-up surfaced during that review)
  • mm-data PR #330 — the audit PR currently in flight; tagged CLAN.HW/CLAN.IS/BAN.HW/BAN.IS as SPECIAL for the same conceptual reason
  • MekHQ #8936 — the broader "Faction registry conflates non-state entities" code-side issue

Contributor guide

No contributing guide indexed for this repository

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

Research direction

Start by auditing the YAML entries under data/universe/commands/, separating military formations from the listed Periphery regions and SPECIAL umbrella aggregates. Then inspect MegaMek's FactionTag definition and MekHQ's CustomizePersonDialog.getFactionsComboBoxModel(...) to trace how tags reach origin pickers. Done means the applicable command files are tagged and the origin picker no longer shows those unit names after the data and code changes are integrated.

Written by the indexing model from the issue text.

Assessment

Tech stack
yaml
Domain
data
Issue type
Feature
Difficulty
5/5
Estimated time
Over a week
Activity status
Quiet
Clarity
Mostly clear
Newbie friendliness
45/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.