Proposal 2.

Decoupling games from battle-rooms
These commands are used for better match-making. They allow to initiate games without creating a battle-room first. That means in practise, that we can also initiate multiple games from a single chat-room.

   <Command Name="CONNECTUSER" Source="client">
     <Arguments>
        <Argument Name="user" Optional="no" Sentence="no"/>
        <Argument Name="IpAndPort" Optional="no" Sentence="no"/>
        <Argument Name="scriptPassword" Optional="yes" Sentence="no">
       </Arguments>
      <Description>
      Client may send this command if it is a battle host or lobby moderator. Server will decide if they are and send  <clink name="CONNECTUSER"/> to user.
      </Description>
      <Response>
      See <clink name="CONNECTUSER:server"/>.
      </Response>
    </Command>

   <Command Name="CONNECTUSER" Source="server">
     <Arguments>
        <Argument Name="IpAndPort" Optional="no" Sentence="no"/>
        <Argument Name="scriptPassword" Optional="yes" Sentence="no"/>
       </Arguments>
      <Description>
      Client connects spring to given IP:port with given script password  <clink name="CONNECTUSER"/> to user.
      </Description>
      <Response>
      See <clink name="CONNECTUSER:client"/>.
      </Response>
    </Command>

----------------------------------------

    Proposal 3.

    REPLACED BY:
    We will introduce a new compatFlag + additional arguemtn to all *SAY* commands (isCommand), to allow lobby clients to send commands to each other "directly".
    These commands will have to be documented in the protocol XML aswell.

    ####################
    IGNORE FROM HERE ON:
    proposal 3 is used to make sure that client has the necessary resource to start spring in a room-less scenario.
    Alternatively REPORTDOWNLOADPROGRESS could be sent to all clients in a room so that they can display progress bars of other clients.

   <Command Name="REQUESTDOWNLOAD" Source="client">
     <Arguments>
        <Argument Name="userName" Optional="no" Sentence="no"/>
        <Argument Name="type" values="map|game|engine" Optional="no" Sentence="no"/>
        <Argument Name="resource" Optional="no" Sentence="yes"/>
       </Arguments>
      <Description>
      Client may send this command if it is a battle host or lobby moderator. Server will decide if they are and send  <clink name="REQUESTDOWNLOAD"/> to user.
      Resource is resource name - internal name in case of map or game, and engine version including last number in case of engine. User is user name
      </Description>
      <Response>
      See <clink name="REQUESTDOWNLOAD"/>.
      </Response>
    </Command>

   <Command Name="REQUESTDOWNLOAD" Source="server">
     <Arguments>
        <Argument Name="userName" Optional="no" Sentence="no"/>
        <Argument Name="type" values="map|game|engine" Optional="no" Sentence="no"/>
        <Argument Name="resource" Optional="no" Sentence="yes"/>
       </Arguments>
      <Description>
      Client starts download of given resource unless its already present <clink name="REQUESTDOWNLOAD"/>. Client responds with at least one REPORTDOWNLOADPROGRESS to the user.
      </Description>
      <Response>
      See <clink name="REQUESTDOWNLOAD"/>.
      </Response>
    </Command>

   <Command Name="REPORTDOWNLOADPROGRESS" Source="client">
     <Arguments>
        <Argument Name="userName" Optional="no" Sentence="no"/>
        <Argument Name="progress" Optional="no" Sentence="no"/>
        <Argument Name="eta" Optional="no" Sentence="no"/>
        <Argument Name="resource" Optional="no" Sentence="yes"/>
       </Arguments>
      <Description>
      During download, initied by REQUESTDOWNLOAD,
      client sends this information at least 1x per 30s to requestor of download and sends.
      Progress is in percents = 100 = done
       -1 = download failed
      Eta is in seconds
      If the file is already present, REPORTDOWNLOADPROGRESS is sent once with progress 100. Client must not send progress 100 if its not fully prepared to use the resource.

      Client can also send this command with empty user, in that case it will be advertised to his current battle-room.
      <clink name="REQUESTDOWNLOAD"/>.
      </Description>
      <Response>
      See <clink name="REQUESTDOWNLOAD"/>.
      </Response>
    </Command>

   <Command Name="REPORTDOWNLOADPROGRESS" Source="server">
     <Arguments>
        <Argument Name="userName" Optional="no" Sentence="no"/>
        <Argument Name="progress" Optional="no" Sentence="no"/>
        <Argument Name="eta" Optional="no" Sentence="no"/>
         <Argument Name="resource" Optional="no" Sentence="yes"/>
       </Arguments>
      <Description>
      This is received by the sender of REQUESTDOWNLOAD or by the people who are in the same battle-room.

      Client sends that at least 1x per 30s to requestor of download<clink name="REQUESTDOWNLOAD"/>.
      </Description>
      <Response>
      See <clink name="REQUESTDOWNLOAD"/>.
      </Response>
    </Command>

----------------------------------------

    Proposal 4.

FORCEJOINBATTLE -> JOINBATTLEFORCE

----------------------------------------

    Proposal 5.
Change CPU info

Some  lobby clients will report a special CPU id instead of processor  frequency. This may be used by other lobby clients to display a specific  icon or determine capabilities of an host.
Known CPU identifiers are listed below:

6666    Springie or Zero-K Loby
6667    Srpingie with matchmaker (fully managed autohosts)
7777    WebLobby
-1525630178    MUSLCE (Android Lobby)