It was a simple example, but it illustrates the trivial nature of what
it needs, which is simply a way for the engine to ask the mod for a
version number. Same thing as your example. It doesn't mean it
corresponds to the public release version number, just breaking
changes would need to change that, and not just class table changes or
user messages. Anything that alters the behavior of a game entities,
like our FF 1.1 to 1.11 we tweaked the assault cannon spinup time.
While technically not a breaking change in the sense that clients can
join 1.1 servers and not get an error, the different values on each
side result in awkward behavior, and the newer client would appear to
be shooting ineffectively earlier if the server was still using the
longer spinup time. It's not just a way to catch table mismatches
early, it's a way to keep client and servers in sync, and more
importantly, give clients an error message that means something.
There's no alternative to doing this but for the engine to ask the
mod. It's a bit short sighted that something like that doesn't already
exist.
J
On Nov 20, 2007 9:53 AM, <[EMAIL PROTECTED]> wrote:
> Your example is a bit misleading as to what would be needed. You shouldn't
> include version numbers in the description of the mod. You can always just
> add an sv_version cvar if you want a stringified representation of the
> version.
>
> The version that the srcds.exe/HL2.exe closed-source side of things would be
> concerned with would only be incremented when the new version was not
> backwards-compatible with the old version. Usually this would occur when
> class tables changed. It might also occur if usermessages needed to be
> interpreted differently, or perhaps if there were a critical bug of some sort
> in a client previous version and you wanted to prevent it from connecting to
> a new server and causing havoc. If the compatibility_version of the server
> differed from the client, then it would just pop up a message with a link to
> the "manual" or "developer_url" websites as defined in gameinfo.txt.
>
> ConVar sv_version("sv_version", "v6.1a beta");
> void GameRules::GetGameDescription(char*& description, int&
> compatibility_version)
> {
> description = "My Mod";
> compatibility_version = 4;
> }
>
>
> Another possibility would be to leverage some of the sv_pure functionality to
> allow for specification of a list of sha1sums of acceptable
> client.dll/server.dll on the client, for a given version of the server. The
> only downside there would be that you'd need to inform server hosts to add a
> new sha1sum to their server list every time a new client version was released.
>
>
>
>
> At 2007/11/17 02:05 PM, Jeffrey \"botman\" Broome wrote:
> >Jorge Rodriguez wrote:
> >>--
> >>[ Picked text/plain from multipart/alternative ]
> >>On 11/17/07, Jeremy <[EMAIL PROTECTED]> wrote:
> >>>It's a bit hard to believe something so trivial as client->server
> >>>versioning
> >>
> >>
> >>... trivial?
> >>
> >>I don't know where you got that idea.
> >
> >It could be trivial if GameRules::GetGameDescription() returned a
> >version number as well as a string...
> >
> >GameRules::GetGameDescription(char *Description, int *Version)
> >{
> > strcpy(Description, "My Mod v.83");
> > *Version = 83;
> >}
> >
> >The client would also need some way to return the version number to the
> >engine so that it could check this when displaying servers (filtering
> >out servers that weren't running the same version as the client).
> >
> >--
> >Jeffrey "botman" Broome
> >
> >_______________________________________________
> >To unsubscribe, edit your list preferences, or view the list archives,
> >please visit:
> >http://list.valvesoftware.com/mailman/listinfo/hlcoders
>
> _______________________________________________
> To unsubscribe, edit your list preferences, or view the list archives, please
> visit:
> http://list.valvesoftware.com/mailman/listinfo/hlcoders
>
>
_______________________________________________
To unsubscribe, edit your list preferences, or view the list archives, please
visit:
http://list.valvesoftware.com/mailman/listinfo/hlcoders
