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: hlcoders@list.valvesoftware.com <hlcoders@list.valvesoftware.com> on behalf of Sam V <duo...@hotmail.com> Sent: Friday, July 11, 2025 6:58 AM To: Discussion of Half-Life Programming <hlcoders@list.valvesoftware.com> 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: 1. 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) 2. CSGO and CS2 3. 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. _______________________________________________ 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/
