Actually this is a topic I've been musing for a while. We plan to follow the release early, release often approach which could mean a patch/update going out every 6-8 weeks. Version conflicts with server/clients is a big concern for us.
About the only solution we came up with was to have the mod version number in the actual mod name so you can see what version servers are running in the server list. Untidy but might be the easiest solution. - Jed On 09/12/2007, Jeremy <[EMAIL PROTECTED]> wrote: > -- > [ Picked text/plain from multipart/alternative ] > Sorry for reviving this, but can I please get some sort of response from > Valve? > > I'd imagine their updates probably never break netcode compatibility and > such, but is that to say there isn't the infrastructure to support game > compatibility breaking changes? > > For whatever reason, a number of servers for our mod still haven't updated > to the latest version, clients go through several attempts at joining > servers, only to error out, before finding one that works. As you can > imagine it really destroys the player perception of a mod when we can't do > fundamentally basic things like differentiate versions between one another. > That includes only showing clients servers compatible with their version, > and giving meaningful error messages to them if they do somehow try to join > one. > > Valve, please throw something into this discussion. Surely the need is > obvious. > > J > > On Nov 22, 2007 1:28 AM, Julian Moschüring <[EMAIL PROTECTED]> wrote: > > > Most recent example would be Garry's Mod. > > Valve gets money, the mod community gets more popular, the sdk > > improves... everyone is happy. Where is the point of this discussion? > > > > Adam Maras (memzero) wrote: > > > It wasn't on the Source engine a long time ago. It also wasn't owned by > > > VALVe a long time ago. > > > > > > // Adam Maras (memzero) > > > > > > Kori wrote: > > >> It was along time ago. > > >> ----- Original Message ----- > > >> From: "Nick" <[EMAIL PROTECTED]> > > >> To: <[email protected]> > > >> Sent: Wednesday, November 21, 2007 7:14 PM > > >> Subject: Re: [hlcoders] Proper mod versioning? > > >> > > >> > > >> CS isn't free... > > >> > > >> On Nov 21, 2007 5:57 PM, Slash <[EMAIL PROTECTED]> wrote: > > >>> Ha! Valve hasn't made money off of mods? Have you lost your marbles? > > >>> > > >>> http://www.steampowered.com/v/index.php?area=stats > > >>> > > >>> See that "Counter-Strike" thing there at the top? That's a mod. Not > > >>> only did it bring in great revenue by itself once Valve "adopted" it, > > >>> but it also made Steam a legitimate and popular platform. Valve > > >>> wouldn't be in the position they are right now without HL1 mods and > > >>> millions and million of people playing them. With appropriate > > >>> resources, anyone can make a platform like Steam- The problem is > > >>> getting people to use it. HL1 mods are what got people using Steam. > > >>> People = Money. And now it has tons of games and that is very > > >>> beneficial to Valve. And it's not just CS- There are a ton of mods > > >>> throughout the years that contributed to the success of Valve's online > > >>> presence. Without the strong mod community in HL1, I would fancy a > > >>> guess that Steam would either not exist or would be an irrelevancy. > > >>> > > >>> > > >>> On Nov 21, 2007 6:36 PM, Nick <[EMAIL PROTECTED]> wrote: > > >>> > Now before people get upset. Valve helps mods a great deal, but > > >>> > clearly it isn't their top priority, nor should it be. > > >>> > > > >>> > > > >>> > On Nov 21, 2007 5:35 PM, Nick <[EMAIL PROTECTED]> wrote: > > >>> > > Since when did Valve ever make money off free mods? I really see > > no > > >>> > > reason for Valve to help mods that could and probably do compete > > >>> > > against Valve products? > > >>> > > > > >>> > > > > >>> > > On Nov 21, 2007 12:04 PM, <[EMAIL PROTECTED]> wrote: > > >>> > > > 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 > > >>> > > > > > >>> > > > > > >>> > > > > >>> > > > >>> > _______________________________________________ > > >>> > 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 > > >> > > >> > > >> > > >> _______________________________________________ > > >> 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 > > > > > -- > > _______________________________________________ > 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
