Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

M4: Orion burger fix for using kibble in test2 and a general sound unload fix #5654

merged 2 commits into from Feb 10, 2024


Copy link

This PR fixes the issue of not playing the correct speech sequence when using the kibble from Wilbur's inventory

It also fixes an issue that was detecting during testing the above fix, whereby some sounds would not play a second time. This was due to the unload() method for sounds being called twice in some cases, which seems unintended.

This was tested in the demo, but it looks like it should be the same case for game proper

It looks like a typo in the assignment of the _G(wilbur_should) global var, made the engine/script only play the first speech cue and then do a different action
(which also used to cause a crash

The game when played in DosBox, plays the speech cues and returns control to the player.

However, as of yet, there are two issues I could find with this speech sequence:
1. Sometimes the "hmmm" idle animation of Wilbur will interfere while the speech cues are playing (in between them I think) and then Wilbur will get stuck (soft lock)
without the engine giving control back to the player. An assumption here is that due to the engine currently not playing the speech animation for Wilbur, which may be could "block"
the idle animation from kicking in(?).
2. The sfx (a "crunch" sound) (600_008) and first speech cue (602w012) when using the kibble only plays the first time. Subsequenct uses do not produce the sfx sound (but the speech plays). On DosBox the sfx plays in subsequent uses.
Copy link
Contributor Author

The second commit in the PR addresses the second of the pending issues mentioned in the first commit.
And, at least in my testing, it seems that it may have fixed the first pending issue as well; although I can't really understand why. I could not reproduce the first pending issue (soft lock due to the "hmmm" sound / idle animation playing in-between the monologue), after the fix for the redundant unload() call.

@dreammaster dreammaster merged commit 7ec6f59 into scummvm:master Feb 10, 2024
8 checks passed
Copy link

Confirmed with the disassembly that it should indeed be 10010

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
None yet
None yet
2 participants