Copied from the agreed story (STORY.md) and the rule sheets
(2026-10-07); those two win if this drifts.
The Excursion Funnel (the left ramp, two PVC tubes wound with LED wire) and the Hard Light
Bridge (the right ramp's blue plexiglass fly-over [LED-Bridge]; the CAD's "light bridge rails"
confirm it). Below the bridge, the diverter [Div1] sends the ball into VUK6 and up into the ball
dropper, the Companion Cube dropper. The two ramp optos are a laser relay pair powering the light.
sequence ramp_combo — pinball design research: the standard real-machine use for a symmetric
L/R ramp pair is a sequence block rewarding ramp-to-ramp combos (left ramp -> right ramp within
N seconds), or a repeat-ramp bonus-multiplier build. Still applies regardless of the diverter
finding below - this scores the shot, the diverter controls where the ball goes physically.
See design/research/portal-themes-and-pinball-design.md Part 2.
other right_ramp_diverter — CAD correction (design/research/onshape-cad-findings.md): the
earlier "no diverter hardware" assumption was wrong. The playfield has a real Diverter_Rod +
Diverter_Base + Bridge_Diverter_Cover assembly feeding a Subway tunnel right where the right ramp
bottoms out - this is a genuine routing diverter, not just an entry/exit confirmation pair. MPF
has a native diverters: device type for exactly this. Electrically drafted (2026-08-27):
dv-ramp-diverter (MPF diverters: device, c-ramp-diverter coil) plus
s-subway-entry/s-subway-exit switches (both REMOVED 2026-10-04: the path from the diverter
into the ball dropper has no switches, per the owner) now exist in
hardware-devices.yaml/hardware-coils.yaml/hardware-switches.yaml, DRAFT numbers pending real
board assignment - same status/pattern as the Phase 1 flipper coils (and hit the identical
default_hold_power: 1.0 requirement MPF asserts for any hold-type driver). Boot/logic-tested
against smart_virtual only. Deliberately NOT wired to any game logic
(activate_events/deactivate_events, or a subway-passage shot/score) - what a diverted shot
should actually award or do is a real design question (this is still the sparsest-designed Phase 3
feature per the xlsx), not something a hardware draft should answer unilaterally.
DRAFT, needs a real game-balance pass with the user: 400/hit per ramp (either l1/l2 or r1/r2 switch
counts), +1500 shot_group-complete bonus for hitting both ramps, +1000 for the 2-hit ramp_combo
sequence. Implemented in modes/ramps/config/ramps.yaml. Still does NOT implement any
right_ramp_diverter game logic (routing/subway-passage scoring) - the hardware is now electrically
drafted (see rules notes above) but what it should actually do needs a design pass with the user
first. No combo time window either, same gap as slings/dropbank.
From rule-sheets.md, not built yet: the rules above are what the mode does
today. Counts, timers and scores are drafts for the balance pass.
Lowest-priority Phase 3 feature - board Overviews.xlsx's "Modes" sheet notes are sparsest here
("right ramp", a bare "?" placeholder). Needs a real design pass with the user (what a ramp shot
actually does/awards) before implementation, per the resumption roadmap (CHANGES.md #3). The
diverter/subway isn't a hypothetical wishlist item anymore (as an earlier version of this file
assumed) - it's built into the CAD already; standard real-machine use is alternating L/R routing to
feed a physical ball lock for multiball, which is now a real near-term option once it's wired, not
just a stretch goal. Real dimensions: right ramp bottom ~4.9"x9.6", light bridge rails ~12"-18"
long. See design/research/onshape-cad-findings.md and the schematic artifact linked there.
funnel-exit-post, idea) picks one of twopanel-ramp: one Portal 2 style