Ammler wrote:

a local test with trunk
hd52fbbbc 16177 0 hd52fbbbc

set min_active_clients
Current value for 'min_active_clients' is: '0' (min: 0, max: 255)
set min_active_clients 1
*** Game paused (not enough players)
*** AmmIer # 1 has joined the game
*** Game paused (connecting client)
*** Game unpaused (client connected)
*** AmmIer # 1 has started a new company (# 1)
*** Game unpaused (enough players)
pause
Game is already paused.

This comment was imported from FlySpray: https://bugs.openttd.org/task/2864#comment5976

Rubidium wrote:

Assume "next join" is whenever autopause would unpause and "next quit" is whenever autopause would pause.

Manual pause and automatic pause will always interfere in some way. It looks like the messages are just misleading, but I also think that automatic pausing and manual pausing was never intended to be used together.

For example: if I manually pause the game, should a leaving and rejoining player cause the game to be unpaused? Should a joining player cause the game to be unpaused?
It would make perfect sense (for me) that you just want to pause the game because you joined and are going to eat something and don't want to disconnect but want to make it possible for others to join and continue. On the other hand it would make as much sense to say that because you manually paused the game, the automatic pausing/unpausing shouldn't occur.

What currently happens (I think) is that each pause increments a counter and each unpause decrements it. It might make sense any manual unpause 'resets' that counter to 0. But then doing a manual pause will mean something different when 'autopaused' or not. If autopaused already the next join will decrement it and unpause the game. If not autopaused the next quit will increment the number thus never unpausing it. This is inconsitent behaviour, which means it isn't the solution. This leaves the option that the game is paused when either autopause is in effect or a manual pause is done, which means you cannot 'undo' an autopause (i.e. unpause when autopaused). I reckon that this again is unwanted behaviour, which basically makes autopausing a feature that CANNOT be implemented without nasty side effects.

So the choice is: consistent pausing/unpausing behaviour when mixing manual pausing and auto pausing OR the ability to unpause when auto paused as you simply cannot have both!

This comment was imported from FlySpray: https://bugs.openttd.org/task/2864#comment6009

Ammler wrote:

IMO, the automatic unpause/pause should function always, as you can disable it with min_active_clients=0. So if you use manual pause/unpause, it should be retriggered with client join/part (and move to/from spectactors).

As a workaround, I could imagine to make a custom command for autopilot, which does change min_active_clients instead of pause/unpause.

Greets
Ammler

This comment was imported from FlySpray: https://bugs.openttd.org/task/2864#comment6024

Rubidium wrote:

Why a custom command for autopilot? Isn't the 'normal' settings changing command enough?

This comment was imported from FlySpray: https://bugs.openttd.org/task/2864#comment6025

Ammler wrote:

As I said, a workaround. Isn't that easy either. Best would be, min_active_clients doesn't care about state of manual pause/unpause, imo.

This comment was imported from FlySpray: https://bugs.openttd.org/task/2864#comment6036

Rubidium closed the ticket.

Reason for closing: Fixed

In r16242

This comment was imported from FlySpray: https://bugs.openttd.org/task/2864