Ha! Valve hasn't made money off of mods? Have you lost your marbles?
http://www.steampowered.com/v/index.php?area=stats
See that "Counter-Strike" thing there at the top? That's a mod. Not
only did it bring in great revenue by itself once Valve "adopted" it,
but it also made Steam a legitimate and popular platform. Valve
wouldn't be in the position they are right now without HL1 mods and
millions and million of people playing them. With appropriate
resources, anyone can make a platform like Steam- The problem is
getting people to use it. HL1 mods are what got people using Steam.
People = Money. And now it has tons of games and that is very
beneficial to Valve. And it's not just CS- There are a ton of mods
throughout the years that contributed to the success of Valve's online
presence. Without the strong mod community in HL1, I would fancy a
guess that Steam would either not exist or would be an irrelevancy.
On Nov 21, 2007 6:36 PM, Nick <[EMAIL PROTECTED]> wrote:
> Now before people get upset. Valve helps mods a great deal, but
> clearly it isn't their top priority, nor should it be.
>
>
> On Nov 21, 2007 5:35 PM, Nick <[EMAIL PROTECTED]> wrote:
> > Since when did Valve ever make money off free mods? I really see no
> > reason for Valve to help mods that could and probably do compete
> > against Valve products?
> >
> >
> > On Nov 21, 2007 12:04 PM, <[EMAIL PROTECTED]> wrote:
> > > Indeed, that example falls in to the category of new version
> > > interpretations, or client/server havoc from differing incompatible code
> > > bases. I think we (and all the other modders out there) are in violent
> > > agreement on this one.
> > >
> > > It's just a question at this point as to what Valve's planning to do
> > > about it, since it's really out of the modders hands to have a reasonable
> > > solution here.
> > >
> > >
> > >
> > > At 2007/11/20 12:48 PM, Jeremy wrote:
> > > >It was a simple example, but it illustrates the trivial nature of what
> > > >it needs, which is simply a way for the engine to ask the mod for a
> > > >version number. Same thing as your example. It doesn't mean it
> > > >corresponds to the public release version number, just breaking
> > > >changes would need to change that, and not just class table changes or
> > > >user messages. Anything that alters the behavior of a game entities,
> > > >like our FF 1.1 to 1.11 we tweaked the assault cannon spinup time.
> > > >While technically not a breaking change in the sense that clients can
> > > >join 1.1 servers and not get an error, the different values on each
> > > >side result in awkward behavior, and the newer client would appear to
> > > >be shooting ineffectively earlier if the server was still using the
> > > >longer spinup time. It's not just a way to catch table mismatches
> > > >early, it's a way to keep client and servers in sync, and more
> > > >importantly, give clients an error message that means something.
> > > >There's no alternative to doing this but for the engine to ask the
> > > >mod. It's a bit short sighted that something like that doesn't already
> > > >exist.
> > > >
> > > >J
> > > >
> > > >On Nov 20, 2007 9:53 AM, <[EMAIL PROTECTED]> wrote:
> > > >> Your example is a bit misleading as to what would be needed. You
> > > >> shouldn't include version numbers in the description of the mod. You
> > > >> can always just add an sv_version cvar if you want a stringified
> > > >> representation of the version.
> > > >>
> > > >> The version that the srcds.exe/HL2.exe closed-source side of things
> > > >> would be concerned with would only be incremented when the new version
> > > >> was not backwards-compatible with the old version. Usually this would
> > > >> occur when class tables changed. It might also occur if usermessages
> > > >> needed to be interpreted differently, or perhaps if there were a
> > > >> critical bug of some sort in a client previous version and you wanted
> > > >> to prevent it from connecting to a new server and causing havoc. If
> > > >> the compatibility_version of the server differed from the client, then
> > > >> it would just pop up a message with a link to the "manual" or
> > > >> "developer_url" websites as defined in gameinfo.txt.
> > > >>
> > > >> ConVar sv_version("sv_version", "v6.1a beta");
> > > >> void GameRules::GetGameDescription(char*& description, int&
> > > >> compatibility_version)
> > > >> {
> > > >> description = "My Mod";
> > > >> compatibility_version = 4;
> > > >> }
> > > >>
> > > >>
> > > >> Another possibility would be to leverage some of the sv_pure
> > > >> functionality to allow for specification of a list of sha1sums of
> > > >> acceptable client.dll/server.dll on the client, for a given version of
> > > >> the server. The only downside there would be that you'd need to
> > > >> inform server hosts to add a new sha1sum to their server list every
> > > >> time a new client version was released.
> > > >>
> > > >>
> > > >>
> > > >>
> > > >> At 2007/11/17 02:05 PM, Jeffrey \"botman\" Broome wrote:
> > > >> >Jorge Rodriguez wrote:
> > > >> >>--
> > > >> >>[ Picked text/plain from multipart/alternative ]
> > > >> >>On 11/17/07, Jeremy <[EMAIL PROTECTED]> wrote:
> > > >> >>>It's a bit hard to believe something so trivial as client->server
> > > >> >>>versioning
> > > >> >>
> > > >> >>
> > > >> >>... trivial?
> > > >> >>
> > > >> >>I don't know where you got that idea.
> > > >> >
> > > >> >It could be trivial if GameRules::GetGameDescription() returned a
> > > >> >version number as well as a string...
> > > >> >
> > > >> >GameRules::GetGameDescription(char *Description, int *Version)
> > > >> >{
> > > >> > strcpy(Description, "My Mod v.83");
> > > >> > *Version = 83;
> > > >> >}
> > > >> >
> > > >> >The client would also need some way to return the version number to
> > > >> >the
> > > >> >engine so that it could check this when displaying servers (filtering
> > > >> >out servers that weren't running the same version as the client).
> > > >> >
> > > >> >--
> > > >> >Jeffrey "botman" Broome
> > >
> > > _______________________________________________
> > > To unsubscribe, edit your list preferences, or view the list archives,
> > > please visit:
> > > http://list.valvesoftware.com/mailman/listinfo/hlcoders
> > >
> > >
> >
>
> _______________________________________________
> To unsubscribe, edit your list preferences, or view the list archives, please
> visit:
> http://list.valvesoftware.com/mailman/listinfo/hlcoders
>
>
_______________________________________________
To unsubscribe, edit your list preferences, or view the list archives, please
visit:
http://list.valvesoftware.com/mailman/listinfo/hlcoders
