Screens and layout

You tell vPinOps where your playfield, backglass and DMD live. It writes the settings Visual Pinball reads — per table, immediately before it launches — so every table in your library comes up the same way.

DMD is a screen. Score view is one of the things you can put on it.

vPinOps names the four surfaces after the physical screens a cabinet has: playfield, backglass, DMD and topper. That is what you are placing here.

What plays on the DMD screen is a separate choice, made per table, and it is where Visual Pinball’s own vocabulary appears: its plain dots are called the score view ([ScoreView] in the ini), and it is only one of the options — the backglass’s own DMD artwork is another. So DMD is where, score view is what, and on a two-screen cab the score can be drawn into the backglass with no DMD screen involved at all.

Three shapes people actually run

All three work today. Pick the one that matches your room, not the one that sounds like the default.

Cabinet

Playfield, backglass and DMD on three physical displays, in a cab. The boxes you drag map onto the real machine.

Multi-screen desktop

Two or three monitors on a desk. Same idea as a cab, without the woodwork — the backglass takes a second monitor and the DMD a strip of it, or its own.

Single screen

One monitor. The playfield fills it, and the backglass and DMD are either off or composited. A first-class setup, not a fallback.

Desktop mode is not limited to one screen

Cabinet or desktop is a separate choice from how many monitors you have. Desktop mode drives a backglass on one monitor and the playfield and DMD on another perfectly happily — you do not have to call your desk a cabinet to spread out across it.

How you set them up

There are two ways, and most cabinets only ever need the first.

Pick a monitor — from anywhere

Open Screens in OpsLink. Each surface — playfield, backglass, DMD, topper — has its own card, and each card asks which monitor it lives on. Choose one and that surface fills that screen.

That is the whole job for the common case: one surface per monitor, each filling it. You can do it from your phone, standing at the cabinet or sitting somewhere else, which matters because a cab has no keyboard and its own screen may be sideways or showing a broken layout when you most need to fix it.

Draw the box — at the machine

Some layouts need an exact rectangle rather than a whole screen: a DMD strip along the top of the backglass monitor, or a scaled-down cabinet on one desktop display. For those, open the screen designer on the machine itself and drag real windows to where you want them.

It has to be done there, and that is not a limitation we chose — you cannot drag a box onto a display you are not looking at. Everything else about screens can be done remotely.

Note

Both routes write the same stored layout, so they cannot disagree. Pick a monitor and the box is set for you; open the designer afterwards and you are adjusting that same box.

Per table, not just globally

A global layout covers the whole library, and most tables need nothing more. But some tables want a different arrangement, and Visual Pinball supports per-table settings — so vPinOps writes the keys for the table you are launching, at the moment you launch it, rather than making you keep one global compromise.

Note

vPinOps does not write VPinballX.ini until you launch a table. Up to that point your Visual Pinball settings are exactly as you left them.

Visual Pinball’s own settings — which are yours, and which are ours

A few things live in Visual Pinball’s VPinballX.ini rather than in vPinOps, and the split matters: hand-set one of ours and you will watch it change back.

Turn the plugins on — this is the one that costs you a backglass

Visual Pinball ships its plugins switched off. Nothing warns you. The table plays, and the backglass and DMD simply never appear — which reads like a vPinOps fault and is not one.

you want	turn on
A backglass	B2SLegacy
A DMD	ScoreView, plus FlexDMD or AlphaDMD depending on the table
A ROM to load at all	PinMAME

Turn them on in Visual Pinball’s own Live UI, or set Enable = 1 under each [Plugin.*] section of VPinballX.ini.

Enable B2SLegacy, not B2S

There are two backglass plugins with nearly the same name and different key names for the same ideas. Every backglass and DMD setting vPinOps writes goes into [Plugin.B2SLegacy]. Enable the other one and you get a backglass that ignores everything you set here — which is a far more confusing failure than having no backglass at all.

Never leave RefreshRate blank

Put your display’s real rate in [Player] RefreshRate — 60, or whatever your screen runs at.

Blank is not “use the default”. Visual Pinball asks the driver for rate 0, fails to find a display mode, fails to build its sync device, and raises an error dialog you cannot see, because the full-screen shields are drawn over it. What you get is a black screen or an app that looks frozen, and nothing anywhere says why.

What vPinOps writes, so you do not

Leave these alone in the ini. vPinOps writes them immediately before a table launches, so an edit you make by hand is overwritten with nothing said.

• Where each surface goes, how big it is, and which display it is on — the boxes you drag
• PlayfieldFullScreen, BackglassFullScreen, ScoreViewFullScreen and TopperFullScreen — always 0, so the box you drew is the one Visual Pinball honours
• BGSet, the cabinet-versus-desktop view mode — that follows the mode you pick in Settings
• Table and music volume, the backglass and DMD overlay settings under [Plugin.B2SLegacy], and whether the grill is hidden — these are written only when you have set them; leave them alone in vPinOps and whatever you chose in Visual Pinball’s own F12 stays put

Which settings you should not hand-edit — and where to set them instead

The two sections above send you into VPinballX.ini on purpose: RefreshRate and the plugin switches are genuinely yours and vPinOps never touches them.

The settings below are different. vPinOps writes them into the ini itself, immediately before a table launches, because that is the only way a whole library ends up consistent. Hand-set one and it reverts on your next launch with nothing said — which reads as vPinOps breaking something, when it is vPinOps doing its job.

set it here, not in the ini	the keys this writes
Screens in OpsLink, or the screen designer	PlayfieldWndX/Y, Width, Height and the same four for Backglass, ScoreView and Topper — the boxes you drag; plus …FullScreen (always 0) and …Display, which names the monitor
Cabinet or desktop, in Settings	BGSet, and ViewCabRotation when you are in cabinet mode
The table’s own page in OpsLink	ScoreViewOutput and the Priority.* order — what wins the DMD screen
The table’s own page in OpsLink	BackglassDMDOverlay / AutoPos and ScoreViewDMDOverlay / AutoPos — where the DMD is drawn
The table’s own page, or the global default in Settings	B2SHideGrill — the backglass grill
Settings	MusicVolume and SoundVolume

⚠ The difference is worth knowing, because it is the whole rule: the first two rows describe your cabinet — what you play on and where your screens are — so vPinOps rewrites them on every launch and nothing else would keep a mixed library straight. The rest are per-table choices, and vPinOps writes those only once you have made one. Leave a table’s setting alone in vPinOps and whatever you chose in Visual Pinball’s own F12 stays exactly as it is.

When a window lands in the wrong place

The run log says whether vPinOps configured that launch at all:

layout -> Guns N' Roses: Written (1 global, 0 per-table, dmd=Unknown)

Written means it configured this launch; UpToDate means what it wanted was already correct. ⚠ Neither the positions nor your DMD choice are logged — dmd= is which kind of DMD window this table has been seen to open before, not a setting. So this tells you whether we wrote at all, and not where anything was sent. Read last-run.log first; the path is on your platform’s install page.

More, including what to check in what order: the backglass or DMD is in the wrong place.