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: 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/
