ROMs, nvram and high scores

Tables that emulate a real machine need a ROM — a .zip under your PinMAME roms/ folder. Leave it zipped. Unzipping it is the commonest way to break a good ROM.

Both places work

<your shared PinMAME folder>/roms/f14_l1.zip     ← used by every table with no folder of its own
<table folder>/pinmame/roms/f14_l1.zip           ← this table only, and it WINS over the shared one

The second is exactly what a .vpxz package ships, which is why import never strips it out.

An EMPTY pinmame/ folder breaks the table

The moment a table has pinmame/roms/, Visual Pinball stops consulting your shared ROM folder for that table. Create the structure without putting the ROM in it and the table can no longer find a ROM it could find before.

A pinmame/roms/ with the ROM in it is fine. An empty one is worse than nothing. This is why vPinOps creates medias/ on import and never pinmame/.

Does this work on my platform?

Both paths are Visual Pinball’s own, not ours, and the per-table one is checked first on every platform — it carries no platform condition in Visual Pinball’s source at all.

	per-table pinmame/	shared PinMAME folder
macOS	✅	✅
Windows	✅	✅
Linux	✅	✅

High scores stick. They live in the nvram file next to whichever ROM folder won, and Visual Pinball writes them when you finish playing. (Driven on Windows and macOS. On Linux the ROM paths are the same code, but the score write-back has not been run end to end.)

You tell Visual Pinball where the shared folder is. vPinOps does not.

This catches people, so it is worth being blunt about.

The PinMAME path in vPinOps Settings is what vPinOps uses to check a table’s ROM exists before launching it, so it can warn you instead of dropping you into a failure. It is not passed to Visual Pinball. Visual Pinball has its own setting for the shared folder, and only you can set it — in its own settings, or by putting the ROM in the table’s pinmame/roms/ where it needs no configuration at all.

On Windows you must do one or the other. If nothing is configured, macOS and Linux fall back to a .pinmame folder in your home directory — Windows has no last-resort default at all and simply reports that the PinMAME path is not defined. So either set the shared folder in Visual Pinball, or give the table its own pinmame/roms/; on Windows, doing neither does not work.

⚠ That home-directory fallback is a last resort, not the shared folder. The shared folder is Visual Pinball’s PinMAMEPath setting, it is explicit, and it works the same on all three platforms — the fallback only fires when you have not set one.

Which to prefer, when both work

The shared folder — for one reason that only shows up later.

Per-table pinmame/ also holds that table’s nvram: the machine’s battery-backed memory, which is where high scores, audits and settings live. Keep two versions of a machine and each keeps its own scores; your grand champion does not follow you to the newer build. If you do not care about that, either place is correct.

When a ROM goes wrong, vPinOps tells you

You do not have to work any of this out by yourself. vPinOps checks a table’s ROM before it launches, so it can warn you instead of dropping you into a black screen — and after a launch it records what happened as that table’s verdict.

When something is wrong you see it in two places: the table is held off the wheel with a reason, and its page in OpsLink shows that reason, the exact files Visual Pinball could not find, and the buttons that fix it.

Two different things go wrong, they look similar, and they need opposite fixes.

1 · The ROM is missing

The table is held and the reason names the ROM and the file to add:

Needs its ROM — f14_l1 would not start. Add f14_l1.zip to your PinMAME roms folder.

1. Get that ROM yourself. vPinOps points at your ROMs and never downloads them.

2. Put the .zip in a folder Visual Pinball reads — still zipped. Either the table’s own pinmame/roms/, or your shared PinMAME roms/ folder. Settings shows you the path.

3. Open the table in OpsLink and press “Forget this verdict”. This step is easy to miss: a held table is deliberately kept off the wheel, so there is no way to launch it and prove you fixed it. That button clears the stored verdict and the table comes back as unchecked.

4. Launch it. A clean play marks it validated and it stays on the wheel.

Tip

If you add the ROM through the table’s own Files section in OpsLink, the verdict is cleared for you and step 3 is unnecessary — vPinOps knows a ROM just arrived for that table.

2 · The ROM is there and the table still dies

Same symptom, completely different cause: the ROM loaded and then the table failed in its own script. Some tables lean on a scripting quirk that behaves differently on Standalone. Clearing the verdict will not help, because nothing is missing.

The community publishes a corrected script for these, and vPinOps will fetch it for you:

1. On the table’s page in OpsLink, press “Look for a compatibility script.”

2. If one exists, press “Apply the compatibility patch.” It is fetched for that one table only — never in bulk, never automatically.

3. Launch it. Visual Pinball picks the script up on its own; there is nothing to switch on.

By hand instead: take the .vbs from vpx-standalone-scripts, name it exactly like the .vpx, and drop it in the same folder — My Table.vpx next to My Table.vbs.

This is supplying a piece the table is missing, not editing somebody’s table. vPinOps never edits a table either — it points at what you have.

nvram on import

A packaged table carries its pinmame/nvram/ with it, and vPinOps imports it — that is part of what makes a table portable. Send your own table from one machine to another and your scores travel with it.

The one moment you are asked is an overwrite: if that table already has an nvram here, vPinOps says so before replacing it, because that is the only point at which you can lose scores you actually earned. Nothing there already, and it simply comes across.

⚠ The flip side is that a .vpxz you downloaded from somebody else carries their scores, and that is deliberate — the package is imported as it was built. A ROM table with no nvram at all has to be launched, cancelled so PinMAME can build one, and relaunched before you can play a ball, so throwing the packaged one away would hand you that dance on every import.

The one place scores are a choice is Replace. Tick Replace tables I already have and a second box appears under it: Keep the high scores I already have, ticked by default. That is the case worth protecting — you are re-installing a table that went wrong, and losing scores you actually earned is destructive where inheriting a stranger’s is merely odd. Untick it to take the package’s instead.