Autolaunch should be disabled if one of the players is ZZZ

[bibim]

As battle.net has proven time and time again, a ready button is bad design. Obviously many lobby devs agree.

If you're using springlobby as some sort of metric for what is "standard" then ur doin it rong. I suggest using pretty much just about any commercial RTS game as your metric for what is standard. The obvious being battle.net because obvious reasons.

The reason I am annoyed is that this is such standard behavior that it becomes difficult to explain why it's standard behavior... Suffice it to say that it works well. There is a reason the companies use the method.

You got me totally wrong. What I tried to explain to you in my message is that what I consider the standard (for Spring, obviously) is what is described in the official Spring lobby protocol description. This document provides the "ready" status flag that is meant to be used by lobby clients to tell if the player is ready or not (cf MYBATTLESTATUS command). It doesn't matter if this is good or not, I'm just saying this is how it is designed in official documentation, how it has been used by all lobby clients in the past, and how it is still used by most lobby clients (including the main official one).

As long as this is the standard , I don't see why I would auto-spectate ready players. I could make it possible to prevent auto-start when a player is afk in a future version though.

That being said, I'm not convinced that the removal of the ready button would be a good thing with current Spring lobby architecture:
I never used battle.net, but is it really relevant to compare battle.net with current Spring architecture?
Does battle.net use the same server/autohost system with big rooms of 8v8+ players? (not matchmaking)
Do battle.net games require as much waiting and have as many spectators as Spring games, leading to a high proportion of afk players?

[Jools]

I tried to work on a plugin for this behaviour, more specifically doing a check in "prespadscommand" to see if people are afk or not, but I couldn't reproduce the autolaunch setting (it's actually called autoStart right; I tried with values "on" and "advanced"). The games simply don't autostart for me at all, even with no AI and with two human players both ready. I wanted to reproduce the autolaunch so I could see if it shows up in prespadscommand callin, and if it does, a plugin could be easily made.

On another note: why don't you just disable autoStart for your hosts?

[bibim]

I tried to work on a plugin for this behaviour, more specifically doing a check in "prespadscommand" to see if people are afk or not [...] I wanted to reproduce the autolaunch so I could see if it shows up in prespadscommand callin, and if it does, a plugin could be easily made.

Auto-start doesn't work by simulating a !start command, so the preSpadsCommand callback won't be called by SPADS core when auto-starting.

One simple way to use a plugin to disable auto-start when one player is afk would be to dynamically adjust the autoStart setting value. For this you could use a timer running every second (cf Timers management in the plugin API) which would check the players in the battleroom, or a handler on CLIENTBATTLESTATUS messages (cf Lobby handlers in the plugin API). When at least one player is afk, autoStart would be set to off by the plugin, otherwise it would be kept as configured in SPADS configuration files. SPADS would do all the remaining job by itself.

I couldn't reproduce the autolaunch setting (it's actually called autoStart right; I tried with values "on" and "advanced"). The games simply don't autostart for me at all, even with no AI and with two human players both ready.

Are you sure the battleroom was satisfying all autoStart conditions when you tested with the "advanced" value, especially the minPlayers one?

[Jools]

How about this solution instead: https://github.com/Yaribz/SPADS/pull/10

The proposition is to add a 'beforeStart' callout, which allows a plugin to do whatever it wants before the game is launched.

It would also provide an easy solution for adding a launch countdown, like shown in this code: http://pastebin.com/PMsMDzGP

[Jools]

As battle.net has proven time and time again, a ready button is bad design. Obviously many lobby devs agree.

If you're using springlobby as some sort of metric for what is "standard" then ur doin it rong. I suggest using pretty much just about any commercial RTS game as your metric for what is standard. The obvious being battle.net because obvious reasons.

The reason I am annoyed is that this is such standard behavior that it becomes difficult to explain why it's standard behavior... Suffice it to say that it works well. There is a reason the companies use the method.

I haven't played a lot of rts games, but I have played a little bit of civilization and company of heroes in multiplayer. They both have ready buttons. Maybe there are several industry-wide standards? How would you know if someone is ready if you don't ask him?

Anyway, I think the best thing to do is to allow for both ways...

[Forboding Angel]

Maybe there are several industry-wide standards? How would you know if someone is ready if you don't ask him?

Well, basically RTS as esports generally set the standards for these things. Starcraft1/2 being the most glaring examples.

The person is ready if he is on a team. If he isn't ready he should be a spectator. This is generally how games do this sort of thing and it makes sense.

Well autostart as it is is basically worthless. Why even have it if it isn't useful? With the way it currently works the use cases for it are extremely small. Utilizing a countdown and making sure that all the players on a team are present should be the very least of it's functions.

Using a ready button is not good design. If the player is on a team, he is ready. This is common and standard behavior.


To answer a question posed elsewhere, yes Battle.net has custom games, and the setup works incredibly well. There is no ready state, there is simply the host with the ability to move players around (the lobby autobalances so moving isn't usually done often). Only the host can add AIs, and only the host has a start button.

It works very well, and it is dead simple. Everyone knows how it works and rarely do issues arise. If a player causes issues, the host kicks him and life goes on. Clicking start starts a 10 second countdown. The players have 5 seconds to drop out which stops the countdown. They cannot spec after countdown has started, they can only leave the game. Game lobby is locked when countdown starts. That same player can't just immediately rejoin the game (this prevents trolling of any sort). Game lobby is unlocked if countdown is interrupted (but the player who left can't just rejoin immediately, there is a lockout period).

Basically this nips all possible bad behavior in the bud. Sure a player could leave the lobby to stop the countdown, but he can't rejoin it, so it's not an effective trolling method. Spectators are limited (specs in battle.net are rare except for tournaments).

Look guys, sc2 multiplayer is free. You really should download it and use it a little bit. It will open your eyes, big time. Battle.net isn't perfect, but it is VERY VERY good.

[bibim]

How about this solution instead: https://github.com/Yaribz/SPADS/pull/10

The proposition is to add a 'beforeStart' callout, which allows a plugin to do whatever it wants before the game is launched.

Yes it's always possible to modify SPADS core code to call a new callback to do exactly what we want when we want. However, I try to limit the number of callbacks in the plugin API, to maintain a good balance between simplicity and flexibility.

That's why I suggested simple ways to implement the desired behavior without modifying SPADS core, to show this is already possible easily using the existing set of functions/callbacks. And in your example (a plugin preventing auto-start when a player is afk), the plugin code wouldn't be bigger when using timers or lobby callbacks than when using your new dedicated callback: in one case the code doing the afk check would be in a new callback and would return 0 or 1, whereas in the other cases this code would be in a timer or a lobby callback and would just update the autoStart value. The overall code size and complexity is the same.

That being said, I guess such a callback could be useful for other things (for example to prevent starting the game using !start when a player is afk). So I think I will add it. But it will be a bit different than what you provided in your merge request, to allow plugins to provide reasons for preventing game start. Anyway, thanks for your merge request.

It would also provide an easy solution for adding a launch countdown, like shown in this code: http://pastebin.com/PMsMDzGP

This CountDown plugin only requires a callback called just before launching the game, and there is already one: addStartScriptTags. So basically this plugin could already be used with current SPADS version, it doesn't require a new callback.

However the problem of this plugin is that it contains blocking code: the "sleep" call. Consequently, during your "countdown" SPADS will be totally frozen: it won't be able to process anything else like network messages, lobby commands, timers etc. So you won't even be able to prevent the game from starting during this countdown. Basically this plugin just implements a freeze in SPADS before game start.

[bibim]

To answer a question posed elsewhere, yes Battle.net has custom games, and the setup works incredibly well. There is no ready state, there is simply the host with the ability to move players around (the lobby autobalances so moving isn't usually done often). Only the host can add AIs, and only the host has a start button.

Well I wasn't asking if battle.net had manual games, we have self-hosting too but it's quite off-topic here. I was asking if it was relevant to compare battle.net system with the autohost system we have here, in other words does battle.net have an automatic hosting system (i.e. not with a human host who can manage the battle) which doesn't rely on matchmaking?

Spectators are limited (specs in battle.net are rare except for tournaments).

It is very different in Spring. It's not uncommon to see as many specs as players for example, which explains the high afk ratio and the usefulness of the ready the button (cf the players who join a battle lobby just to spectate a game in progress but forget to spectate in the lobby and then go afk for example)

[bibim]

New callback added in the plugin API (SPADS 0.11.38): preGameCheck