Source machine definitions from the PinMAME machine reference

[freezy]

Summary

Machine definitions no longer come from hard-coded C# game classes. The editor loads them from the PinMAME machine reference (pinmame-game-defs), and a table's hardware is populated from the selected machine and ROM. PinMAME also no longer depends on a Visual PinMAME installation: it keeps its data in VPE's own folder and reads ROMs from a configurable ROM folder.

Catalog definitions

• Machine and ROM pickers: the inspector lets you search the catalog for a machine and pick its ROM. The default ROM is the parent ROM, not the alphabetically first one.
• Populate Hardware: fills the switch, coil, lamp and wire mappings from the machine's definition. The candidate lists are kept on the component, so the managers' dropdowns work offline. Changing the machine or ROM refreshes them without touching the mappings.
• Older tables: tables that used the retired game classes keep working through a legacy alias resolver (s_flipper_lower_left, c_game_on, …). Player builds only receive the mappings, never the catalog.
• Catalog to VPE conversion:
  • normally_closed is the physical contact. PinMAME already inverts optos per game (invSw), so only the coin door is passed on as normally closed.
  • The generic lower flipper switches 111–114 follow PinMAME's numbering (odd: EOS, even: button). They take precedence over the matrix flipper switches, which PinMAME only mirrors.
  • Virtual inputs and outputs with a public role are kept, e.g. flipper buttons outside the matrix and synthetic flipper coils. Mirrors and internal state are dropped.

Assignment by position

The catalog's playfield positions are matched against the table's items to link hardware that isn't linked yet. Existing links are kept.

Validated against the Terminator 2 table, starting from empty mappings:

	Matches the table	Different from the table	Left for manual mapping
Lamps	74	0	4
Switches	38	3	2

The remaining switch differences come from disagreements between the catalog and the table, not from the matching itself.

How it matches:

• Items are paired with targets in order of increasing cost. A machine item that isn't modelled on the table therefore doesn't push a neighbour away.
• A match is only rejected as ambiguous when two targets could really swap their items. A slightly offset row of inserts still matches.
• Items at the same position, like a mech's switches, are told apart by name.
• Devices whose positions the catalog marks as conflicted get no playfield positions, and neither do cabinet inputs.
• Spatial assignment is disabled when the mappings were populated for another machine. It also never links a second device to hardware that already has one per position.

Runtime

• Output events: a PinMAME output now drives every mapping row that resolves to it, e.g. coil 19 and the c_game_on alias. Before, only the last row fired.
• Mech switches: a mech switch ID that isn't a PinMAME switch is skipped instead of aborting the mech setup.
• Unresolved mapping IDs: they log a warning at runtime instead of an error that recommends repopulating, which would wipe the mappings.

Data folder and ROM folder

• Data: NVRAM, config and high scores live below VPE's data folder, shared by all VPE apps. A game's state is copied from Visual PinMAME the first time VPE runs it, and also before Create Displays runs the ROM.
• ROMs: they're read from GamelogicPaths.RomFolder:
  • The editor has its own ROM folder setting, saved per machine, which falls back to VPM's ROM folder.
  • A player app can override it for its play session.
• New dependencies: this needs PinMame 1.1.0 and PinMame.Native 3.7.0-beta2 (api: fix SetPath binding and expose folder overrides vpinball/pinmame-dotnet#45, libpinmame: keep PinmameSetPath() paths across PinmameSetConfig() vpinball/pinmame#725).

Dependencies

• GamelogicPaths is on VisualPinball.Engine master. package.json still depends on org.visualpinball.engine.unity 0.0.1-preview.119 and needs the first release that contains it.

Known gaps

• Several issues in the catalog data will be reported to pinmame-game-defs: Terminator 2's 111–114 button/EOS labels, its jet bumpers 42/43, and the meaning of normally_closed.
• Items positioned by drag points or child objects (slingshots, area triggers, drop target banks) are placed at the playfield origin.
• Several lights at one insert, as in VPX-converted tables, are rejected as ambiguous.
• These two will be addressed once the Centaur and Tron tables are ready for validation.

Testing

• Unit tests: 27 pass. The catalog corpus test fails only on X-Men LE's GI on a solenoid, which predates this branch.
• Whole catalog: converting all 793 published definitions before and after shows only the intended changes.
• Terminator 2 in the editor: the game starts, all switches resolve, and the mech registers. The ROM is found through the new folder setup.

[greptile-apps]

Confidence Score: 5/5

[Medium impact] The latest changes appear safe to merge, with all previous findings addressed.

Summary

The PR replaces compiled machine definitions with editor-loaded catalog data and keeps runtime tables on saved mappings.

• The editor turns a selected machine definition into table hardware mappings.
• Catalog positions can fill empty hardware links on the playfield.
• Older table aliases still resolve, and unmapped mech switches are skipped.
• PinMAME stores game state in VPE’s folder and uses configurable ROM folders.
• CI builds the plugin and checks catalog conversions against a pinned corpus.

Diagram

%%{init: {'theme': 'neutral'}}%%
flowchart LR
  Catalog[Machine reference] --> Editor[Editor loads machine and ROM]
  Editor --> Candidates[Saved hardware choices]
  Editor --> Mappings[Table mappings]
  Undo[Undo or Redo] --> Reload[Reload restored selection]
  Reload --> Editor
  Mappings --> Player[Player runs selected ROM]

Loading

_{Reviews (2) · Last reviewed commit: "editor: Address review findings on the P..." · Reviewed by Greptile}