On 4/7/09, Zarel <zarelx...@gmail.com> wrote:
> 2009/4/7 bugs buggy <buginatorx...@gmail.com>:
>
> > We also may want to change GAMESTRUCT, so the master server can take
> > care of games that have a password, and other stuff we want to check
> > for?
>
> YES.
First, let me explain a bit.
typedef struct
{
uint32_t GAMESTRUCT_VERSION; // in case we have different sized GAMESTRUCTs?
char name[StringSize];
SESSIONDESC desc;
char motd[max_motd_sting_size]; // to get MOTD from server?
(date/time structure here?)
uint32_t game_version_major;
uint32_t game_version_minor;
uint32_t private; // if a private game
uint32_t password; // would be password hash (only used for private games)
uint32_t mods; // would be if host allows mods or perhaps
running mods?
uint32_t pure; // pure flag (no mods allowed for host/clients)
uint32_t cheats; // allow some of them? (host decides?)
uint32_t future1; // reserved for future use *though, not
really needed if we
uint32_t future2; // have a GAMESTRUCT_VERSION check...
uint32_t future3;
uint32_t future4;
(more?)
} GAMESTRUCT;
Now, let me get into more detail.
The first version of the version checking code did *not* modify GAMESTRUCT.
It used special packets to request a version ping, and if that request
went unanswered, then it would auto-kick the person.
If the person did respond to the version ping, but didn't have the
correct version, then it would auto-kick.
I would have preferred to modify this structure (GAMESTRUCT), since it
is the first thing that is sent.
However, the reason I didn't was to remain backwards compatible with
2.1.3, (which don't have the version checking code for whatever
reason--blame GNA!).
*If* we want 2.2 to be released ASAP then I think we shouldn't do the
GAMESTRUCT mods, but we *should* have the version checking code. It
has enough room to grow. The GAMESTRUCT mods should be saved for
trunk & the new branch. (There wouldn't be that much changes from
what the current version checking does now, it just get done a bit
earlier in the process.)
> imho, most of the problems with hosting multiplayer games is that
> people with incompatible versions always join, and it's impossible to
> shoo them away. That's why I find version check so important.
>
> By the way, Buggy, I sincerely hope your version checking code affects mods.
Can't do it easily...
We can turn OFF mods for 'pure' games, but detecting what mod is
loaded is a huge PITA. We would need to parse the directory that
physfs is pointing to. Then copy that list someplace. Then try to
figure out which mod has priority over another one, and finally, we
send that info with the version checking code.
If one or more of the mods conflict with each other, then... :(
>
> Even if we make totally network incompatible changes, there's an easy
> fix without even changing the corresponding ports:
>
> In 2.2:
> - Interpret an unrecognized packet as a kick.
Does that now
> In the lobby server:
> - Have the lobby server retain backwards compatibility.
perhaps. Depends if we want to modify GAMESTRUCT or not.
> In 2.3:
> - Use either a recognized version check packet, or a known unrecognized
> packet.
yep.
_______________________________________________
Warzone-dev mailing list
Warzone-dev@gna.org
https://mail.gna.org/listinfo/warzone-dev
