Zandronum

Watermelon wrote:Currently even without this implementation, there's already a way to overload someones hard drive using ConsoleCommand, but that is in there, an that can affect clients anywhere at any time, whereas this would only affect the server. I even think Apothem proved you could delete someone's files on their computer with ACS somehow.

IIRC Torr said he would disable it if there was an abuse case. Referring to ConsoleCommand isn't a valid argument anyway since like I said, it's a horrible idea. It's only there at the moment because Skulltag had it.

I apologize: I don't follow what you mean. Can you clarify?

ConsoleCommand is an abomination that was added to Skulltag before I joined the development. If you ask me, it should have never been added in the first place. The only reason why I haven't removed it yet is that many mods rely on it. Nevertheless, if ConsoleCommand is going to be abused too much, I will either remove it entirely or at least disable it by default so that the user has to activate it manually to use mods that need it.

Torr Samaho wrote: if ConsoleCommand is going to be abused

Define "abused."

Really, the only thing that you can "Abuse" with ConsoleCommand is screwing with a client's settings, and spamming their INI file with fake settings, and hopefully you won't see that very often...

And it lets you do a lot of things that you can't do without it, even in the newest zDoom revisions. Don't remove it unless you're adding in a bunch of ACS functions that replicate every behavior it was used for previously.

