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 difficult for a module-agnostic game to select a shot at random.

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_LeftLoopBackwardsHit 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 newly locked ball.

The ShipToRamp BallPath describes a captured ball being ejected 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, although the event is sent only once.

The ShipExitBottom BallPath describes a ball draining below the ship. Using the existing Evt_SaucerBallDrained event as the CompletedEvent might have been more appropriate. When the event data for Evt_SaucerBallDrained is true, it means the ball was locked and 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 as Heist does.

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

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

Pop bumpers 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. You may use those events instead.

Beware that 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 Evt_PopBumperHit is a LocationScore object containing a score value (long) and a location (string) which is the pop bumper switch name. This is specific to P3SampleApp. You can change that in your application if desired.

Balls in Play

The SDK attempts 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 each ball that drains 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.

This detail is relevant 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 into the ModeHole or dropping into the PopHole decreases the number of balls in play by 1.

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

The application can try to compensate for this discrepancy by calling the BallsInPlayManager directly. 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 criterion for ending 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 track the number of balls in play in multiball, which is what P3SampleApp does in MultiballMode.