Reusable Fragments

Wiring up a pop bumper takes several separate steps: place it, give it a scoring rule, attach a sound, maybe bind a model. Doing that a second and third time means repeating all of it — and if you later decide the bumper should pay 750 instead of 500, you change it in as many places as you have bumpers.

A fragment captures that wiring once and lets you apply it to another device. Crucially it does not copy the wiring: every device a fragment is applied to joins the same tag, and the scoring rule and sound route are attached to that tag. So a fourth bumper costs nothing to wire, and changing the points changes all four.

A fragment is wiring only — no shape and no position. Applying one never moves a device or changes its size. Geometry stays where you put it.

What a fragment holds

Part	Shared or per-device
Scoring rule (points, condition, emitted event)	Shared through the tag
Synth voice or audio clip	Shared through the tag
Mix channels the sound lands on	Shared through the tag
Model or texture	Per device — art attaches to one mesh

“Shared” is the default and the reason fragments are worth using. You can switch the scoring rule or a sound to per-device when it genuinely has to differ — a bank of drop targets where each one pays differently, for example. The last two rows are not choices: art attaches to one mesh, and a mix destination belongs to the route rather than to any one device, so both are fixed.

A sound can land on more than one mix channel — say a bumper voice going to both sfx and a reverb bus. Each destination is captured as its own row, so you can take one and leave the other, and each keeps its send level.

Making one

Compose one device the way you want it — scoring, sound, art — then right-click it and choose Capture fragment…. You can select several devices first, in which case the menu offers Capture fragment from 3 devices… and the fragment describes what they have in common.

Showcade looks at what is attached and shows you a list before saving anything. Give the fragment a name and a tag, then tick what should travel with it. Most rows start ticked; anything showcade is not confident about — see the next section — starts unticked on purpose.

Read the trigger warning

One row on that screen deserves attention. Scoring rules can be triggered three different ways, and they are not equally portable:

Trigger	Fires for	In a fragment
`device.bumper_003.hit`	that one device	Fine — its points are captured; the original rule is left alone
`tag.pop_bumpers.hit`	every device carrying the tag	The shape fragments want
`device.bumper.hit`	every bumper on the table	Usually not what you meant

Note the middle row carefully: a group is addressed as tag.<name>, not as device.<name>. Those are two separate namespaces — a rule written as device.pop_bumpers.hit looks right and fires for nothing at all, because the device namespace only ever reaches a device’s own name or its kind. Fragments always write the tag. form.

The third row is the trap. A rule triggered on the kind fires for every device of that kind, so capturing it into a fragment quietly carries the whole table’s bumper scoring with it. Showcade flags this, tells you how many devices beyond your selection the rule reaches, and leaves the row unticked — you have to opt in. It also offers to re-point that rule at the fragment’s tag instead, and tells you which devices will stop being covered if you accept.

Accepting that offer changes your table straight away — it is the one thing capturing a fragment does beyond writing a file. Everything else on this screen only affects what gets saved.

Applying one

Select one or more devices, right-click, and choose Apply fragment… (or Apply fragment to 3 devices… for a multi-selection), then pick the fragment from the browser that opens.

Each selected device joins the fragment’s tag, and the shared rule and route pick it up from there. Per-device parts, like a model, are applied to each device individually. Applying to a second device costs one tag membership and nothing else — it inherits the rule the first apply created.

Four things are worth knowing about what happens next.

Devices you placed yourself get declared. A device you added from the toolbox is known to the renderer but not yet to the engine, so it cannot carry a tag. Applying a fragment declares it — by name and type only. Its position and size stay where they are and never move into your table’s configuration.

Missing pieces are reported, not guessed. If the fragment refers to a synth patch or clip this table does not have, the parts that can apply still do, and the rest are named so you know what to add — a status line reading “3 of 4 applied” followed by the first thing that went wrong, rather than a silent partial result.

A tag that already exists is not overwritten. If the fragment’s tag is already on this table with different wiring, showcade shows you the difference and lets you join it anyway, use a differently-named tag, or cancel. If the wiring is identical it just joins, with no question asked — which is the normal case when you apply the same fragment to a fourth bumper.

The game restarts. Scoring rules are compiled when the table is built, so a freshly applied rule does not pay out until showcade rebuilds the machine. It does that once at the end of the apply, which restarts the game and resets the score. That is expected, and it is the same cost the rules editor’s apply pays.

Changing your mind

Right-click a device that has a fragment applied and choose Remove fragment “tag” — the row names the tag, and there is one row per fragment the selection carries. A device with no fragment on it is not offered the row at all.

Removing undoes that application, not just this one device: if you applied the fragment to four bumpers, all four leave the tag. Per-device parts come off with them.

Anything showcade cannot still verify it created is deliberately left alone, and it says so. A rule that has been edited since, an entity another fragment also claims, or one that has already been removed by hand all stay put — removal acts only on what it can confirm is still its own doing.

Undo does not cover this. Applying or removing a fragment changes your table’s configuration, not just the scene, so it is outside the object editor’s undo history. Use Remove fragment to reverse an apply rather than Ctrl-Z.

Fragments and assemblies

A fragment carries wiring and is applied to devices that already exist. An assembly additionally carries the devices themselves and their positions relative to each other, so you can drag a pre-wired group out of the asset drawer and place it. Assemblies build on fragments and are covered separately.