preble / jd-pyprocgame Goto Github PK

For the "Balls Played" audit, the last ball is counted twice, once in highscore_entry_finished() and again later in end_ball()
highscore_entry_finished() does not need to deal with the end of ball audits.

For the "Avg Score" audit, the value is incorrect because the number of games must be incremented after the new score is incorporated into the average. The function calc_number_average() knows the average must be computed with count + 1.

For the "Games Played" audit, we always increment by one, but we need to increment by the number of players.
In fact, for each player, we should incorporate the score in the average and then increment by 1.

crimescences and multiball modes are removed when starting ultimate challenge.
crimescences and multiball modes are never added back to the mode queue after ultimate challenge ends.

The number of completed shots displayed is wrong if BattleTank is played twice within the same ball. The number of shots is initialized to zero when the mode is created at the start of the ball, but it is never cleared afterwards causing the count to just keep growing. This also silences the voice callouts because the sound file is not found. Luckily, the mode can still be completed normally because the completion depends on a set of 3 boolean flags which are correctly initialized.

The solution is to set self.num_shots to 0 in mode_started() instead of the constructor.

When starting service mode from attract mode, these other modes are still running:
Trough, Deadworld, BallSearch, BallSave, FlipperWorkaround, Attract, ScoreDisplay

When starting service mode from a started game with the ball in the shooter lane, these other modes are still running:
Tilt, ModesAnimation, ModesDisplay, Trough, Deadworld, Replay, Crimescences, Multiball, ballSearch, JD_Modes, BasicDropTargetBank, BallSave, FlipperWorkaround, BaseGameMode, ScoreDisplay

Boring will also be present if start service mode with a ball in play
and you get taunted with "this is boring" callouts in the service menu.

The outer loop champ score is always one less than it should because jd_modes.sw_leftRollover_active() checks if the current streak beats the previous best streak before it increments the number of loops.

In jd_modes.sw_topRightOpto_active() a very similar algorithm for inner loops is implemented correctly. In that method, the number of inner loops is incremented before it is compared to the best streak.

In Missile_Award_Mode, the variable swards_remaining is a typo
self.swards_remaining = self.awards
Also, the value assigned should be a copy of the awards to keep every player independent.
This is the correct statement:
self.awards_remaining = self.awards[:]
This bug will manifest itself only for player 2 to 4.

The message should say Replay only when the replay award is set to Credit in the game settings.

Missing license file

The rule sheet describes the Blackout this way:
GI turns off. Left center ramp is lit with Blackout flasher flashing. If ramp is hit once, it re-‐lights for a double award (2x Blackout flasher also flashes). The double award is required for mode completion.

The current implementation does:
For easy and medium difficulty, the required number of shots is 1, for hard difficulty the required number of shots is 2.
Every shot awards 10000. First shot always marks the mode completed successfully, turns on the 2x flasher and keeps the mode going. Making the required number of shots awards 50000 and keeps the 2x flasher and keeps the mode going. Shots beyond the required number of shots only award the regular 10000 nothing more. The mode ends when the timer reaches 0 and never earlier.

A more coherent implementation would do:
For easy and medium difficulty, the required number of shots is 2, for hard difficulty the required number of shots is 3.
Every shot awards 10000. Completing the required number of shots minus 1 awards 50000 and turns on the 2x flasher. The shot after that gives the regular 10000 plus 110000, marks the mode completed successfully and ends the mode.

In JD_Modes, self.hold_bonus_x remains True forever after that award is awarded once.
All subsequent balls irrespective of the player will also hold the bonus.
The bonus_x itself is correctly handled across players.
The bug will cause each player to hold their own independent bonus_x.

Sniper mode registers a delayed task in its constructor. This delayed task reschedules itself forever. The task is never cancelled because delayed_cancel() is called with the wrong name.

This bug is not very apparent because delayed tasks are not running when the mode is not present in the ModeQueue.

The fix is to register the delayed handler in mode_started() and cancel the handler with the right name in mode_stopped().

A chain mode completed successfully will always be considered successful if played again within the same ball. To reproduce, you have to finish ultimate challenge to make the modes available again.

This happens because the completed flag of a chain mode is initialized in the constructor instead of mode_started().

The rule sheet says: if missile award is lit when multiball starts, missile award is disabled but it is remembered and it relights automatically after the last concurrent multiball ends. This works, but afterwards, every chain mode ending incorrectly relights the missile award. This defect continues until the ball ends or another multiball is started with missile award already turned off.

This happens because the flag missile_award_lit_save is not cleared when relighting missile award.

The game is not completely reset after service mode to take into account the new settings.
The reset method does not reinitialize everything we need to recreate.

save_settings calls itself with the wrong number of arguments. It should call super instead.

	def save_settings(self):
		self.save_settings(settings_path)

should be

	def save_settings(self):
		super(JDGame, self).save_settings(settings_path)    

The end of ball bonus only accounts for the attempted and completed modes within the current chain, ignoring chain modes completed before the last ultimate challenge.

The bonus should use the existing variable num_modes_completed which holds the correct number of modes before or after ultimate challenge. Another variable num_modes_attempted should be implemented and saved in the record_info to count the number of attempted modes.

When the 'Chain feature difficulty' is medium the number of shots required for Meltdown is 5.
This produces a valid sequence of callouts as the switches are hit:
0 -> "power towers going critical.wav"
1 -> "reactor 1 stabilized.wav"
2 -> "reactor 2 stabilized.wav"
3 -> "reactor 3 stabilized.wav"
4 -> "reactor 4 stabilized.wav"
5 -> "all reactors stabilized.wav"

When the 'Chain feature difficulty' is easy the number of shots required for Meltdown is 3.
This produces a sequence of callouts that never announces the end of the mode:
0 -> "power towers going critical.wav"
1 -> "reactor 1 stabilized.wav"
2 -> "reactor 2 stabilized.wav"
3 -> "reactor 3 stabilized.wav"
The last callout should be "all reactors stabilized.wav"

When the 'Chain feature difficulty' is hard the number of shots required for Meltdown is 7.
This produces a sequence of callouts that announces the end of the mode prematurely:
0 -> "power towers going critical.wav"
1 -> "reactor 1 stabilized.wav"
2 -> "reactor 2 stabilized.wav"
3 -> "reactor 3 stabilized.wav"
4 -> "reactor 4 stabilized.wav"
5 -> "all reactors stabilized.wav"
6 -> "all reactors stabilized.wav"
7 -> "all reactors stabilized.wav"

There are no callouts for 5 or 6 reactors.
The easiest way to deal with the missing sound files is to change the number of shots required
easy -> 3
medium -> 4
hard -> 5

JD-pyprocgame was modified at some point to access assets using an absolute path computed from the location of the running class. This makes it relative to where JD-pyprocgame is stored in the file system.

Some locations were missed and still access assets with the relative path "./games/jd/...". This assumes the game was launched from a directory higher in the file system. The code should be modified to use absolute paths like the other assets. After the change will be able to launch JD-pyprocgame from its own installation directory. This change is backwards compatible.

JD-pyprocgame makes an assumption where pyprocgame is located relative to the current directory and modifies the sys.path accordingly. This code should be removed to rely on the sys.path being configured properly. This change is not backwards compatible, but is required to safely launch from its own installation directory. Look for comments similar to this:
sys.path.append(sys.path[0]+'/../..') # Set the path so we can find procgame. We are assuming (stupidly?) that the first member is our directory.

Globe spins clockwise and drops ball.