[TFC] Execution order of map configs reveresed

[pizzahut2]

This is a new client side issue which is caused by the bug fix for https://github.com/ValveSoftware/halflife/issues/2108 .

With developer 1 the console says that the game is executing mapdefault.cfg and then the current map's cfg file, however it actually executes them the other way round (1st map cfg file, then mapdefault.cfg ).

This partially defeats the purpose of having a default cfg file for maps. Individual settings made in a map's config are overruled by the mapdefault.cfg .

[vilhelmgray]

I would imagine porting HL1 to Source 2 would be more of a hassle than simply releasing GoldSource under an open source license, since the former would require a certain amount of man-hours to accomplish while the latter is just uploading the code to Github with the new license.

It would be nice to know whether there are technical reasons why GoldSource cannot be released under an open source license (e.g. a patent hurdle similar to the Doom 3 shadow volume code fiasco) or whether it's purely a philosophical desire to keep the code proprietary. This would help users better understand the challenge of open sourcing GoldSource.

[patch6]

I'm interested in TFC source as well. Hoping to develop for it. Some kind of revival for the game.

[sergei-bondarenko]

Open sourcing is a possibility though it will likely take some time to work out, though I did speak to Alfred a bit about it before so I'm aware of some of what that would entail. I'll open a new issue to discuss it if and when I have more information.

@mikela-valve, is there any news on this? The number of likes under your post indicates a lot of interest in open sourcing GoldSrc. It's an ancient engine, I doubt it can still generate much revenue for Valve, but publishing it out would be a huge public good and enhance the company's reputation for "doing the right thing". I hope we can get it eventually into the public domain.

[julcioo]

@mikela-valve sorry to post on a closed issue, but since this is where open sourcing was discussed i'm putting it here: if open sourcing GoldSource is not an option it might be a good idea to consider porting HL1 to Source 2 instead and allowing us to make mods for it on that engine instead. Source 2 is much more powerful so i think it could be a suitable alternative.

I don't know if Valve is still planning to make Source 2 available for free for non-commercial use but that would make making mods a lot easier without the hassle of having to open source GoldSource.

Allowing content from Valve games built on GoldSource and Source to be ported to Source 2 for use in mods would be a big plus for Source 2 modding as well as HL1 and HL2 modding since it unifies all modding on the most powerful platform, and it would encourage people to move over and write documentation and tutorials which Source 2 will probably need since it's brand new.

I think the reason people like these games is because they are on an engine that works like they remember. If we port the game to an engine like Source 2 (possibly 3 ?), not everybody will be happy about it.

[blackletum]

Hey @SamVanheer, first off, sorry for the lack of communication. I'd intentionally withheld the first set of patch notes temporarily and had hoped to release them shortly after this release cycle settled down a bit but that went on much longer than I'd intended. I plan to have a complete set of patch notes covering the last set of releases posted on Monday. I'll also be actively updating issues that I work on here in the future.

What I'd hoped to accomplish from this release set was to establish a high water mark for how secure things will be then dial anything back that is too restrictive, this issue being a prime example of that. For the moment I thought that moving the script exec'ing from TFC into the engine was safest since it retains the current behaviour while removing the requirement for the client to trust the configs specified by the server.

Regarding allowing mods to configure whether or not exec is allowed, what I worry about is that it's putting a bit too much trust back into the server, though I do agree that there should be a way for users directly or through mods to be able to enable more functionality. One possibility I was thinking of was allowing the client to specify a whitelist of allowed config files, but I'd definitely be open to suggestions.

Open sourcing is a possibility though it will likely take some time to work out, though I did speak to Alfred a bit about it before so I'm aware of some of what that would entail. I'll open a new issue to discuss it if and when I have more information.

Last, as @pizzahut2 pointed out, server owners aren't using the latest TFC versions (which I unfortunately wasn't aware of, sorry) which obviously doesn't work well with the engine change so I've fixed #1070 in the latest TFC beta released today which I'll promote to public on Monday if things seem to be working well over the weekend. If there are other issues that are similarly blocking adoption of newer versions, please let me know and I'll prioritize them accordingly. I also have changes staged for several other issues that I should be able to release to beta soon, which I'll be sure to mark the associated issues for.

It's awesome to see the dedication and passion for these games, so I'll definitely be doing what I can to support the community going forward.

Just to let you know, the community at large would still love to see this come to open source. I personally believe it would bring a renaissance of old-school indie games.