> Ok, this whole argument is showing the need for a "codebase type" field > for the metaserver. A description of this field should also be provided > to the user of the client if it is implemented. > > A couple of other fields i can think of that would be useful would be > for "map set" and "server configuration". >
So a question here would be what info should be in the metaserver beyond what we have now. Quick thoughts, gathered here and from other areas: 1) Server code base 2) Map code base 3) Archetype code base? 4) The SC_VERSION and CS_VERSIONS that the server supports (this could be handy as the clients could filter out servers they know they can't use) 5) A flags field with single letter flags that could denote various things, like: $ - pay to pay P - player killing allowed p - permadeath etc - ideally, these flags get interperted by the client, so perhaps filtering can be done, icons, etc. Any that the client doesn't understand, it either ignores or displays in some way. The flags don't necessary have to match what they stand for, and if they grow enough, they certainly wouldn't. But that gives spaces for 90+ flags in one field, so it means expanding to new things is easier than having to add new fields. Another question related to this is whether we should re-do the metaserver connection method all together - in shorter term, the servers could use both new and old methods to report data, but then at some point, they only use new method. There were discussions in the past about this - I bring it up now, because if we add all these new fields, it may make it hard to keep things compatible. _______________________________________________ crossfire mailing list [EMAIL PROTECTED] http://mailman.metalforge.org/mailman/listinfo/crossfire