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
