So presumably one could take into account some mod side 'version' constant
to do some degree of versioning? Have you tried that by chance?
On Fri, Apr 18, 2008 at 1:33 PM, Tom Edwards <[EMAIL PROTECTED]>
wrote:
> I've just been leafing through the OB header files for Steam, and it's
> started talking about "modIDs" (steamclientpublic.h ln508 onward). That
> sounds good to me!
>
> > #if defined( CHECKSUM_CRC_H )
> > CGameID( uint32 nAppID, const char *pchModPath )
> > {
> > m_ulGameID = 0;
> > m_gameID.m_nAppID = nAppID;
> > m_gameID.m_nType = k_EGameIDTypeGameMod;
> >
> > char rgchModDir[MAX_PATH];
> > Q_FileBase( pchModPath, rgchModDir, sizeof( rgchModDir ) );
> > CRC32_t crc32;
> > CRC32_Init( &crc32 );
> > CRC32_ProcessBuffer( &crc32, rgchModDir, Q_strlen( rgchModDir )
> );
> > CRC32_Final( &crc32 );
> >
> > // set the high-bit on the mod-id
> > // reduces crc32 to 31bits, but lets us use the modID as a
> > guaranteed unique
> > // replacement for appID's
> > m_gameID.m_nModID = crc32 | (0x80000000);
> > }
> >
> > CGameID( const char *pchExePath, const char *pchAppName )
> > {
> > m_ulGameID = 0;
> > m_gameID.m_nAppID = 0;
> > m_gameID.m_nType = k_EGameIDTypeShortcut;
> >
> > CRC32_t crc32;
> > CRC32_Init( &crc32 );
> > CRC32_ProcessBuffer( &crc32, pchExePath, Q_strlen( pchExePath )
> );
> > CRC32_ProcessBuffer( &crc32, pchAppName, Q_strlen( pchAppName )
> );
> > CRC32_Final( &crc32 );
> >
> > // set the high-bit on the mod-id
> > // reduces crc32 to 31bits, but lets us use the modID as a
> > guaranteed unique
> > // replacement for appID's
> > m_gameID.m_nModID = crc32 | (0x80000000);
> > }
> > #endif
> >
> > void SetAsShortcut()
> > {
> > m_gameID.m_nAppID = 0;
> > m_gameID.m_nType = k_EGameIDTypeShortcut;
> > }
> >
> > void SetAsP2PFile()
> > {
> > m_gameID.m_nAppID = 0;
> > m_gameID.m_nType = k_EGameIDTypeP2P;
> > }
>
>
> [EMAIL PROTECTED] wrote:
> > Well Valve dodges the issue entirely because Steam enforces client
> > updates prior to the client HL2 even being launched.
> >
> > If there was no client/server mod version identification system
> > implemented, then simplified third-party integration with Steam would be
> > a solution.
> >
> > Jeremy wrote:
> >
> >> --
> >> [ Picked text/plain from multipart/alternative ]
> >> Haven't been modding long? Because mod versioning has generally been
> >> exposed
> >> to the modders, such as in the Q3 engine. Foxbot didn't need
> >> versioning for
> >> HL1, being server side only so I don't know if HL1 was missing the
> >> functionality too.
> >>
> >>
> >>> From the Q3 source
> >>>
> >> // check version
> >> s = CG_ConfigString( CS_GAME_VERSION );
> >> if ( strcmp( s, GAME_VERSION ) ) {
> >> CG_Error( "Client/Server game mismatch: %s/%s", GAME_VERSION, s
> );
> >> }
> >>
> >> Appreciate the responses, but none of them really address the core
> issue.
> >> That being that there doesn't appear to be any exposed versioning
> >> support. A
> >> proper solution shouldn't be that difficult to add. The entire point
> >> of this
> >> question for valve is that they have the ability to add something
> >> relatively
> >> easily and more 'proper' than any of the do it yourself solutions
> >> mentioned
> >> thus far. Notifying them that theres a more recent version doesn't
> >> solve our
> >> problem. As I already mentioned, our clients are generally updated.
> >> It's a
> >> number of the servers who are slow to update. It's a little late to
> >> change
> >> game folders for each version change(and a hack as well). Nowhere do I
> >> expect valve to provide update notification to clients.
> >>
> >> Servers being generally unattended kinda ruin the usefulness of a nag
> >> message, and I'd question how useful a command line nag message would
> >> even
> >> be on the server side. To me the only real solution is real versioning.
> >> Clients should not see nor be able to join incompatible servers,
> period.
> >> It's common sense. Given that versioning depends very much on the mod,
> >> there
> >> should be a hook for that provided somewhere in the mod, like quake 3
> did
> >> 8-9 years ago. Until then each release of a mod does significant
> >> damage to
> >> itself with user frustrations of not knowing what servers on a long
> >> list of
> >> them is compatible. Frustrated users don't stick with a game long.
> >>
> >> A response from Valve would be most useful. How does Valve do it? Maybe
> >> there's some way that hasn't been mentioned yet.
> >>
> >> J
> >>
> >> On Dec 10, 2007 5:07 AM, Tobias Kammersgaard
> >> <[EMAIL PROTECTED]>
> >> wrote:
> >>
> >>
> >>> --
> >>> [ Picked text/plain from multipart/alternative ]
> >>> Why not make some sort of huge label, element or whatever on the Main
> >>> Menu
> >>> screen that tells you if there's been released a new version (maybe a
> >>> flashing sign that would annoy the crap out of the users ;D)?
> >>>
> >>> Bet you could turn this into something usable :-)
> >>> http://developer.valvesoftware.com/wiki/Custom_Menu_Screen
> >>>
> >>> /ProZak
> >>>
> >>>
> >>> On 10/12/2007, Tony omega Sergi <[EMAIL PROTECTED]> wrote:
> >>>
> >>>> --
> >>>> [ Picked text/plain from multipart/alternative ]
> >>>> The thing that gets me:
> >>>> Mod versioning has been up to the mod author for the past 11-12
> >>>> years..without problem..
> >>>> yet now it's all of a sudden an issue..
> >>>> -Tony
> >>>>
> >>>> On Dec 10, 2007 1:13 AM, Stephen Micheals <[EMAIL PROTECTED]
> >
> >>>> wrote:
> >>>>
> >>>>
> >>>>> --
> >>>>> [ Picked text/plain from multipart/alternative ]
> >>>>> yes but the end effect is just about the same. (minus the wasted
> >>>>>
> >>> time
> >>>
> >>>> the
> >>>>
> >>>>> user spends loading/connecting to the game before the warning is
> >>>>>
> >>> shown)
> >>>
> >>>>> the idea i posted is just a simple method that should work, other
> >>>>>
> >>> fixes
> >>>
> >>>>> can
> >>>>> be more complex then needed.
> >>>>>
> >>>>> a proper version system would be a hell of a lot better.
> >>>>>
> >>>>> On Dec 9, 2007 9:51 PM, Mark Chandler < [EMAIL PROTECTED]> wrote:
> >>>>>
> >>>>>
> >>>>>> Think they are talking about before that function ever gets
> >>>>>>
> >>> called (
> >>>
> >>>> i.e
> >>>>
> >>>>> .
> >>>>>
> >>>>>> in
> >>>>>> the processes of connecting)
> >>>>>>
> >>>>> --
> >>>>>
> >>>>> _______________________________________________
> >>>>> To unsubscribe, edit your list preferences, or view the list
> >>>>>
> >>> archives,
> >>>
> >>>>> please visit:
> >>>>> http://list.valvesoftware.com/mailman/listinfo/hlcoders
> >>>>>
> >>>>>
> >>>>>
> >>>> --
> >>>> -omega
> >>>> --
> >>>>
> >>>> _______________________________________________
> >>>> 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
