[crossfire] Metaserver2 / schmorp

[Mark Wedel]

Nicolas Weeger wrote:
> Hello.
> 
> Schmorp server appears on metaserver2. But the officiel client (latest) SVN 
> does *not* work with this server.
> 
> This server shouldn't be on metaserver2 until it supports the official 
> Crossfire client, since metaserver2 is the future 2.0 version.

  My $.02 is that the SC_VERSION on the svn trunk for crossfire should have been 
updated when the older commands were removed, because effectively clients 
(either crossfire or other) can not play on a trunk server.  It is sort of 
problem that because that hasn't been done, a client would have to connect to 
the server to find out it doesn't have any compatible way for map updates (this 
also applies to turnk releases of the client talking to fairly old 'real' 
crossfire servers)

  I note that schmorp does currently report older cs/sc versions, so in that 
sense, I think it is proper.  I think the clients should filter out servers that 
have protocol levels is does not support, so in this case, trunk clients should 
not show schmorp as an available server in its list of metaservers.

  I say this because as we move forward with 2.0, I expect to see those servers 
running 1.x branches until 2.0 becomes stable, and alpha/beta/test 2.0 servers. 
  And I also expect at some point protocol changes may be made so that 2.0 
servers will not be compatible with 1.x servers, and client should show 
appropriate servers (1.x client show 1.x servers, trunk client show trunk 
servers - it is conceivable that outdated trunk clients (eg, checkout 6 months 
old), may not have any servers to show).

  As such, it would seem banning servers from metaserver2 because they do not 
support latest trunk would be wrong, because that would likely result in us 
banning 1.x servers also.

  If schmorp was not playable with either the 1.x client or trunk client, then 
it seems reasonable it shouldn't be listed.

  Looking what is there right now, it does seem that schmorp is reporting some 
incorrect information, which would be grounds for blacklisting - in particular, 
it clearly isn't running off a standard code base (and I'm not sure about maps 
or arches), so that should get fixed.  It also doesn't seem to be reporting 
bytecounts, but I don't think we have an actual official policy that it has to 
do that.