MOHAWK: RIVEN: Pause action doesn’t reset when Space Bar pressed to resume game.

[macca8]

If the game is paused by pressing the Space Bar, pressing it again to resume the game (instead of selecting any other key) will resume the game, but can make the Space Bar unresponsive to further pauses. The Pause dialog will flicker, but not stick.

As far as macOS is concerned, this behaviour appears restricted to the 32bit build (the 64bit build always displays the Pause message).

The easy way to test if your system is affected is to press the Space Bar at least three consecutive times (the Pause dialog should flicker by the third press). If it’s not affected, then you won’t see any of the following F5 issues.

Current Daily Build: 2.2.0git4276-g8347638ea6 (9 April 2020) - 32bit version
Game Version: English, 5-CD (contains v1.02 patch files)
Platform: Intel Mac (OS X 10.6.8, 10.11.6)

Fortunately, any other unassigned single key press immediately resets the Space Bar to its designated Pause function (including modifier keys forming part of other designated functions, such as Ctrl+F5 & Cmd+q), so it’s never been a problem in the past.

Just to be clear here, everything that follows can be avoided if the Space Bar properly resets itself when resuming the game.

Now that the GMM can be accessed using F5 (an assigned single key), if the Pause function hasn’t been reset before it’s opened, then odd behaviour can result with some of its functions (Load, Save, RTL).

Furthermore, the extent of these issues can vary relative to the version of macOS.

You asked for details, so here goes!

For example, on macOS 10.6.8 & 10.11.6, both Load & Save open their respective screens with the Autosave file preselected (in List mode).
As a result:

• In Load, no other saves can be selected.
• In Save, selecting a slot doesn’t offer a name prompt, though characters will appear on the right hand side of the screen if you start typing.

The quick test here is to press the Space Bar at least twice (or more to confirm the Pause dialog doesn't stick), then F5, then inspect the Save/Load windows, then repeat with Ctrl+F5 for comparison.
At the end of the day, this is inconvenient but harmless.

RTL is different. Note that in each of these cases, the Launcher is in windowed mode and the game is fullscreen. For each of these issues, set up the GMM as for Save/Load, check that one of the windows matches the relevant description, cancel back to the GMM, then select RTL.

On macOS 10.6.8 & 10.11.6, the exit autosave is created with the Pause function unset. If you hover the cursor over the Launcher’s Load button, the tooltip will flash indicating that state. The same applies when you click Load and enter the Load screen.
It’s what happens when you start loading games that responses differ:

• On macOS 10.6.8, all saves open correctly so there’s no problem.
• On macOS 10.11.6, if the Autosave is selected, the app usually freezes with a black window, or if selecting another save, again depending on the state of the Pause function, it may open without an issue, or crash the app with a segmentation fault.

Nasty stuff, and you probably won’t see any of it if it only affects certain systems.

So what’s the simple solution here?
It probably comes down to two choices:

• Allow the Space Bar to toggle the Pause function on & off on all systems (it’s the intuitive action for the user).
• Remove the Pause action from the Riven keymap, and rely on opening the GMM to pause the game during cutscenes (since it’s not needed otherwise).

In case you’ve missed it, I’ve reopened #11399 with some feedback about unexpected behaviour from your fix.

[bgK]

Thank you for your report, this was fixed by commit 85e3fb3.

[macca8]

Well done bgK!
All issues relative to the Pause action have been resolved.
However, I was in error in assigning the major RTL issues exclusively to F5, when in fact they applied equally to Ctrl+F5 access to the GMM. Unfortunately, this was masked by the testing regime. Furthermore, they also weren't directly attributable to the Pause action issues.

Based on the macOS console reports and the wide variety of selector errors, it appears that they are the result of a variation of the known SDL 1.2 bug affecting MacOS 10.9 & later (refer #11156), which was resolved by the release of SDL 2.0.
Previous reports of this bug had identified multiple switches between windowed & fullscreen modes using Alt+Enter in a single environment as the trigger. It appears that switching repeatedly between environments set to different screen modes has the same effect (as was the case when testing RTL issues).
The only potential solution here is to operate the Launcher and game in the same screen mode, and limit the usage of Alt+Enter. Or just run a build with SDL 2.0.

As such, no further action need be taken, and this report can remain closed.