version used on lobby server (TASSERVER, OPENBATTLE)

[abma]

when setting the default version of spring i found some inconistenty / not documented stuff in lobby protocol:

the command TASSERVER sent by lobbyserver (see also OPENBATTLE) sends the default spring version used on the lobby server. there was/is some controversy about what it should be set to as there exist two possibilties:

1. the sync version, for example "95"
2. or the full version, for example "95.1"

the version is sent by the client that opens a battle and a client that joins a battle receives it and it has to check if the "sync" version is the same. when using 1. it could just do a full string check, when using 2. it has to check only the sync relevant part, "95" in the example.

1. has the benefit as the client has to only do a string comparison, but it disallows to check if versions are 100% identical or a minor update exists.

i've choosen variant 2. because it was already used and has some benefits, as its more informal with the drawback that it maybe requires client code changes / more complex code on the client. but it also allows directly to get the correct path to download the engine that is needed on the host.

i've also implemented it in the current development version of springlobby and updated LobbyProtocol docs.

I hope this causes no problems on clients/autohosts/etc. Atm there are still some battles opened with version "95" set, but clients atm have to understand both, because springie always sets version by schema 2.

[Silentwings]

Summary as i understand it, protocol says one thing, springie can only deal with the other, spads handles both.

I don't have a view on which is better - if you engine ppl think the .0/1/etc syncing has uses then it should be kept and go with 1. If not then go with 2.

Slightly not relevent side point; when its actually printed somewhere I think "95.0" just looks better than "95" as a version number.

[jK]

how to handle "94.1.1-1241-geb77a48"?

[abma]

any version which has chars that are not "0123456789." is seen as not stable -> full string has to match.

atm we can't change to an always full string match as some lobby / autohosts have implemented the incomplete OPENBATTLEEX/BATTLEOPENEDEX. (these commands didn't allow to send versions which include a space, and development versions contain such...)