Indeed, that example falls in to the category of new version interpretations,
or client/server havoc from differing incompatible code bases. I think we (and
all the other modders out there) are in violent agreement on this one.
It's just a question at this point as to what Valve's planning to do about it,
since it's really out of the modders hands to have a reasonable solution here.
At 2007/11/20 12:48 PM, Jeremy wrote:
>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
