Well considering they shutdown CS:Classic Offensive and the Alyx SDK is half assed I doubt they care about modding anymore.
On Sat, 12 Jul 2025 at 01:06, Half-Life Coders Mailing List < [email protected]> wrote: > Future of mod support <#m_8054334965537689920_msg31097256> - Sam V *(11 > Jul 2025 13:59 UTC)* > Re: [hlcoders] Future of mod support <#m_8054334965537689920_msg31100044> - > Andrew > McWatters *(11 Jul 2025 15:42 UTC)* > Re: [hlcoders] Future of mod support <#m_8054334965537689920_msg31100315> - > Andrew > McWatters *(11 Jul 2025 15:50 UTC)* > ------------------------------ > Future of mod support > <https://list.valvesoftware.com/hlcoders/msg/31097256/> by Sam V > <[email protected]> *(11 Jul 2025 13:58 UTC)* > Reply to list > <[email protected]?Subject=Re:+Future+of+modsupport&References=%3CAM0PR08MB52687F935DE3DB1B9A37C8A5834BA%40AM0PR08MB5268.eurprd08.prod.outlook.com%3E> > > > I see this mailing list has been inactive for over a year, but i > thought i'd take a shot at this: > > Is there a future for game modding as far as Valve games are > concerned? I'm referring specifically to making entire mods, not making > maps or models. > > When the HL1 25th anniversary updates released we could see there were > hidden branches for other GoldSource engine games that ultimately weren't > released. Those branches are now completely hidden due to changes in how > Steam handles them. > > Some changes like the enabling of asserts have made HL1 modding even > more confusing than before since it now adds more errors that people can't > make sense of. > > There are a lot of bugs that could be fixed, some of the changes made > in the anniversary update were also imposed on other games (like the weapon > bobbing change) which isn't what anybody was asking for. > > Valve employees have mentioned open sourcing before and we got a > response from an employee on the Half-Life issue tracker that they would > look into it way back in 2019: > > https://github.com/ValveSoftware/halflife/issues/2112#issuecomment-482718243 > > Nothing ever came of that. > > Based on how and when Valve does communicate we will never get a > response if it's negative, so it's safe to assume that somewhere along the > line there is a roadblock or someone who does not want the engine open > sourced. > > While it would be nice to have that happen, i don't expect it will. > Conversely, it would be nice to get a definitive "no" so we can tell > everyone to stop wasting their time on a dead game, but i doubt that's > going to happen. > > Instead, i'd like to point out another option. Steam is missing a > developer feature that would make it easier to manage different versions of > a game. Users can only install one version of a game at a time and have to > switch branches to play another version, which requires users to > (re-)download changed files. > > There is a recently added API that lets developers switch branches on > behalf of the user but that still involves changes the single copy of the > game. > > A couple examples: > HL1 legacy and anniversary versions (made worse because all GoldSource > games use the engine binaries from HL1 so switching branches for that game > doesn't change the engine) > CSGO and CS2 ARMA 3 current, previous and dev versions ( > https://community.bistudio.com/wiki/Arma_3:_Steam_Branches) > > Unity for instance lets you switch engine versions through the hub. If > someone were to distribute a developer tool like an engine or level editor > through Steam and there are different versions then you'd have to > re-download the version you want to use when switching. > > Why do i bring this up? To justify having Valve work on making a new > version of GoldSource. Steam could use a feature like this. And when > developing such a feature you could develop a new version of GoldSource to > test it. > > You can make a new engine branch that strips out anything that's > non-functional or obsolete (some engine functions do nothing, VGUI1 can be > replaced with VGUI2), HLTV is pretty much useless (HL has a handful of > empty servers with it enabled, CS servers are apparently glitched and > refreshing the server in the browser changes the title so it's probably > broken), GameUI can be moved to the client dll, the save game system can be > moved so modders have full control over what gets saved and how, and > anything game-specific can be moved into the SDK (physics, entity > networking, loads of stuff). > > This new engine branch can have its own version of the SDK, a new > Hammer build that's compatible with today's operating systems (it would be > better if it were open source so we can fix it and make it better!), a > decent renderer that uses modern hardware properly and properly supports > custom graphics code (i'm talking shaders, buffers, post-processing > effects, all that stuff), with higher limits, and so on and so forth. > > You can eliminate problems like TGA files needing a specific origin > setting to load properly, allow full-color images everywhere instead of 256 > color images and streamline a lot of stuff. > > Valve games can have new versions made that use the new engine in a > self-contained manner. You could install the version of CS 1.6 based on > this engine branch and it would have its own set of engine binaries that > are affected by neither HL1 nor the engine branch that mods are based on. > You can fix games without breaking other games and without breaking mods. > > You can also make community-made projects obsolete if you tackle the > problems they were created to deal with. > > This would also allow VAC to be turned on again (it seems to be turned > off for GoldSource engine games, probably due to mods using extra dlls, so > you shouldn't enable it there) and made stricter than before without > breaking mods that run on the current engine. > > There would need to be a way to have server plugins work with VAC > thrown in the mix which means you'll have to work with the community to > design a good way to integrate that and provide functionality that modders > need and currently implement by way of hooking into the engine. > > So you'd have a new version for every GoldSource engine game (HL1, CS, > TFC and so on) plus a separate engine that mods run on (like Source SDK > Base apps), with the first version being a clone of HL1 and subsequent > updates bringing in updated versions of the engine. Instead of having to > make a new app for every major update you have one app with different > versions that can be installed side by side. Obviously you'd need a way to > locate the right version so mods can locate assets and launch with the > right engine (and automatically have Steam download it if you try to launch > a mod that uses a non-installed version). Ideally mods would be installed > outside the engine installation (like Source mods) because that's caused > enough problems with overwriting files and mods stomping on each-other's > third party dlls (like FMOD). > > Building tools to let developers work better using Steam is something > that Valve does very well, using it to motivate developing new versions of > these old games is a bonus. > > I realize i'm probably screaming into the void, but i thought i'd give > folks over at Valve a good reason to work on these games. > > I've spent enough time trying to help people, watching them try to > make games on this engine knowing what they want to do can't be done > without some serious hacks, all the way up to basically building a new > engine. If open sourcing is not an option then this is the best way i can > think of to help them. > > I've only mentioned GoldSource engine games but you can do this for > Source games as well, though that would be a lot more work. Source recently > got updates so maybe it doesn't need more attention, i'd ask Source modders > for feedback on that. > > Now, i've already mentioned this above but i'll say it again. If you > won't provide support, you can at least tell us so nobody wastes their time > trying to figure out a way forward in a dead end. > > People just want to be creative with these games but the tech is so > old it belongs in a museum. People aren't porting CS 1.6 to Source to break > the law or violate licenses, they want a version of the game that runs on > an engine that can make proper use of even 15 year old hardware and has > limits to match. > > If you won't provide them with a solution they'll go work on one > themselves, and then you end up having to shut them down after years of > work. Nobody wins in a situation like that. > > You can solve a bunch of problems here and build a framework that > makes fixing these games in the future a lot easier. Surely there must be > value in that. If not, then at least we tried to make this happen. But if > any future attempts are a waste of time, you ought to tell us. > > ------------------------------ > Re: [hlcoders] Future of mod support > <https://list.valvesoftware.com/hlcoders/msg/31100044/> by Andrew > McWatters <[email protected]> *(11 Jul 2025 15:42 UTC)* > Reply to list > <[email protected]?Subject=Re:+[hlcoders]Future+of+modsupport&References=%3CAM0PR08MB52687F935DE3DB1B9A37C8A5834BA%40AM0PR08MB5268.eurprd08.prod.outlook.com%3E%20%3CBL0PR01MB449717ECDD7E7C18052C1627F34BA%40BL0PR01MB4497.prod.exchangelabs.com%3E> > > > Hi Sam, > I know other modders still follow this mailing list, so I hope some of > them chime in as well. > I worked on the team that built a mod called Half-Life 2: Sandbox. We > last shipped an update in December 2024, and I really don’t want to do it > again. We thought it was safe, since the 2013 branch hadn’t been updated in > 10 years. And then, the day after we released our update, someone at Valve > decided to push a new update to that very same old branch. Incredible > timing. What a great experience. > Honestly, I don’t think there’s a future in modding Valve games. At > various points, I'm not exactly sure when; I could probably piece it > together if I sat down and documented it, several changes were made that > made it increasingly difficult to ship mods. Doors that had been open to > previous developers and teams were gradually closed, making it harder not > just to build, but also to monetize our work. > I may have the order of events wrong. Maybe someone else can clarify > the history better than I can. > The biggest change, I think, was the staff turnover. That’s just part > of life, but it had real consequences. We noticed it directly through our > interactions with people working on the Source SDK. Some individuals who > could have helped us likely weren't even accessible, and once no one at > Valve was actively maintaining the SDK or pushing cleaned-up code drops > from internal Perforce repositories, development basically stalled. I > believe Tony Sergi was the main Source SDK contractor, and he was > incredibly helpful and kind in my experience. But most of Valve doesn’t > work on the non-licensee SDK, and most aren’t subscribed to this list. So, > whoever we had here was who we had. The rest of Valve was hard to reach. > You might have been able to reach someone at Facepunch years ago, but that > was rare too. > Then came SteamPipe, which broke a lot of mods. The abstraction layers > intended to keep them running weren’t tested with the broader modding > community, so backwards compatibility suffered. Many of those older teams > were long gone and weren't coming back to fix what Valve broke. The only > way to play some of those mods was to go to cs.rin.ru, download a > Steam.dll crack, extract assets from the old .gcf files, and run the mods > manually. > Hunt Down the Freeman was so poorly received that Valve stopped > allowing monetization of Half-Life 2 mods entirely. Around that time, they > also closed the door on modding other Valve IPs. So, if you built something > you thought was promising and considered investing the $50,000 for a Source > 1 license plus sublicenses for sound and physics, Valve's business > development team would basically tell you to make a total conversion > instead. If your project relied on the look, feel, or lore of the > Half-Life universe, you were dead in the water. > The shift toward promoting user-generated content workflows over > traditional mods happened slowly but deliberately, as Valve extended > systems originally built for Team Fortress 2 into other titles and stopped > supporting modders through updates or tools. > There used to be a pipeline, whether or not it was official, that > encouraged modders to build great projects. Some of those became full > games, a few of which Valve even acquired. That pipeline no longer exists. > I know some developers still release free mod updates and do excellent > work, but I also know many would have preferred to sell what they built. > Most people have moved on. These days, we work in Unreal, Unity, or > even custom engines, just like the rest of the industry. If you're really > passionate about shipping games, I would recommend that you learn from some > of the mistakes a few of us have made here and build your intellectual > property on more reliable software. > Best, > Andrew McWatters > https://www.planimeter.org/ > From: [email protected] <[email protected]> > on behalf of Sam V <[email protected]> > Sent: Friday, July 11, 2025 6:58 AM > To: Discussion of Half-Life Programming < > [email protected]> > Subject: [hlcoders] Future of mod support > > > I see this mailing list has been inactive for over a year, but i > thought i'd take a shot at this: > > Is there a future for game modding as far as Valve games are > concerned? I'm referring specifically to making entire mods, not making > maps or models. > > When the HL1 25th anniversary updates released we could see there were > hidden branches for other GoldSource engine games that ultimately weren't > released. Those branches are now completely hidden due to changes in how > Steam handles them. > > Some changes like the enabling of asserts have made HL1 modding even > more confusing than before since it now adds more errors that people can't > make sense of. > > There are a lot of bugs that could be fixed, some of the changes made > in the anniversary update were also imposed on other games (like the weapon > bobbing change) which isn't what anybody was asking for. > > Valve employees have mentioned open sourcing before and we got a > response from an employee on the Half-Life issue tracker that they would > look into it way back in 2019: > > https://github.com/ValveSoftware/halflife/issues/2112#issuecomment-482718243 > > Nothing ever came of that. > > Based on how and when Valve does communicate we will never get a > response if it's negative, so it's safe to assume that somewhere along the > line there is a roadblock or someone who does not want the engine open > sourced. > > While it would be nice to have that happen, i don't expect it will. > Conversely, it would be nice to get a definitive "no" so we can tell > everyone to stop wasting their time on a dead game, but i doubt that's > going to happen. > > Instead, i'd like to point out another option. Steam is missing a > developer feature that would make it easier to manage different versions of > a game. Users can only install one version of a game at a time and have to > switch branches to play another version, which requires users to > (re-)download changed files. > > There is a recently added API that lets developers switch branches on > behalf of the user but that still involves changes the single copy of the > game. > > A couple examples: > HL1 legacy and anniversary versions (made worse because all GoldSource > games use the engine binaries from HL1 so switching branches for that game > doesn't change the engine) > CSGO and CS2ARMA 3 current, previous and dev versions ( > https://community.bistudio.com/wiki/Arma_3:_Steam_Branches) > > Unity for instance lets you switch engine versions through the hub. If > someone were to distribute a developer tool like an engine or level editor > through Steam and there are different versions then you'd have to > re-download the version you want to use when switching. > > Why do i bring this up? To justify having Valve work on making a new > version of GoldSource. Steam could use a feature like this. And when > developing such a feature you could develop a new version of GoldSource to > test it. > > You can make a new engine branch that strips out anything that's > non-functional or obsolete (some engine functions do nothing, VGUI1 can be > replaced with VGUI2), HLTV is pretty much useless (HL has a handful of > empty servers with it enabled, CS servers are apparently glitched and > refreshing the server in the browser changes the title so it's probably > broken), GameUI can be moved to the client dll, the save game system can be > moved so modders have full control over what gets saved and how, and > anything game-specific can be moved into the SDK (physics, entity > networking, loads of stuff). > > This new engine branch can have its own version of the SDK, a new > Hammer build that's compatible with today's operating systems (it would be > better if it were open source so we can fix it and make it better!), a > decent renderer that uses modern hardware properly and properly supports > custom graphics code (i'm talking shaders, buffers, post-processing > effects, all that stuff), with higher limits, and so on and so forth. > > You can eliminate problems like TGA files needing a specific origin > setting to load properly, allow full-color images everywhere instead of 256 > color images and streamline a lot of stuff. > > Valve games can have new versions made that use the new engine in a > self-contained manner. You could install the version of CS 1.6 based on > this engine branch and it would have its own set of engine binaries that > are affected by neither HL1 nor the engine branch that mods are based on. > You can fix games without breaking other games and without breaking mods. > > You can also make community-made projects obsolete if you tackle the > problems they were created to deal with. > > This would also allow VAC to be turned on again (it seems to be turned > off for GoldSource engine games, probably due to mods using extra dlls, so > you shouldn't enable it there) and made stricter than before without > breaking mods that run on the current engine. > > There would need to be a way to have server plugins work with VAC > thrown in the mix which means you'll have to work with the community to > design a good way to integrate that and provide functionality that modders > need and currently implement by way of hooking into the engine. > > So you'd have a new version for every GoldSource engine game (HL1, CS, > TFC and so on) plus a separate engine that mods run on (like Source SDK > Base apps), with the first version being a clone of HL1 and subsequent > updates bringing in updated versions of the engine. Instead of having to > make a new app for every major update you have one app with different > versions that can be installed side by side. Obviously you'd need a way to > locate the right version so mods can locate assets and launch with the > right engine (and automatically have Steam download it if you try to launch > a mod that uses a non-installed version). Ideally mods would be installed > outside the engine installation (like Source mods) because that's caused > enough problems with overwriting files and mods stomping on each-other's > third party dlls (like FMOD). > > Building tools to let developers work better using Steam is something > that Valve does very well, using it to motivate developing new versions of > these old games is a bonus. > > I realize i'm probably screaming into the void, but i thought i'd give > folks over at Valve a good reason to work on these games. > > I've spent enough time trying to help people, watching them try to > make games on this engine knowing what they want to do can't be done > without some serious hacks, all the way up to basically building a new > engine. If open sourcing is not an option then this is the best way i can > think of to help them. > > I've only mentioned GoldSource engine games but you can do this for > Source games as well, though that would be a lot more work. Source recently > got updates so maybe it doesn't need more attention, i'd ask Source modders > for feedback on that. > > Now, i've already mentioned this above but i'll say it again. If you > won't provide support, you can at least tell us so nobody wastes their time > trying to figure out a way forward in a dead end. > > People just want to be creative with these games but the tech is so > old it belongs in a museum. People aren't porting CS 1.6 to Source to break > the law or violate licenses, they want a version of the game that runs on > an engine that can make proper use of even 15 year old hardware and has > limits to match. > > If you won't provide them with a solution they'll go work on one > themselves, and then you end up having to shut them down after years of > work. Nobody wins in a situation like that. > > You can solve a bunch of problems here and build a framework that > makes fixing these games in the future a lot easier. Surely there must be > value in that. If not, then at least we tried to make this happen. But if > any future attempts are a waste of time, you ought to tell us. > > _______________________________________________ > > To unsubscribe, edit your list preferences, or view the list archives, > > please visit: > > https://list.valvesoftware.com/ > > ------------------------------ > Re: [hlcoders] Future of mod support > <https://list.valvesoftware.com/hlcoders/msg/31100315/> by Andrew > McWatters <[email protected]> *(11 Jul 2025 15:50 UTC)* > Reply to list > <[email protected]?Subject=Re:+[hlcoders]Future+of+modsupport&References=%3CAM0PR08MB52687F935DE3DB1B9A37C8A5834BA%40AM0PR08MB5268.eurprd08.prod.outlook.com%3E%20%3CBL0PR01MB4497CE0520ABF027CA2A7142F34BA%40BL0PR01MB4497.prod.exchangelabs.com%3E> > > > Sorry! I realize now you must be Sam Vanheer. So, my reply was mostly > preaching to the choir. > I hope you get better responses. > Best, > Andrew > From: [email protected] <[email protected]> > on behalf of Sam V <[email protected]> > Sent: Friday, July 11, 2025 6:58 AM > To: Discussion of Half-Life Programming < > [email protected]> > Subject: [hlcoders] Future of mod support > > > I see this mailing list has been inactive for over a year, but i > thought i'd take a shot at this: > > Is there a future for game modding as far as Valve games are > concerned? I'm referring specifically to making entire mods, not making > maps or models. > > When the HL1 25th anniversary updates released we could see there were > hidden branches for other GoldSource engine games that ultimately weren't > released. Those branches are now completely hidden due to changes in how > Steam handles them. > > Some changes like the enabling of asserts have made HL1 modding even > more confusing than before since it now adds more errors that people can't > make sense of. > > There are a lot of bugs that could be fixed, some of the changes made > in the anniversary update were also imposed on other games (like the weapon > bobbing change) which isn't what anybody was asking for. > > Valve employees have mentioned open sourcing before and we got a > response from an employee on the Half-Life issue tracker that they would > look into it way back in 2019: > > https://github.com/ValveSoftware/halflife/issues/2112#issuecomment-482718243 > > Nothing ever came of that. > > Based on how and when Valve does communicate we will never get a > response if it's negative, so it's safe to assume that somewhere along the > line there is a roadblock or someone who does not want the engine open > sourced. > > While it would be nice to have that happen, i don't expect it will. > Conversely, it would be nice to get a definitive "no" so we can tell > everyone to stop wasting their time on a dead game, but i doubt that's > going to happen. > > Instead, i'd like to point out another option. Steam is missing a > developer feature that would make it easier to manage different versions of > a game. Users can only install one version of a game at a time and have to > switch branches to play another version, which requires users to > (re-)download changed files. > > There is a recently added API that lets developers switch branches on > behalf of the user but that still involves changes the single copy of the > game. > > A couple examples: > HL1 legacy and anniversary versions (made worse because all GoldSource > games use the engine binaries from HL1 so switching branches for that game > doesn't change the engine) > CSGO and CS2ARMA 3 current, previous and dev versions ( > https://community.bistudio.com/wiki/Arma_3:_Steam_Branches) > > Unity for instance lets you switch engine versions through the hub. If > someone were to distribute a developer tool like an engine or level editor > through Steam and there are different versions then you'd have to > re-download the version you want to use when switching. > > Why do i bring this up? To justify having Valve work on making a new > version of GoldSource. Steam could use a feature like this. And when > developing such a feature you could develop a new version of GoldSource to > test it. > > You can make a new engine branch that strips out anything that's > non-functional or obsolete (some engine functions do nothing, VGUI1 can be > replaced with VGUI2), HLTV is pretty much useless (HL has a handful of > empty servers with it enabled, CS servers are apparently glitched and > refreshing the server in the browser changes the title so it's probably > broken), GameUI can be moved to the client dll, the save game system can be > moved so modders have full control over what gets saved and how, and > anything game-specific can be moved into the SDK (physics, entity > networking, loads of stuff). > > This new engine branch can have its own version of the SDK, a new > Hammer build that's compatible with today's operating systems (it would be > better if it were open source so we can fix it and make it better!), a > decent renderer that uses modern hardware properly and properly supports > custom graphics code (i'm talking shaders, buffers, post-processing > effects, all that stuff), with higher limits, and so on and so forth. > > You can eliminate problems like TGA files needing a specific origin > setting to load properly, allow full-color images everywhere instead of 256 > color images and streamline a lot of stuff. > > Valve games can have new versions made that use the new engine in a > self-contained manner. You could install the version of CS 1.6 based on > this engine branch and it would have its own set of engine binaries that > are affected by neither HL1 nor the engine branch that mods are based on. > You can fix games without breaking other games and without breaking mods. > > You can also make community-made projects obsolete if you tackle the > problems they were created to deal with. > > This would also allow VAC to be turned on again (it seems to be turned > off for GoldSource engine games, probably due to mods using extra dlls, so > you shouldn't enable it there) and made stricter than before without > breaking mods that run on the current engine. > > There would need to be a way to have server plugins work with VAC > thrown in the mix which means you'll have to work with the community to > design a good way to integrate that and provide functionality that modders > need and currently implement by way of hooking into the engine. > > So you'd have a new version for every GoldSource engine game (HL1, CS, > TFC and so on) plus a separate engine that mods run on (like Source SDK > Base apps), with the first version being a clone of HL1 and subsequent > updates bringing in updated versions of the engine. Instead of having to > make a new app for every major update you have one app with different > versions that can be installed side by side. Obviously you'd need a way to > locate the right version so mods can locate assets and launch with the > right engine (and automatically have Steam download it if you try to launch > a mod that uses a non-installed version). Ideally mods would be installed > outside the engine installation (like Source mods) because that's caused > enough problems with overwriting files and mods stomping on each-other's > third party dlls (like FMOD). > > Building tools to let developers work better using Steam is something > that Valve does very well, using it to motivate developing new versions of > these old games is a bonus. > > I realize i'm probably screaming into the void, but i thought i'd give > folks over at Valve a good reason to work on these games. > > I've spent enough time trying to help people, watching them try to > make games on this engine knowing what they want to do can't be done > without some serious hacks, all the way up to basically building a new > engine. If open sourcing is not an option then this is the best way i can > think of to help them. > > I've only mentioned GoldSource engine games but you can do this for > Source games as well, though that would be a lot more work. Source recently > got updates so maybe it doesn't need more attention, i'd ask Source modders > for feedback on that. > > Now, i've already mentioned this above but i'll say it again. If you > won't provide support, you can at least tell us so nobody wastes their time > trying to figure out a way forward in a dead end. > > People just want to be creative with these games but the tech is so > old it belongs in a museum. People aren't porting CS 1.6 to Source to break > the law or violate licenses, they want a version of the game that runs on > an engine that can make proper use of even 15 year old hardware and has > limits to match. > > If you won't provide them with a solution they'll go work on one > themselves, and then you end up having to shut them down after years of > work. Nobody wins in a situation like that. > > You can solve a bunch of problems here and build a framework that > makes fixing these games in the future a lot easier. Surely there must be > value in that. If not, then at least we tried to make this happen. But if > any future attempts are a waste of time, you ought to tell us. > > _______________________________________________ > > To unsubscribe, edit your list preferences, or view the list archives, > > please visit: > > https://list.valvesoftware.com/ > > ------------------------------ > > _______________________________________________ > > To unsubscribe, edit your list preferences, or view the list archives, > > please visit: > > https://list.valvesoftware.com/ > _______________________________________________ To unsubscribe, edit your list preferences, or view the list archives, please visit: https://list.valvesoftware.com/
