PauseReduction Setting

[SamuZad]

This PR creates a dropdown (set to off by default) to reduce the number of "forced pauses" by the game. When playing in singleplayer these are not an issues, but in multiplayer some people (including the people I play with) find them a bit jarring. Especially if one of the players is a bit overly prone to spamming the Esc key, it can be quite disruptive to other players

The possible options are:

• Off (standard behaviour)
• Recommended (reduces the pauses during the deconstruction confirmation)
• High-Risk (makes the Esc menu non-synced, and does not pause the game)

I should also point out the following things:

• the game will work just fine with the dropdown set to different values by different players (ie, it won't cause inherent desyncs in that state)
• I made some minor edits to the comments, but stopped shy of a full rewording etc

This PR might indirectly help with #57

Let me know if you need me to tweak/change anything

[thomaswp]

This is a good idea - thanks for the PR. I'm a little confused at some of the choices, and I made what I think is a simplified version here: https://github.com/thomaswp/BeaverBuddies/tree/feature/reducepauses-setting

Basically: OverlayPanelSpeedLocker.OnPanelShown is the only thing that ever calls SpeedManager.ChangeAndLockSpeed (other than dev panel stuff), so there's really no need to modify both. I just kept the former. This has the advantage of removing the need for the static variable.

However, you may be seeing things I'm not, e.g. something arises if people have different settings?

I'm going to leave this one out of the next release for now since it's more experimental, but take a look and let me know what you think.

[thomaswp]

Also just a heads up (that should maybe be in the tooltip on the option: this might cause some issue when saving. Right now the save functionality assumes that you're at the end of a tick. But if the game is running when you Save or do other things in the menu... that could be problematic. So I'd recommend manually pausing before actually using the options menu. Which sort of makes me think the options menu should be exempt from this rule (I don't know why your friend presses it habitually but maybe that's the root issue :D). What do you think? Or it could just be "use at your own risk" but I really don't like the idea of including things that could in theory crash or corrupt a save...

[thomaswp]

I'd say at most it should be a separate option (e.g. a 3-option dropdown with "Pause normally" "Only pause on options menu" and "Don't pause at all (see warning)" with a warning about pausing before saving. But I wonder how useful that last one really would be.

[thomaswp]

Also for lack of a better place, putting this here: a way to manually set the OptionsPanel to freeze the game (or not):

            base.Replay(context);
            var optionsBox = context.GetSingleton<IOptionsBox>() as GameOptionsBox;
            // In lieu of optionsBox.Show(), we push the options box directly so we can control
            // the lockSpeed function
            // If the user wants to reduce pauses, don't create an event or pause the game.
            // Let each player open their own menu independently.
            optionsBox._panelStack.Push(optionsBox, hideTop: false, showOverlay: true, lockSpeed: !Settings.ReducePausesEnabled);

[SamuZad]

I wanted to put a Work in Progress label on the PR, but there wasn't one so I just put it in the title for now

I'll take a look at your simplified version tomorrow. There were some "unintended consequences" of this change - but I will test it to make sure that I'm not misremembering

And yes, we got into the habit of manually pausing before saving, but even when we haven't had "a save corruption" problem (and at this point we have quite a few hours with this setting) - though of course, just because we haven't encountered it doesn't mean it can't happen. I like the idea of the 3-option dropdown though

[thomaswp]

Hey, just following up on this one. Did you have a chance to look at / test the updates I made?

[SamuZad]

Sorry, been swamped with work, should have some time this weekend 🙏

[Cilyena]

The ESC key closes pop-up windows. I think we should simply prevent the game menu from opening when the ESC key is pressed and display a message saying "Would you like to display the menu? Please note that the game will be paused. Yes/No" or, without displaying a message, ask the user to press ESC a second time within 2 seconds.

[SamuZad]

The ESC key closes pop-up windows. I think we should simply prevent the game menu from opening when the ESC key is pressed and display a message saying "Would you like to display the menu? Please note that the game will be paused. Yes/No" or, without displaying a message, ask the user to press ESC a second time within 2 seconds.

While it would be exciting to make something like this, I think it would put too much of a "cognitive burden" on the player. But of course, maybe I'm just imagining it wrong

[SamuZad]

@thomaswp I tried your branch, and then implemented the "3-way dropdown". I can change the option names and change the setting to a Range slider (I tried it as well, but liked the dropdown more tbh). Let me know what you think

[robinplace]

Love this by the way. I'm a huge escape-key-hitter & it's a problem.

I'd suggest that straight up removing pause-on-panel-open everywhere, with no setting otherwise, would be great in a multiplayer setting. The resume button in the options panel or hitting the pause key shortcut is plenty.

This is probably the behavior people are used to. Most popular multiplayer games I'm aware of don't pause unless a player is quite explicit about wanting to pause.

If the only real hangup is clicking the save button then modifying that to wait until end-of-tick doesn't seem too difficult.