Swapped the last two parameters to Sam & Max iMUSE command 257. This fixes

bug #1202071 and probably (it's much less obvious) bug #888248 as well.

Since these parameters are both zero in all other known uses of this
particular iMUSE command, it doesn't affect anything else.

I don't know if it's correct, or if it sounds like in the original, but it
sounds good to me.

svn-id: r18284

1 files changed, 28 insertions, 3 deletions

diff --git a/scumm/imuse.cpp b/scumm/imuse.cpp
index 648e585170..fa46a5eba7 100644
--- a/scumm/imuse.cpp
+++ b/scumm/imuse.cpp
@@ -847,9 +847,34 @@ int32 IMuseInternal::doCommand(int numargs, int a[]) {
 				return player->getParam(a[2], a[3]);
 			}
 		case 1:
-			if (g_scumm->_gameId == GID_SAMNMAX)
-				player->jump(a[3] - 1, (a[4] - 1) * 4 + a[5], ((a[6] * player->getTicksPerBeat()) >> 2) + a[7]);
-			else
+			if (g_scumm->_gameId == GID_SAMNMAX) {
+				// FIXME: Could someone verify this?
+				//
+				// This jump instruction is known to be used in
+				// the following cases:
+				//
+				// 1) Going anywhere on the USA map
+				// 2) Winning the Wak-A-Rat game
+				// 3) Losing or quitting the Wak-A-Rat game
+				// 4) Conroy hitting Max with a golf club
+				//
+				// For all these cases the position parameters
+				// are always the same: 2, 1, 0, 0.
+				//
+				// 5) When leaving the bigfoot party. The
+				//    position parameters are: 3, 4, 300, 0
+				// 6) At Frog Rock, when the UFO appears. The
+				//    position parameters are: 10, 4, 400, 1
+				//
+				// The last two cases used to be buggy, so I
+				// have made a change to how the last two
+				// position parameters are handled. I still do
+				// not know if it's correct, but it sounds
+				// good to me at least.
+
+				debug(0, "doCommand(%d [%d/%d], %d, %d, %d, %d, %d, %d, %d)", a[0], param, cmd, a[1], a[2], a[3], a[4], a[5], a[6], a[7]);
+				player->jump(a[3] - 1, (a[4] - 1) * 4 + a[5], a[6] + ((a[7] * player->getTicksPerBeat()) >> 2));
+			} else
 				player->setPriority(a[2]);
 			return 0;
 		case 2: