There are the most battles hosted by autohost in Spring. And as I know currently 2 or 3 implementations of them. All implementations has more the less common commands. And strictly all autohosts use one way to interact with users - it is chat message. I think it is ugly. Some lobby ( TASClient, Zero-K for examle ) introduce GUI elements to make autohost control more friendly to user, such things as voting, set game preferences.
But it is impossible to implement complete battle management GUI for autohost in correct, clean and compatible way for all authosts.
Moreover, to implement matchmaking, and other advanced features we required many information not related to lobbyserver itself. It is communication between autohost and user.

So I think it is time for autohost protocol.

Protocol consist of subsystems - features. When user attempt to connect, autohost send all required and optional features, that autohost implemented. If lobby not implement required features, then lobby should not connect to autohost.

Currently I suppose next subsystems:

• Autohost management ( may be should not be in autohost protocol )
• Information (about host) ( Required )
• BattleManagement ( Required )
• MatchMaking ( Required )
• Smurf db ( Optional )
• Clan Battles ( Optional )

Autohost can implement for example only Information and Matchmaking features, so lobby can show appropriate UI. (Set preference for games types, (1v1, Coop vs bugs, Zero-K)). When we go to Autohost with BattleManagement then we got UI with box, team management. Cool buttons for voting, boss mod and other.
And get rid talking with bots.

Imo only thing thats really needed is unified voting/map/settings interface so that you can add gui to change common things (map, modoptions) and display ongoing polls.

I agree with Licho here. Starting point should be a minimal set of most commonly used commands.
The question of whether autohosts authors would actually commit to this protocol is also somewhat open.

Yeah.

Really, we already have a framework for a mod or map providing a set of options to the lobby - the Mapoptions.lua and Modoptions.lua.

Logically, let a Spring bot message a user with Commandoptions.lua, that is functionally the same as the Mapoptions and Modoptions but with the additional concept of providing multiple "submit" buttons. This way a bot can be provide the complete flow of a menu - the user initiates communication with the menu command, so the bot replies with a list of commands and submenus.

The user picks a command, and the bot replies with a commandoptions of parameters and a "submit" and "back" button. And so on.

Just add a standard base "request menu" command to get the root command and integrate sending that to host into the battle window.

I'm starting unified battle management of existing autohost system.
First I do list of battle commands. Then I need autohost developers implement them. It should be a problem I think. So I try maximum using of existing common autohost commands.

BattleManagement

BattlePresets

• Start rects
• Set map
• Set game settings ( Mod/Map options )
• Start game
• Voting

BattleService

• Info about battle progress
• Info about user download progress
• Ring
• Notifications

Commands suggestion later in etherpad

Autohosts knows nothing about user download progress btw.