Skip to content

Medieval Madness

Williams WPC table (1997). A classic pinball machine featuring castle attacks, trolls, and multiball mayhem.

Build Notes

Starting Version

Medieval Madness VPW build started as a LITE project using the Skitso mod (based on Ninuzzu/Tom Tower) as the definitive base version. Initial approach focused on Fleep sounds and NFozzy physics first, skipping 3D inserts initially in favor of Lampz. The table later escalated to a full Blender Toolkit build.

Multiple other versions existed (Reloaded, Merlin Mod) but Skitso's was considered the starting point.

Playfield Dimensions

Standard dimensions: 20.25" x 46"

Determined by CK's scan at 600 DPI (reported as 300 but actually 600): 12168/600 = 20.28" width. Verified by checking that circles are circular at these dimensions. Bord1947 confirmed 20.25" x 46" from direct measurement.

Key finding: 20.25" width is the universal standard for non-widebody tables. The pinballmakers.com wiki lists some early Williams SS at 20.5" but this is inaccurate - bord1947 confirmed even Space Shuttle is 20.25". Cabinet width has been the same since the 60s; at 20.5" there would be no clearance to lift the playfield.

DPI-based calculation: Divide pixel width by DPI to determine playfield dimensions. Scanner metadata may report incorrect DPI (e.g., 300 when actually 600). Verify by importing to VPX and checking that bumper holes are perfectly circular.

Layer Organization

Complex modded tables accumulate duplicate and hidden objects across multiple mod iterations. MM had primitives inside other primitives, non-collidable/non-visible orphaned objects, and duplicates hiding behind layer limits.

Cleanup approach: 1. Expand to ~20 layers to properly split content 2. Use VPX "Select Element" view to sort by collidable and move to dedicated layers 3. Create separate "blocker walls" layer for invisible physics walls 4. Remove all non-visible, non-collidable orphans 5. Strip all lighting if heading to Blender Toolkit (will be rebuilt)

Flipper Placement

The initial left flipper was flat-out in the wrong position - always verify flipper placement against reference photos.

Scripting

Castle Moat and Tower Ball Handling

MM castle moat works like a subway - everything rolls left and queues at a kicker. The single tower holds a ball in place using a post on a ramp, but ramps don't like static balls sitting on them (ball tends to fall through).

Solution: Use a kicker to catch the ball until the post drops to release it back into play. The whole castle physical area was later rebuilt with a large low-poly collidable castle primitive to simplify collision and reduce edge cases.

Drawbridge Stepper Motor Fix

MM drawbridge uses Controller.GetMech(0) for position sensing, which broke with newer VPinMAME solenoid handling. The drawbridge solenoid callback uses GetMech to determine position (divides by 16, checks if <= 15 or > 15) to set direction.

