Lexy Lightspeed BallPaths

This tech tip examines the BallPaths on the Lexy Lightspeed module.

For the list of BallPaths, see the module definition file in %HOMEDRIVE%%HOMEPATH%\.multimorphic\P3\ModuleDrivers\LL-EE\2.1.0.0\LL-EE.json

For an introduction to BallPaths in general, see the tech tip on Heist BallPaths.

Overview

The initial version of Lexy Lightspeed predates BallPaths. At that time, device capabilities served a similar purpose. See the tech tip describing the ship for a peek at the Lexy Lightspeed device capabilities.

BallPaths were eventually backported to Lexy Lightspeed. For the most part, BallPaths work as expected on this module, though there are important differences when compared to more recent titles:

• There is no BallPath API in Lexy Lightspeed. Instead all BallPaths are active all the time.
• Diverters are controlled through the ship API since there is no way to activate a BallPath. See the previously mentioned tech tip describing the ship for details.
• Some BallPaths might be unreachable at a particular time. The module driver gives little indication which BallPaths are unreachable, making it hard for a module agnostic game to pick a shot randomly.

In the tables below, all BallPath events pass a switch object as the event data unless stated otherwise.

Loop and Ramp BallPaths

There are two missing BallPaths in the module definition file:

• When the ball comes back from the pop area to the left orbit, the Evt_LeftLoopBakwardsHit event is sent.
• When the ball enters the ship with the lower gate closed, the ball is locked and the Evt_BallInSaucer event is sent. The event data is the number of balls currently locked in the ship, including the new locked ball.

The Evt_LeftRampHit event is accompanied by two Evt_LeftRampInc events (one ModeToModes and one ModeToGUI). The event data is how many times that shot was made as an integer. The Evt_LeftRampInc events are not from the module driver, they come from the ShotCounter mode in P3SampleApp. ShotCounter can be removed if desired.

Similarly, the Evt_RightRampHit event is accompanied by two Evt_RightRampInc sent by ShotCounter.

The ShipToRamp BallPath describes a captured ball ejecting from the top. This BallPath is unreachable with a flipper shot. It requires using the ship API (Evt_SaucerEject).

Hole BallPaths

The naming convention is inconsistent for the Hole BallPaths and events.

The StartedEvent and CompletedEvent are the same, though the event is sent only once.

The ShipExitBottom BallPath describes a ball draining below the ship. I wonder if using the existing Evt_SaucerBallDrained event as the CompletedEvent would have made more sense. When the event data for Evt_SaucerBallDrained is true, it means the ball was locked and it went all around the ship at least once before draining. When the event data for Evt_SaucerBallDrained is false, it means the ball has entered the ship and dropped immediately because the lower gate was open. This information is not available in the Evt_ShipExitBottom event.

Target BallPaths

In Lexy Lightspeed, the Started and Completed events for targets are pure switch events. The module driver does not send a ModeToModes event of the same name like Heist does.

Many applications look only for the StartedEvent and ignore the CompletedEvent for targets.      

Do not confuse the “top” targets accompanied by alien silhouettes on the backboard versus the “alien” targets below the mini LCD.

PopBumpers also send events. These events do not appear in the module definition file because Target BallPaths could only use switch events before WAMONH changed the rule. Feel free to use the events instead.

Beware the names for the pop bumper switch and its associated PopHit event are inverted, i.e. popXXX versus Evt_XXXPopHit, where XXX is Bottom, Left or Right.

If you don’t need to distinguish which pop bumper was hit, you can handle the Evt_PopHit event instead.

HomeMode handles the ModeToModes Evt_PopHit event and sends the ModeToGUI event Evt_PopBumperHit. The event data for the Evt_PopBumperHit is a LocationScore object containing a score value (long) and a location (string) which happens to be the pop bumper switch name. This is specific to P3SampleApp. You can change that in your application if desired.

Balls in Play

The SDK makes an effort to keep track of the number of balls in play with the BallsInPlayManager. This is only advisory since the count is never used by the SDK. When the ball starts, the number of balls in play is set to 0. The count is incremented for every successful launch and decremented for every ball draining below the main flippers.

Every time the count changes, BallsInPlayManager sends the Evt_BallsInPlay event where the event data is the number of balls in play.

I mention this now because some Lexy Lightspeed BallPaths also affect the number of balls in play, consequently causing an Evt_BallsInPlay event to be sent.

Ejecting a ball increases the number of balls in play by 1.

Locking a ball in the ship, dropping in the ModeHole or dropping in the PopHole decreases the number of balls in play by 1.

Dropping in the hole below the ship or in the SecretHole does not modify the number of balls in play. This discrepancy makes it hard to keep an accurate count.

The application can try to compensate for this discrepancy by calling the BallsInPlayManager itself. For example, to increase the number of balls in play by one, call:

        BallsInPlayManager.Inc(1);

To decrease the number of balls in play by one, call:

        BallsInPlayManager.Dec(1);

To get the number of balls in play according to BallsInPlayManager, call:

int numBallsInPlay = BallsInPlayManager.GetBallsInPlay();

Maintaining an accurate number of balls in play is important. The true criteria to end a ball is to let the sw_drain_active switch event propagate to HomeMode. For most applications, it might be easier to ignore BallsInPlayManager and keep track of the number of balls in play directly in the multiball mode.