Good examples are: Puking Clientside Scripts for one player.
Changing server settings automatically for your map (ones that aren't implemented in MAPINFO)
Also, a very good example is a mod I made that allows you to administrate your server from inside the game quickly and efficiently with an ACS menu, and allows you to set up permissions for server administrators without giving them the actual RCON password by making the server ConsoleCommand things like kick, and ban.

Furthermore, this topic has absolutely nothing to do with ConsoleCommand, and everything to do with allowing servers to save data after a game session WITHOUT having to use (NOT abuse) things like ConsoleCommand, and relying on the limited application of inis.

Add to that being able to save custom CVars and giving the client a way to communicate to the server automatically (if that's not what you meant by the first point).

Remove ConsoleCommand and I will abandon Zandronum. It's literally the only reason I stay here.

We're getting way off-topic here, but would a CVAR to print out all ConsoleCommand usage be a viable compromise?

[EDIT] Thread split for the sake of not reeling off the rails too much in the original topic.

Unless Zandronum adds new functions to replace what people use consolecommand for, then don't remove it.

Catastrophe wrote: Unless Zandronum adds new functions to replace what people use consolecommand for, then don't remove it.

Basically this, please.
The way I see it, ConsoleCommand is a double-edged sword.
Yes, it's stupidly easy for someone to create a troll wad to make some havoc, making a script that does UnbindAll and say "dicks dicks dicks dicks dicks" in a constant loop.
But also at the moment, there's quite a few things that can be done with only console command and there simply aren't any adequate replacements for it. It makes quite a few things infinitely easier to do.

That doesn't mean it shouldn't have a better alternative, but in the meantime until the aforementioned better alternative comes up it's pretty vital.

Some of my mods rely on ConsoleCommand for serverside commands.

Ænima wrote: Some of my mods rely on ConsoleCommand for serverside commands.

I did something that forced item respawn for timed respawning items and had to use consolecommand for this, always wondered if there was another way :/

You should make like a whitelist or something of commands that conslecommand can do (change c/svars, puke scripts, other useful mod stuff), and disable execution of all other commands that aren't in that list. That would help so that any abuse case won't happen in the first place, as "nobody has abused it yet so we are safe" might not hold true forever.

consolecommand should at least not save settings. Forcing it on client side scripts is just horrible.

-=Dark-Assassin=- wrote: consolecommand should at least not save settings. Forcing it on client side scripts is just horrible.

Several mods use this method to create variables in order to save a form of persistent data across game sessions that are used for personal settings for their mod. Unless a method is created to replace this, please, no.

-=Dark-Assassin=- wrote: consolecommand should at least not save settings. Forcing it on client side scripts is just horrible.

Removing the ability to archive CVars removes 90% of the legitimate use for it.

Well first of all I should point out that consolecommand/getcvar are inheriently non-portable. While I expect this to not be considered important to the average user, this is something that prevents extended ACS from being a universal scripting language for Doom. To give an example of the portability issues, Fragglescript supposedly is based partly around console command execution and requires that (G)ZDoom have only partial support.

The console is also mostly considered not game state critical, which means it has no place in a scripting language mostly dedicated to game state manipulation. This results in the usage having unclear semantics and differing mechanics between net code types. If replaced with proper features, the engine has more clear instructions to follow allowing for better forwards and cross compatibility.

Basically the point is these features have a bad benefit to cost ratio, which can only be seen if looking at things from the port developer's point of view. They were implemented as a supposed easy way to implement a set of features and as a result provides easy abuse cases (some of which Zandronum blocks through a blacklist already) and compatibility headaches.

Llewellyn wrote: Also, a very good example is a mod I made that allows you to administrate your server from inside the game quickly and efficiently with an ACS menu, and allows you to set up permissions for server administrators without giving them the actual RCON password by making the server ConsoleCommand things like kick, and ban.

I have no idea why this is better than giving the rcon password to people that should administrate your server, but this sounds like something that should be handled by the engine itself and not a mod.

One thing to remember is that ACS scripts are supposed to be deterministic. While the server authoritive model of C/S ports helps mask this, introducing more paths for non-deterministic behavior could cause problems in the future.

I see the ConsoleCommand thing the same way as I see allowing to call custom system commands on a remote web service. If you get all the permissions, blacklist, whitelists, and so on, right then it will be safe. But if you forget about that one tiny thing that someone else discovers, a "rm -rf /" happens. So, to me, ConsoleCommand is a security threat, and security threats should be removed.

Agree with Zalewa. A wad that can be made by anyone with any intentions shouldn't have direct access to server and client console by logic, although I understand that its use has grown into big scale as of now, and it would be a pain for modders if it was plain removed.

I've seen quite shady use of ConsoleCommand around, from fucking with users' config (WDI, before it was removed) to this plain dumb script in fxdms3.wad that is probably meant to be executed by the client when it grabs BFG but it executes on the server too.

It had me baffled for at least half an hour trying to understand who and how is saying that. Did someone steal my RCON password? There is no sign of using RCON in the console. Did someone find an exploit? It's neither funny nor legitimate use of ConsoleCommand.

Llewellyn wrote:

-=Dark-Assassin=- wrote: consolecommand should at least not save settings. Forcing it on client side scripts is just horrible.

Several mods use this method to create variables in order to save a form of persistent data across game sessions that are used for personal settings for their mod. Unless a method is created to replace this, please, no.

Sorry, wasn't really clear.
I was talking about the internal cvars, such as GVH forcing OpenGL client settings.
Just an example.

I can agree that it can be dangerous, but I would imagine if anyone ever did try to harm the user through their wad via ConsoleCommand that they would be removed from the community. There's really no need to maliciously use something widely used in popular wads these days. I agree to the idea of waiting for a good replacement of ConsoleCommands for the sake of the good wads that rely on it.

Llewellyn wrote: Define "abused."

Really, the only thing that you can "Abuse" with ConsoleCommand is screwing with a client's settings, and spamming their INI file with fake settings, and hopefully you won't see that very often...

Yes, screwing with the user's settings (client or server) is certainly abusing this feature. Using "say" to make a player say certain things is an abuse as well.

Ijon Tichy wrote: Remove ConsoleCommand and I will abandon Zandronum. It's literally the only reason I stay here.

If ConsoleCommand is so important for you, please tell us in detail what you use it for here, so we can think about creating proper ACS functions that achieve the same things in a way that's not a big security problem.

Konar6 wrote:

Code: Select all

script 2 (void) //Lol
{

delay( 35 );
        consolecommand( "say Im a n00b so I use the BFG!!!11!1111" );
        
        }

It had me baffled for at least half an hour trying to understand who and how is saying that. Did someone steal my RCON password? There is no sign of using RCON in the console. Did someone find an exploit? It's neither funny nor legitimate use of ConsoleCommand.

Thanks for pointing this out! I added "say" and "say_team" to Zandronum's ConsoleCommand blacklist putting an end to this misuse.