MOHAWK: Riven: Prison Island sound puzzle graphics glitch.

[macca8]

This refers to the sound puzzle on Prison Island that releases Catherine, and follows up #10521.

When the player presses a sound button, it should return to the up position when the player either:

• releases the mouse button, or
• moves the cursor away from the button.

This glitch relates to the first case.
If the mouse button is released while the cursor is still hidden, the sound button remains in the down position.
If the mouse button is released after the cursor reappears, the sound button returns to the up position.

This appears to be a timing issue between the mouse button release and the delay while the cursor is hidden, rather than anything to do with the cursor's visibility, since it also existed before the fix in #10521, when the cursor was always visible.

While this can occur in a single click situation, it's generally not obvious unless a sound button requires consecutive clicks.

Fortunately, clicking a sound button in the down position will still register and play the sound, provided the cursor is visible, so it doesn't affect the completion of the puzzle.

Using the attached saved game, choose any button and click & release the mouse in the same action, or perform a standard double-click.

Current Daily Build: 2.1.0git2147-g0aed245 (15 May 2018)
Game Version: English, 5-CD (contains v1.02 patch files)
Platform: Intel Mac (OS X 10.6.8, 10.11.6)

[macca8]

Actual puzzle combination (if required): Middle, Middle, Left, Left, Middle.

[dafioram]

The behavior of the piston staying at the bottom when the user has clicked a music button and not moved away the mouse is identical to the original engine (at least the DVD version) behavior.

But I agree that it would look better if the piston went back up regardless of where the users mouse cursor is pointing.

[bgK]

I wonder why they scripted the button release gfx update on the mouse leave event rather than appending it to the mouse click which would have resulted in the effect you prefer.

[macca8]

Thanks for confirming the glitch, but the responses from both of you suggest that my description of the current behaviour may be unclear, in particular, my use of the terms click (mouse down) and release (mouse up) as related to using the mouse.

It seems that your definition of mouse click is the complete down/up action of the mouse as a single action, whereas I'm treating each component separately.

bgK, I assume the mouse leave event refers to moving the cursor away from the button. If that's the case, then you seem to be under the impression that the button release gfx update isn't currently possible from the mouse click. It actually is, but it's tied to the mouse up component (mouse up event?) of the down/up action of a mouse click.

To clarify this, keeping the cursor over the button, press & hold the mouse down (the cursor will disappear, the button depresses & the sound plays), wait for the cursor to reappear, then release the mouse (the sound button will return to the up position).

The problem is that the down/up action of an uninterrupted complete mouse click currently coincides with the hide & show actions of the cursor, or specifically, the hard coded delay of 500ms that separates the cursor's actions. As long as the mouse up event of the mouse click occurs after this delay, then the sound button will return to the up position.

[bgK]

Thanks for your report, this was fixed in commit 43babaeef8.