Re: [hlcoders] Proper mod versioning?
I've just leafing(wtf is leafing) through the old ep1 sdk.. I think
these things might be important too:
// FIXME: bah, this is horrendously hacky, add
a damn back pointer
for (n = 0; n < g_sequence.Count(); n++)
{
// reduce deflection the more the eye is off center
// FIXME: this angles make no damn sense
eyeDeflect = eyeDeflect * (local.x * local.x);
{
// Hrm, we didn't link up to correct type!!!
Assert( 0 );
// Delete right away since it's fucked up
I don't know about you, but this is some pretty serious stuff going
on. Looks pretty good tbh :P
On Fri, Apr 18, 2008 at 3: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 | (0x8000);
> > }
> >
> > 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 | (0x8000);
> > }
> > #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,
> >
Re: [hlcoders] Proper mod versioning?
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 | (0x8000);
> > }
> >
> > 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 | (0x8000);
> > }
> > #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 M
Re: [hlcoders] Proper mod versioning?
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 | (0x8000);
> }
>
> 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 | (0x8000);
> }
> #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
Re: [hlcoders] Proper mod versioning?
/Facepalm.
On 13/04/2008, Nick <[EMAIL PROTECTED]> wrote:
>
> No he just thought it would be a good idea to bump an inactive thread
> because obviously if valve didn't give a crap the first time, maybe
> after 6 months they might change their minds.
>
> On Sat, Apr 12, 2008 at 7:38 PM, Garry Newman <[EMAIL PROTECTED]>
> wrote:
> > Hah, was that message stuck in your outbox for a few months?
> >
> > garry
> >
> >
> >
> > On Sun, Apr 13, 2008 at 1:15 AM, <[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
Re: [hlcoders] Proper mod versioning?
No he just thought it would be a good idea to bump an inactive thread
because obviously if valve didn't give a crap the first time, maybe
after 6 months they might change their minds.
On Sat, Apr 12, 2008 at 7:38 PM, Garry Newman <[EMAIL PROTECTED]> wrote:
> Hah, was that message stuck in your outbox for a few months?
>
> garry
>
>
>
> On Sun, Apr 13, 2008 at 1:15 AM, <[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
> > >> > > .
>
Re: [hlcoders] Proper mod versioning?
Hah, was that message stuck in your outbox for a few months?
garry
On Sun, Apr 13, 2008 at 1:15 AM, <[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
> >>
Re: [hlcoders] Proper mod versioning?
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
Re: [hlcoders] Proper mod versioning?
--
[ 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
Re: [hlcoders] Proper mod versioning?
-- [ 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
Re: [hlcoders] Proper mod versioning?
-- [ 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
Re: [hlcoders] Proper mod versioning?
-- [ 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
RE: [hlcoders] Proper mod versioning?
Think they are talking about before that function ever gets called (i.e. in the processes of connecting) -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Stephen Micheals Sent: Monday, December 10, 2007 2:40 PM To: hlcoders@list.valvesoftware.com Subject: Re: [hlcoders] Proper mod versioning? -- [ Picked text/plain from multipart/alternative ] the mod i'm working on currently is still in the alpha stages and we have yet to deal with this issue yet so excuse me if this idea is stupid or incorrect in a way. it is a bit hackish but what if you were to create a locked cvar on the client ( cl_clientversion for example ) witch is checked by the on connect if it is not equal to the current server version then send a vgui popup warning message to the client then disconnect them from the server. -- ___ 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
Re: [hlcoders] Proper mod versioning?
-- [ Picked text/plain from multipart/alternative ] the mod i'm working on currently is still in the alpha stages and we have yet to deal with this issue yet so excuse me if this idea is stupid or incorrect in a way. it is a bit hackish but what if you were to create a locked cvar on the client ( cl_clientversion for example ) witch is checked by the on connect if it is not equal to the current server version then send a vgui popup warning message to the client then disconnect them from the server. -- ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders
Re: [hlcoders] Proper mod versioning?
-- [ Picked text/plain from multipart/alternative ] Jeremy, by their lack of response it's obvious that Valve's not going to do this. You have options: - Include the version number in the game description string. It's not a tragedy if you do this. - Change the name of the game directory, such that clients will fail to even see servers of any other versions. - Write a small HTTP query to your central server which grabs the most recent version and displays a window to the user if necessary. - A billion jillion other things. Complaining about it and expecting Valve to do all the hard work for you won't solve the problem. -- Jorge "Vino" Rodriguez -- ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders
Re: [hlcoders] Proper mod versioning?
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: > > >> 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 > > >>> > > >
Re: [hlcoders] Proper mod versioning?
Doesn't the steam.inf file have something to do with versioning? garry On Dec 9, 2007 4:30 AM, 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: > > >> 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
Re: [hlcoders] Proper mod versioning?
-- [ 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: > >> 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 > >>> > > > >
Re: [hlcoders] Proper mod versioning?
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: 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 inc
Re: [hlcoders] Proper mod versioning?
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: 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 > > > >>
Re: [hlcoders] Proper mod versioning?
It was along time ago. - Original Message - From: "Nick" <[EMAIL PROTECTED]> To: 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 i
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 ve
Re: [hlcoders] Proper mod versioning?
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.
> > > >>
> > > >>
> > > >>
> > > >>
> > > >
Re: [hlcoders] Proper mod versioning?
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
Re: [hlcoders] Proper mod versioning?
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,
Re: [hlcoders] Proper mod versioning?
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
Re: [hlcoders] Proper mod versioning?
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
Re: [hlcoders] Proper mod versioning?
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
Re: [hlcoders] Proper mod versioning?
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
Re: [hlcoders] Proper mod versioning?
-- [ 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. -- Jorge "Vino" Rodriguez -- ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders
Re: [hlcoders] Proper mod versioning?
It's a bit hard to believe something so trivial as client->server versioning, with a useful error message isn't already supported in some form. Without blocking the game on your own http version queries or something. It ought to be as simple as the server checking the client version matches. Not all servers stay up to date, so simple nagging users they aren't on the latest version isn't useful. It should work for clients joining newer or older servers. if client version != server version show useful message. I was under the impression that the engine errors out with the class table error stuff before the user code has a chance to do something like this, which means it would need to be have engine level support. On Nov 17, 2007 10:57 AM, Tony omega Sergi <[EMAIL PROTECTED]> wrote: > whiel I'm not looking, I can only assume the [BETA] tihng is because > he's returning the game name as > Garry's Mod [BETA] > from GameRules::GetGameDescription() > > > On Nov 17, 2007 1:48 PM, <[EMAIL PROTECTED]> wrote: > > Yes, now that would be possible, but perhaps misleading in some scenarios. > > (It would of course require the mod author to maintain some > > globally-available server with the latest version, and then write the > > client code to do that check.) > > > > It's a slightly different scenario though than the one originally > > described, though. For instance if you had a beta version as mentioned > > below, you wouldn't get that message when on beta and connecting to > > non-beta, or you would get it erroneously when not on beta, etc. > > > > > > > > > > At 2007/11/17 12:40 PM, Christopher Harris wrote: > > >Or in the dll init function check for new version then display a message > > >box > > >saying there is a new version out. > > >- Original Message - > > >From: "Adam Maras (memzero)" <[EMAIL PROTECTED]> > > >To: > > >Sent: Saturday, November 17, 2007 1:34 PM > > >Subject: Re: [hlcoders] Proper mod versioning? > > > > > > > > >Well pardon my lack of knowledge on the situation, but couldn't you: > > >1. Set a version constant in the code > > >2. Check to see if the server and connecting client's version match > > >3. If they don't, disconnect with a custom message? > > > > > >Could all this occur before class table checking, like right on connect? > > > > > >// Adam Maras (memzero) > > > > > >[EMAIL PROTECTED] wrote: > > >>Well, you can always put the version number in the name of the server, > > >>which may be what he's doing? > > >> > > >>Really though what you want, per previous discussions, is a way to alert > > >>users to the existence of a new version when they try to connect and fail. > > >>And ideally a way to seamlessly perform the update via Steam. > > >> > > >>At 2007/11/17 11:54 AM, Adam Maras (memzero) wrote: > > >> > > >>>Garry's Mod beta (somehow) has [BETA] preceding the Game column contents > > >>>in the server, if I'm correct. Perhaps you could put the version in that > > >>>data field so that people can look specifically for servers of their > > >>>version. > > >>> > > >>>// Adam Maras (memzero) > > >>> > > >>>[EMAIL PROTECTED] wrote: > > >>> > > >>>>For what it's worth the last few times I asked this, the answer was > > >>>>basically "no". > > >>>> > > >>>>At 2007/11/15 10:39 AM, Jeremy wrote: > > >>>> > > >>>> > > >>>>>Is there a way to do proper mod versioning? > > >>>>> > > >>>>>Disconnect: Server uses different class tables. isn't a very useful > > >>>>>error message when clients try to join wrong version servers. > > >> > > >>___ > > >>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 > > > > > > > > -- > -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
Re: [hlcoders] Proper mod versioning?
whiel I'm not looking, I can only assume the [BETA] tihng is because he's returning the game name as Garry's Mod [BETA] from GameRules::GetGameDescription() On Nov 17, 2007 1:48 PM, <[EMAIL PROTECTED]> wrote: > Yes, now that would be possible, but perhaps misleading in some scenarios. > (It would of course require the mod author to maintain some > globally-available server with the latest version, and then write the client > code to do that check.) > > It's a slightly different scenario though than the one originally described, > though. For instance if you had a beta version as mentioned below, you > wouldn't get that message when on beta and connecting to non-beta, or you > would get it erroneously when not on beta, etc. > > > > > At 2007/11/17 12:40 PM, Christopher Harris wrote: > >Or in the dll init function check for new version then display a message box > >saying there is a new version out. > >- Original Message - > >From: "Adam Maras (memzero)" <[EMAIL PROTECTED]> > >To: > >Sent: Saturday, November 17, 2007 1:34 PM > >Subject: Re: [hlcoders] Proper mod versioning? > > > > > >Well pardon my lack of knowledge on the situation, but couldn't you: > >1. Set a version constant in the code > >2. Check to see if the server and connecting client's version match > >3. If they don't, disconnect with a custom message? > > > >Could all this occur before class table checking, like right on connect? > > > >// Adam Maras (memzero) > > > >[EMAIL PROTECTED] wrote: > >>Well, you can always put the version number in the name of the server, > >>which may be what he's doing? > >> > >>Really though what you want, per previous discussions, is a way to alert > >>users to the existence of a new version when they try to connect and fail. > >>And ideally a way to seamlessly perform the update via Steam. > >> > >>At 2007/11/17 11:54 AM, Adam Maras (memzero) wrote: > >> > >>>Garry's Mod beta (somehow) has [BETA] preceding the Game column contents > >>>in the server, if I'm correct. Perhaps you could put the version in that > >>>data field so that people can look specifically for servers of their > >>>version. > >>> > >>>// Adam Maras (memzero) > >>> > >>>[EMAIL PROTECTED] wrote: > >>> > >>>>For what it's worth the last few times I asked this, the answer was > >>>>basically "no". > >>>> > >>>>At 2007/11/15 10:39 AM, Jeremy wrote: > >>>> > >>>> > >>>>>Is there a way to do proper mod versioning? > >>>>> > >>>>>Disconnect: Server uses different class tables. isn't a very useful > >>>>>error message when clients try to join wrong version servers. > >> > >>___ > >>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 > > -- -omega ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders
Re: [hlcoders] Proper mod versioning?
Yes, now that would be possible, but perhaps misleading in some scenarios. (It would of course require the mod author to maintain some globally-available server with the latest version, and then write the client code to do that check.) It's a slightly different scenario though than the one originally described, though. For instance if you had a beta version as mentioned below, you wouldn't get that message when on beta and connecting to non-beta, or you would get it erroneously when not on beta, etc. At 2007/11/17 12:40 PM, Christopher Harris wrote: >Or in the dll init function check for new version then display a message box >saying there is a new version out. >- Original Message - >From: "Adam Maras (memzero)" <[EMAIL PROTECTED]> >To: >Sent: Saturday, November 17, 2007 1:34 PM >Subject: Re: [hlcoders] Proper mod versioning? > > >Well pardon my lack of knowledge on the situation, but couldn't you: >1. Set a version constant in the code >2. Check to see if the server and connecting client's version match >3. If they don't, disconnect with a custom message? > >Could all this occur before class table checking, like right on connect? > >// Adam Maras (memzero) > >[EMAIL PROTECTED] wrote: >>Well, you can always put the version number in the name of the server, >>which may be what he's doing? >> >>Really though what you want, per previous discussions, is a way to alert >>users to the existence of a new version when they try to connect and fail. >>And ideally a way to seamlessly perform the update via Steam. >> >>At 2007/11/17 11:54 AM, Adam Maras (memzero) wrote: >> >>>Garry's Mod beta (somehow) has [BETA] preceding the Game column contents >>>in the server, if I'm correct. Perhaps you could put the version in that >>>data field so that people can look specifically for servers of their >>>version. >>> >>>// Adam Maras (memzero) >>> >>>[EMAIL PROTECTED] wrote: >>> >>>>For what it's worth the last few times I asked this, the answer was >>>>basically "no". >>>> >>>>At 2007/11/15 10:39 AM, Jeremy wrote: >>>> >>>> >>>>>Is there a way to do proper mod versioning? >>>>> >>>>>Disconnect: Server uses different class tables. isn't a very useful >>>>>error message when clients try to join wrong version servers. >> >>___ >>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
Re: [hlcoders] Proper mod versioning?
No, as far as I can tell, the imbedded closed-source srcds.exe and hl2.exe class table checking stuff occurs before any user-controlled mod code is run. So you have no control over that process or that message. At 2007/11/17 12:34 PM, Adam Maras (memzero) wrote: >Well pardon my lack of knowledge on the situation, but couldn't you: >1. Set a version constant in the code >2. Check to see if the server and connecting client's version match >3. If they don't, disconnect with a custom message? > >Could all this occur before class table checking, like right on connect? > >// Adam Maras (memzero) > >[EMAIL PROTECTED] wrote: >>Well, you can always put the version number in the name of the server, which >>may be what he's doing? >> >>Really though what you want, per previous discussions, is a way to alert >>users to the existence of a new version when they try to connect and fail. >>And ideally a way to seamlessly perform the update via Steam. >> >>At 2007/11/17 11:54 AM, Adam Maras (memzero) wrote: >> >>>Garry's Mod beta (somehow) has [BETA] preceding the Game column contents >>>in the server, if I'm correct. Perhaps you could put the version in that >>>data field so that people can look specifically for servers of their >>>version. >>> >>>// Adam Maras (memzero) >>> >>>[EMAIL PROTECTED] wrote: >>> For what it's worth the last few times I asked this, the answer was basically "no". At 2007/11/15 10:39 AM, Jeremy wrote: >Is there a way to do proper mod versioning? > >Disconnect: Server uses different class tables. isn't a very useful >error message when clients try to join wrong version servers. >> >>___ >>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
Re: [hlcoders] Proper mod versioning?
Or in the dll init function check for new version then display a message box saying there is a new version out. - Original Message - From: "Adam Maras (memzero)" <[EMAIL PROTECTED]> To: Sent: Saturday, November 17, 2007 1:34 PM Subject: Re: [hlcoders] Proper mod versioning? Well pardon my lack of knowledge on the situation, but couldn't you: 1. Set a version constant in the code 2. Check to see if the server and connecting client's version match 3. If they don't, disconnect with a custom message? Could all this occur before class table checking, like right on connect? // Adam Maras (memzero) [EMAIL PROTECTED] wrote: Well, you can always put the version number in the name of the server, which may be what he's doing? Really though what you want, per previous discussions, is a way to alert users to the existence of a new version when they try to connect and fail. And ideally a way to seamlessly perform the update via Steam. At 2007/11/17 11:54 AM, Adam Maras (memzero) wrote: Garry's Mod beta (somehow) has [BETA] preceding the Game column contents in the server, if I'm correct. Perhaps you could put the version in that data field so that people can look specifically for servers of their version. // Adam Maras (memzero) [EMAIL PROTECTED] wrote: For what it's worth the last few times I asked this, the answer was basically "no". At 2007/11/15 10:39 AM, Jeremy wrote: Is there a way to do proper mod versioning? Disconnect: Server uses different class tables. isn't a very useful error message when clients try to join wrong version servers. ___ 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
Re: [hlcoders] Proper mod versioning?
Well pardon my lack of knowledge on the situation, but couldn't you: 1. Set a version constant in the code 2. Check to see if the server and connecting client's version match 3. If they don't, disconnect with a custom message? Could all this occur before class table checking, like right on connect? // Adam Maras (memzero) [EMAIL PROTECTED] wrote: Well, you can always put the version number in the name of the server, which may be what he's doing? Really though what you want, per previous discussions, is a way to alert users to the existence of a new version when they try to connect and fail. And ideally a way to seamlessly perform the update via Steam. At 2007/11/17 11:54 AM, Adam Maras (memzero) wrote: Garry's Mod beta (somehow) has [BETA] preceding the Game column contents in the server, if I'm correct. Perhaps you could put the version in that data field so that people can look specifically for servers of their version. // Adam Maras (memzero) [EMAIL PROTECTED] wrote: For what it's worth the last few times I asked this, the answer was basically "no". At 2007/11/15 10:39 AM, Jeremy wrote: Is there a way to do proper mod versioning? Disconnect: Server uses different class tables. isn't a very useful error message when clients try to join wrong version servers. ___ 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
Re: [hlcoders] Proper mod versioning?
Well, you can always put the version number in the name of the server, which may be what he's doing? Really though what you want, per previous discussions, is a way to alert users to the existence of a new version when they try to connect and fail. And ideally a way to seamlessly perform the update via Steam. At 2007/11/17 11:54 AM, Adam Maras (memzero) wrote: >Garry's Mod beta (somehow) has [BETA] preceding the Game column contents >in the server, if I'm correct. Perhaps you could put the version in that >data field so that people can look specifically for servers of their >version. > >// Adam Maras (memzero) > >[EMAIL PROTECTED] wrote: >>For what it's worth the last few times I asked this, the answer was basically >>"no". >> >>At 2007/11/15 10:39 AM, Jeremy wrote: >> >>>Is there a way to do proper mod versioning? >>> >>>Disconnect: Server uses different class tables. isn't a very useful >>>error message when clients try to join wrong version servers. ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders
Re: [hlcoders] Proper mod versioning?
Garry's Mod beta (somehow) has [BETA] preceding the Game column contents in the server, if I'm correct. Perhaps you could put the version in that data field so that people can look specifically for servers of their version. // Adam Maras (memzero) [EMAIL PROTECTED] wrote: For what it's worth the last few times I asked this, the answer was basically "no". At 2007/11/15 10:39 AM, Jeremy wrote: Is there a way to do proper mod versioning? Disconnect: Server uses different class tables. isn't a very useful error message when clients try to join wrong version servers. ___ 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
Re: [hlcoders] Proper mod versioning?
For what it's worth the last few times I asked this, the answer was basically "no". At 2007/11/15 10:39 AM, Jeremy wrote: >Is there a way to do proper mod versioning? > >Disconnect: Server uses different class tables. isn't a very useful >error message when clients try to join wrong version servers. > >___ >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
[hlcoders] Proper mod versioning?
Is there a way to do proper mod versioning? Disconnect: Server uses different class tables. isn't a very useful error message when clients try to join wrong version servers. ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders
