Banning stuffcmd

[Urre]

How about it people. A purely ethical and moral question, should stuffcmd be banned?

[avirox]

I'm in favor of doing this if said engine(s) has CSQC implemented. Otherwise, no.

[ceriux]

no, there's still a bunch of things you can do with stuff cmd. if the engine coders could make things that accessed some of the stuff , that the stuffcmd did then sure. but there's a lot of features stuff cmding something can do that can help a game or mod. removing it wouldnt be worth some of the consequences.

[Orion]

Depends much on what the coder is doing with it, stuffcmd is useful when you don't do things that harasses a player, like changing fov or binding keys and some other things.

For example, afaik, in TF all the aliases like discard, detpipe, +det5, build etc etc etc, are all done by stuffcmd, but aren't bound to any key. The bindings you do the way you like in a cfg file.

Also, TF stuffcmd's v_cshift a lot when you're firing the hwguy's chaingun (or the old concussion grenade, that actually pushes you side to side). The old flash grenade also stuffcmd's brightness to let the screen white.

TF also stuffcmd's cl_forwardspeed, sidespeed and such to limit the velocity for a class.

One thing I hated in TF that is actually been banned, is the autozoom feature for the sniper. Because it stuffcmd's FOV, and it always get back to 90 when I actually play with fov 115! I'd rather make two bindings for fov, one for 115 the fov I like with no zoom, and another for a lower fov.

That's it. But I still find stuffcmd very useful if a coder knows how to use it and not make other players suffer.

[mh]

Depends much on what the coder is doing with it, stuffcmd is useful when you don't do things that harasses a player, like changing fov or binding keys and some other things.

For example, afaik, in TF all the aliases like discard, detpipe, +det5, build etc etc etc, are all done by stuffcmd, but aren't bound to any key. The bindings you do the way you like in a cfg file.

Also, TF stuffcmd's v_cshift a lot when you're firing the hwguy's chaingun (or the old concussion grenade, that actually pushes you side to side). The old flash grenade also stuffcmd's brightness to let the screen white.

TF also stuffcmd's cl_forwardspeed, sidespeed and such to limit the velocity for a class.

One thing I hated in TF that is actually been banned, is the autozoom feature for the sniper. Because it stuffcmd's FOV, and it always get back to 90 when I actually play with fov 115! I'd rather make two bindings for fov, one for 115 the fov I like with no zoom, and another for a lower fov.

That's it. But I still find stuffcmd very useful if a coder knows how to use it and not make other players suffer.

That's pretty much my thinking on stuffcmd too; use it by all means but use it wisely and with caution.

I guess I was the one who said I'd like to see it die, but the context of that was making the point that engines should provide alternatives that don't involve use of stuffcmd, and you've given some good examples of areas where such alternatives are needed here.

The ability for a server to set a cvar on a client is one, but - even without stuffcmd - this would need to be carefully regulated. Should a server be allowed change my video mode (by stuffcmd or any other means)? I don't think so, but currently it can.

(Stuffcmd'ing brightness is a very borderline case IMO; I can see that it gives a neat effect in a mod but I can't see it being anything other than evil. How do you know the correct brightness to restore when you're done? 1.0? 1.2? 0.6? This is actually a good example of the kind of thing where a mod can go overboard - in all innocence - and stomp on a player's settings.)

There's also 13/14 years legacy of mods to be considered, so even though I would like to see it die, I don't think it should - or even could - be banned outright. Regulated would be more like it.

[ceriux]

personally i feel altering the fov is kind of cheating. if the developer intended for you to play at fov 90 then i see no problem with it always being set back. changing your fov can give you an advantage where some it might cause a disadvantage. changing the fov can also screw the the immersion in the game.

[Wazat]

Heh, I'm with ya on the FOV thing being outside of intent (like a lot of pro tweaks), but that's a flame war we do NOT want to start into here.

I agree with stuffcmd being a valuable asset unless viable alternatives are provided by the engine. If taking it away eliminates perfectly legitimate uses for it that a developer needs, that's bad.

And I also agree that legacy mods would be thoroughly screwed by such an act. Bad news, imo.

So perhaps not.

[Urre]

My point was that engines should provide alternatives . stuffcmd should never have been included in the original builtin list, then no one would have even imagined the usefulness of it, thus no one would've abused it either. If all the things people use it for were supported in other more "proper" ways by engines, there'd be no need to use it. I easily grew out of using it as I saw how icky it was. Seeing as my favorite engine already did most of the stuff I wanted to do using it in other ways, it was an easy step to take...

[c0burn]

stuffcmd(self, "bf\n");

We don't even have a replacement for this, do we?

A lot of people use stuffcmd to force settings on the "way the game should be played". I can't say I blame them when engines aren't providing alternatives.

It's one of the reasons IW removed the console from MW2. They designed the game from top to bottom, and don't want people fudging with fov/textures/etc etc to gain an advantage.

[Urre]

The console should exist, but certain cvars and commands should be cheat/dev protected, fov could be one of those if you're anti-fov changing. This is something which Quake engines should adopt as well. Instead of deciding engine-side which cvars to cheat protect, it should be possible for the mod to decide this, especially useful for multiplayer mods. I can imagine it being very hard to do though, with the engine source being open and all. This is because most of the effects which are used to restrict a player are "layered" on top of a fully free world. Shadows for example are put on top of a fullbright world, so those will always be possible to turn off if you have the engine source. If rendering worked the other way around, that everything was black and light was added, it'd be harder to cheat with these sorts of things. But that's not going to happen, as it goes against the entire architecture of what computers are.

stuffcmd(self, "bf\n");

We don't even have a replacement for this, do we?

CSQC.

[Spike]

quakeworld engines have an alternative to bf.
v_bonusflash 0...
</irony>

imho, stuffcmd is a bit too engrained in the fabric of quake. You can't kill it completely, but you can choose which commands you wish to block (or allow, if you're more extreeme).

the catch is that you have to retain support for aliases, or map voting etc etc won't work, without permitting 'unbindall' or 'alias quit'. A couple of engines have aliases that invoke map commands for the menu.
On the plus side, an engine that can filter commands can probably filter protocol-dependant reconnect and client-issued reconnect, as well as latching idlescale if the server sent it, and reverting fov when the server resets it to default.

Urre, in FTE, if the mod stuffcmds a cvar set of some kind, the cvar becomes latched. When the user then tries to change it, all that happens is that it remembers what the user wanted, but doesn't apply it. When the mod sets it to default, it unlatches and reverts to whatever value the user wanted/had it set to before (by mod, I mean either server or csqc).
So if you have an FTE client, you don't need to spam cvar changes constantly. You can just assume the user has default settings for everything. In the case of fov, you need to lock it to 90.1 or so to stop them from changing it. bah.

[Urre]

Spike: I didn't mean dropping support for the builtin in engines, that'd break existing mods (well I actually did, but let's pretend I didn't), but rather trying to convince people to stop using it in new mods. It can be tough if your target engine doesn't have alternatives, but as long as you're developing for the PC as a platform, there exists atleast two engines which have alternatives for everything stuffcmd can do.

[Teiman]

I have voted no, but I wish I where able to choose "No idea" because I don't know enough about the issue.

[Urre]

It's not an entirely serious topic, really, mostly trying to open some eyes or something.

[Spike]

strictly speaking, csqc is not a replacement for stuffcmd.
It provides a client-side reparser for it. Generally that just equates to a localcmd (the local equivelent of stuffcmd...). So yes, csqc can do everything stuffcmd can, but its in no way more secure.

Consider: stuffcmd(self, "cmd rcp $rcon_password\n"); as a method for obtaining the rcon password for other servers.