Please stop trying to defeat AMX "exploits" - you're just breaking classic mods

[Wasdsensei]

The last couple of patches, apparently aimed at fixing various malicious AMX scripts, broke much of the functionality of our game, and we don't even allow AMX on our mod's servers. (Specifically: http://www.msremake.com/ )

For instance, you added this "feature" to prevent the server from sending certain commands to the client console. Neglecting the fact that, short of writing and distributing an entirely separate program, alias script commands, such as "disconnect", and "wait", and "reconnect", are the only way to automate procedures, such as a delayed reconnect, as once a client disconnects, the mod DLL is no longer in control. Our MPRPG mod requires such a delayed reconnect to prevent character corruption. As a result of your "security fix", we're now seeing character corruption on an almost daily basis (as seen yonder: http://www.msremake.com/forums/viewforum.php?f=32 - The dreaded "5hp bug", that cropped up well between patches on our side).

And, apparently in an effort to stop server scripts from modifying client's files, you moved the resource downloads to an independent folder "_downloads". This breaks our map authentication process when the map in question is acquired from the server. It also breaks any other mod checking specific folders for media, independent of engine calls, that the authors presumed would be downloaded into the mod's own path, as was the case for nearly two decades.

Seems you've also done something to prevent the server from shutting itself down normally. Not sure what that's about yet, but it's similarly, re-opened whole can of worms we had managed to close ages ago (seven years and six months ago, to be precise)...

Again, mind ye, none of these are AMX script processes being ranted on about here - you are instead breaking our core DLL functionality with these efforts.

Now, we're an actively updating mod - probably among the last active third party Goldsrc mods, so we can fix some of this. (Well, the downloaded resource redirection, at least, I think we can compensate for... The other two are proving more of a challenge...) However, as one of the last actively developed Goldsrc mods, dealing with this frustration, I feel the need to remind you all of something:

\ THIS IS A LEGACY PRODUCT! **

Your primary goal, should be, first and foremost, retaining legacy compatibility. This engine is not some young minx, where you can expect everyone to just get up and update their mods, each and every time you change something. Some of the most popular mods attached to this engine haven't been updated in nearly two decades. Hell, in a lot of cases, the people who made those mods are probably dead, and the source code buried along with them.

So please, stop it with the "security upgrades". The worst anyone can do with the AMX exploits you are patching, is make it so a non-savvy client would have to reinstall his game. Malicious scripters are still fully capable of deleting a client's system32 folder though meta, or something similarly devastating to their whole system, as are we on the DLL coder end (even more so). Thus, there's no reason to destroy near twenty years worth of classic mods, just to prevent what's never amounted to more than a minor annoyance, especially when it does nothing to prevent anything that could be an actual threat.

This is more of a request that you change your (re)design philosophy than a bug report. You aren't achieving anything positive with these sorts of efforts - you're just breaking more and more classic games.

I'm sure Valve has you under orders not to do anything to expand the visual capabilities of the engine (as that'd eventually run you down a slippery slope of getting into Source's territory), but if you want to do something constructive for the legacy Half-Life community, instead of breaking classic games, maybe you could instead concentrate on fixing limitations of the engine that aren't visual, but nonetheless cripple a lot of these games. Such as the edict limit or the precache model/sprite/sound count limit - that sorta thing. Things that will let you help keep this massive library of neigh infinite nostalgia afloat, and allow people to go back and improve those classic games, without stepping on Source's toes.

That'd at least give people more motivation to actually buy Half-Life, when they see the mods they loved as children are still being played and expanded upon, but what you're doing now is destroying that one motivation to spend another $10 on Steam, in an effort to stop a handful script kiddy trolls, who, really, probably haven't even existed for half a decade or more.

Sorry for the rant, I apologize, but I've lost a lot of hair over this, and when a change in the engine end breaks something, I tend to get the blame... So please, don't let an old modder fart go bald.

[bolokanar]

You probably talk about cl_filterstuffcmd. In my opinion that's a necessary feature. Servers have gone out of line with all the command flood nowdays.

Perhaps what you should demand is a "legacy" branch added next to the "beta". Containing the CS files prior to last changes, meaning before they started changing stuff.

[ghost]

Since when does Valve cater to server admins running third-party addons?

[JoelTroch]

I'm sure Valve has you under orders not to do anything to expand the visual capabilities of the engine (as that'd eventually run you down a slippery slope of getting into Source's territory), but if you want to do something constructive for the legacy Half-Life community, instead of breaking classic games, maybe you could instead concentrate on fixing limitations of the engine that aren't visual, but nonetheless cripple a lot of these games. Such as the edict limit or the precache model/sprite/sound count limit - that sorta thing. Things that will let you help keep this massive library of neigh infinite nostalgia afloat, and allow people to go back and improve those classic games, without stepping on Source's toes.

If engine limits are a problem for you, either you switch to Xash3D, they extended most of the limits and your game will be standalone and will not depend on standard GoldSrc and Steam, but you will have to release the source code under the GPL licence because Xash3D is using it OR you try to write your own "files and entities managers" to bypass those limits.

[Wasdsensei]

@sudoku173

Since when does Valve cater to server admins running third-party addons?

Since when does Valve try to stop them from doing so? And break mods in the process? Well, since about February 2013, apparently.

@JoelTroch

If engine limits are a problem for you, either you switch to Xash3D

Nice option, for new mods being written from scratch, and a nice challenge for the Xash3D devs, attempting to broaden compatibility. But for existing mods, and when the Xash dev efforts fail, no dice.

Of the few mods that survive, quite a few are prone to crashes due to resource limits that, really have no reason to exist, considering the ancient engine is still being patched.

I'm sure the current team, in addition to breaking things (like push brushes in water), is also fixing things - but this is a simple and obvious fix that'd help game stability all around.

Sadly, also, Xash isn't an option for the most actively developed Goldsrc Mods (MSC and CoF).

@sbolokanov

Perhaps what you should demand is a "legacy" branch

Dunno what you'd call that - Half-Life Classic Cassic? If it meant having access to an older version of the engine, it'd help a lot - but the SDK doesn't include the engine, so adding more branches to GitHUB doesn't help - unless, of course, they want to open source this near two decade old engine for us.

...and yay... Found a new one just a few days ago! Apparently they changed how entity tables work. My best guess this is to stop server hosts from editing their maps. Well, a lot of the time, in games with multiple varieties of the same map, developers use Ripent to edit the entity table, rather than rebuilding the map from scratch. So... This security effort killed one of our most beloved maps - a "nightmare" variant of the lower level Thornlands map - a map that, previously, worked fine for nearly seven years.

I managed to tweak the entity table into a fashion that the new engine was willing to digest, and thus salvage it... But that was only possible because the mod affected is active - this is no doubt gonna fry dozens of other mods. Svencoop has probably lost some maps due to the same "security feature", as they ripent a lot of their maps. Will need to check in with them to see.

/therideneverends.jpg

[bolokanar]

@Wasdsensei guess you misunderstood. What I meant is a legacy branch of CS on Steam (CS client/server), not GitHub.