Unable to stop game on [x]TheHost autohost

[pear]

Sometimes the game ends (last commander dies) but the host doesn't stop. Sometimes the host refuses to accept anyone's "!stop", presumably because it doesn't allowed timed out and disconnected players to do that and frequently almost everyone is in one of those statuses after game end. This makes it impossible to stop the server without an admin.

To fix this I propose the following change to SPADS. If no players have played within the last 45 seconds or all but one alliance has no commanders (i.e. someone won) then anyone should be able to call !stop vote, including timed out players and spectators.

Edit: this happened to me just now on [x]TheHost (SPADS 0.11.9).

[bibim]

Sometimes the game ends (last commander dies) but the host doesn't stop.

I believe this is a known bug of Spring 94, related to the server not catching the gameover messages from some clients, depending on the compile options of the server and the clients (32/64 bits etc.). Maybe I'm wrong but for some reason it doesn't seem to happen on my hosts (Spads*), on which I compiled spring-dedicated myself.

Sometimes the host refuses to accept anyone's "!stop", presumably because it doesn't allowed timed out and disconnected players to do that and frequently almost everyone is in one of those statuses after game end. This makes it impossible to stop the server without an admin.

I guess this only happens on [x]TheHost, because vbs uses a custom rights requirement for !stop command which prevents players no longer playing to vote for stop.

To fix this I propose the following change to SPADS. If no players have played within the last 45 seconds or all but one alliance has no commanders (i.e. someone won) then anyone should be able to call !stop vote, including timed out players and spectators.

Edit: this happened to me just now on [x]TheHost (SPADS 0.11.9).

I think it's better to ask vbs to remove his special rights requirements for !stop command until the Spring bug responsible for this problem is fixed (in version 95 I guess).

[pear]

I didn't realize the problem was partly caused by a custom configuration. I agree that eliminating said customization is the appropriate action.