Fix (from GitHub issue vpinball/pinmame#226): Replace the GetMech-based implementation with HandleMech=0.

Troll Mechanism Requirements

MM trolls require specific scripting constants for fast flips: 

Const cSingleLFlip = 0
Const cSingleRFlip = 0

These must be set under Load VPM. Without them, troll activation causes crashes or erratic behavior because the troll mechanisms use flipper solenoid pairs (each troll has two flipper solenoids that push them up).

Switches: sw45/46 are scoring leaf switches, sw74/75 are microswitches confirming troll-up position. The InRect function is also required or trolls crash the table.

SolCallback Enabled Parameter

SolCallback subs fire twice - once with Enabled=True and once with Enabled=False. If the sub doesn't check the Enabled parameter, the action executes on both calls, causing double sounds, double kicks, etc.

Fix: Always add If Enabled Then guard.

Debugging technique: Add debug.print Enabled to the sub to verify it fires with both True and False. This was the root cause of MM's moat VUK playing a double sound - it was firing the kick and sound on both the enable and disable calls.

3D & Art

Playfield Scan Color Correction

Scanners produce flat/desaturated colors; cell phone cameras auto-boost saturation. Neither is accurate alone.

Best approach: 1. Compare scan against multiple reference photos under different lighting 2. Check videos for reference but account for camera lighting effects 3. Scans need post-processing for black levels and saturation 4. Consider using Pantone color swatches printed at bottom of some playfields for calibration 5. The scan metadata DPI may be wrong - verify against known physical dimensions

Color correction for MM specifically focused on bringing black levels to eye-pleasing without crushing detail. Curating source material is critical - most online images don't transform 1:1 to VPX.

Blender Toolkit Insert Depth

Three approaches for inserts in Blender Toolkit tables:

  1. Flat baked inserts - Simple but look flat especially in VR, lack depth
  2. Flupper/3D inserts in VPX - Best depth and fidelity, but requires manual setup per table; can be added after toolkit bake as a copy-paste task
  3. Toolkit-native 3D inserts - Render insert sides, bottom, and transparent top overlay separately by sculpting the insert bucket into the playfield mesh. Gives nice results but tedious to set up.

For VPX, transparency rendering is "very very basic" which limits insert quality. Flupper inserts sometimes look nicer than real ones. In the toolkit, set Flupper insert models to "Indirect only" so they affect reflections/lighting without being in the output bake meshes.

AI-Assisted 3D Model Generation

AI image-to-3D tools used for complex MM toys (castle and dragon) that are difficult to model from scratch.

Workflow: 1. Gather multiple reference photos from all angles 2. Feed to AI generation app 3. AI models have flaws in detail areas - use them as starting point, not final 4. Manual correction of proportions and details 5. Apply real-machine textures as UV maps

For the dragon: separate body and wing photos from eBay listings gave clean reference without occlusion. For the castle: mix of AI-generated and hand-modeled approaches, with displacement/normal maps added for stone texture roughness.

Troubleshooting

PWM Lamp Fading Too Sharp

MM insert lamps appear to flash too sharply (binary on/off) instead of having incandescent fade characteristics. Niwak investigated: VPinMAME physics model shows the bulb never reaches full temperature during rapid flashing pulses, so it operates in the "underpowered" range where cooling may be modeled too fast.

Mitigation options: 1. Select "Linear" fader in VPX which adds smoothing (but makes lights slightly dimmer as they won't reach full power) 2. Accept the physics model is close to real - camera in PAPA videos may smooth the appearance

The VPX linear insert fading was applied as a middle-ground compromise.

Performance Issues from 4K VLM Bake

MM experienced progressive frame drops during gameplay, especially during flasher-heavy sequences (jackpots, castle destruction).

Analysis: - 2K VLM bake ran smooth; 4K with VR room additions caused jitter - Frame pacing in VPX 10.8 worsens the issue - switch to VSync instead - Frame pacing goes bad when framerate can't be maintained; VSync degrades more gracefully - Colored DMD ROM caused progressive stuttering (memory leak in colorization, not fixable at table level). Standard ROM ran fine. - VPX 10.8.1 BGFX resolved most performance issues

CorTimer Warning

The CorTimer 10ms period triggers a VPX 10.8.1 warning about frame pacing but this is expected for physics timers.

Castle Area Collidable Rebuild

MM castle area is extremely complex physically with multiple entry points, the moat, drawbridge, portcullis gate, and lock mechanism.

Rebuild strategy: 1. Create a single large low-poly collidable castle primitive instead of many small overlapping walls 2. Separate visual and collision meshes - visual castle can be detailed while physics mesh is simplified 3. Reinforce stuck-ball areas with additional blocker walls 4. The Merlin scoop legitimately rejects shots in real life - this was intentionally replicated 5. Two-ball stuck scenarios in the Merlin scoop and moat required specific kicker and trigger placement fixes

Game Knowledge

Flipper Angle Tuning

Technique for flipper angle accuracy: overlay PAPA tournament video frames with VPX table screenshot to compare flipper positions. For MM, initial angles were too flat (too low), making the game too easy with easy catches on moat returns.

After overlay comparison, flipper up-angle raised ~4 degrees and down-angle raised ~5 degrees.

Effects: - Changed the "power point" of flippers - more velocity available at ramp shot angles - Made ball control much harder (realistic hot-potato feel) - Left ramp became backhandable but difficult; right ramp not backhandable (confirmed accurate by machine owner) - Holding flipper up no longer auto-catches moat returns

Real Machine Physics Reference

Real MM machine owner (majordrain) provided critical physics reference:

  • Post passing very easy due to flat flipper angle, but keeping ball on flipper is hard
  • Cannot backhand ramps from a trap on either flipper; rolling backhand up left ramp is low-percentage
  • Moat feed to left flipper is highly variable - sometimes clips sling, sometimes bounces to right sling, rarely catches by just holding flipper up
  • Live catch and dead bounce to right flipper work well
  • Slings should be terrifying and dangerous
  • Game plays harder than it seems

Final physics values: Sling strength 5.1, sling threshold 1.8, playfield friction 0.22, target mass 0.1.

Slingshot Tuning for Difficulty

Final slingshot tuning for MM: strength increased to 5.1, threshold lowered to 1.8, sling correction curve tweaked. Combined with slight playfield friction reduction (0.22), this made slings dangerous enough to keep players on their toes - matching the real machine where slings are "terrifying."

The sling changes also increased SDTM (straight down the middle) drain risk on failed castle gate shots. For tables that play too easy, increasing sling strength is an effective way to add difficulty without making the game feel unfair.

Stand-up target mass was also reduced to 0.1 for more realistic rebound behavior.

Resources

VR Room and Backglass

VR integration for MM: - VR room (mega, minimal, cab) added 35MB in images and 110K polys - Animated VR backglass uses SetBackglass() sub to position elements relative to player - Backglass flasher IDs (17, 18, 19, 20) were mapped from real machine lamp test videos - GI strings 1, 2, 3 drive backglass lighting in B2SDesigner - Day/night slider affects VR element brightness - materials need manual brightness adjustment to counteract darkening - Playfield reflections on BM_Playfield object with adjustable strength enhance VR realism

Testing required across VR headset, cabinet, and standalone configurations before release.

Contributors: sixtoe, apophis79, rothbauerw, o0skitso0o, iaakki, majordrain, tomate80, niwak, brad1x, ebislit, astronasty