0001070: Phasing out the dangerous ConsoleCommand for various additional/improved ACS commands

Notes
(0004811) Watermelon (developer) 2012-09-26 15:31	Apparently I didn't finish one of my lines in the post: "In addition, most mod developers like myself only really use consolecommand..." I meant to say, most modders only use it for setting cvars or toggling really outlying things we don't normally have access to, and therefore if we provided all our mod developers with access to particular things then it'd be easier to phase out this command without too much trouble. By phasing out, I figure it'd be in there for the legacy of mods that use them, but maybe it would not work for various things like unbind all or such (as to not break the mods that use them currently)?

(0004812) Qent (updater) 2012-09-26 15:38	I think this could work, but I would like to be careful that no useful functionality is lost.

(0004813) MazterQyoun-ae (reporter) 2012-09-26 17:45 edited on: 2012-09-26 17:51	Well, this thing is actually really annoying (e.g. WDI that forces your cl_identifytarget and cl_drawcoopinfo to 0 so you have to reset it everytime, some mods that bind their actions to keys w/o asking user etc.), but heh, it might sound a bit stupid, but I'd suggest to change this ConsoleCommand() so it will work inside of "ini sandbox", so all the settings/cvars that have been set by ConsoleCommand() (except the ones that were created by the mods themselves) aren't getting saved in INI, but in RAM for current Zan session only. That gives modders freedom for forcing anything in their own mods (no limitations = mods shouldn't break), but the settings will not be saved (they won't work for next time you run Zan, but if you're going to play same mod, they will be forced again when you join).

(0004830) Torr Samaho (administrator) 2012-09-27 19:54	IMHO the whole approach of changing the clients setting is flawed. Mods shouldn't touch the player's settings, no matter if the change is temporary or permanent. For instance, don't touch cl_identifytarget, instead set sv_nocoopinfo to 1 on the server. If the client needs to be prevented from doing something that can't be prevented yet, then a new dmflag should be added for this. BTW: You can't use unbindall in ConsoleCommand. This and some other commands are explicitly disabled when ConsoleCommand is used. Nevertheless, I think phasing out ConsoleCommand is a good idea. I myself would have never added it in the first place...

(0004850) Blzut3 (administrator) 2012-09-29 22:49	I've said before that consolecommand is an example of how not to solve an issue. Even to a lesser extent, getcvar poses a problem with mod compatibility. Even KEYCONF is a bad idea overall and recently the most prevalent use of it was replaced with decorate properties. The point I'm trying to make is mod authors should not be concerning themselves with console commands. Of course at the same time it would be unwise for us to remove consolecommand from Zandronum since it would needlessly break backwards compatibility. Over at zdoom.org I discussed that a lot of time what a mod author really wants is to be able to hint that a certain setting should be on/off. Going on what Torr said, that's exactly the kind of thing MAPINFO is for. Then you would handle the properties in there like allowjump/allowcrouch (able to be overridden).

(0004887) Dusk (developer) 2012-09-30 23:56 edited on: 2012-10-01 00:06	> For example, AOW uses it to force HUD_Scale true This is due to lack of SBARINFO forcescaled-flag in Zandronum. I really hate that forcing and would rid of it the moment we got forcescaled in a release. > In addition, there should be extensions to GetCvar to return strings, or maybe GetCvarString(str cvar), along with SetCvar(str cvar, int archivecvar) and DelCvar(str cvar) I fully agree, BUT it should impose a prefix like "mod_", so SetCVAR ("test", 10, true); would be equivalent of set mod_test 10; archivecvar mod_test - this would be of big help with phasing consolecommand out. With the prefix imposing you don't have to worry about a mod screwing up your vital settings. But it could still affect the CVARs of other mods.. MAPINFO I believe should have a way to suggest dmflags, like sv_nocoopinfo for WDI. I'm thinking it could have like setdmflag sv_nocoopinfo 1 and perhaps a CVAR like sv_nomapinfodmflags to disable this behavior in case. One more thing at least AOW uses is to, from a clientside script, puke a NET script to send information from client to server. Just calling ACS_Execute(Always) does nothing.

(0004888) Edward-san (developer) 2012-10-01 00:03	I like Dusk's idea, I wonder if ZDoom devs could consider it. Obviously some cvars should not be touched...

(0004889) Dusk (developer) 2012-10-01 00:11 edited on: 2012-10-01 00:14	Another thing I've seen is SNS's afk-autoremover which removes players it determines AFK from game. An AFK person could potentially endlessly stall a survival game if there are no RCON users present. Maybe there should be user control commands like KickPlayer(int id, str reason) / KickPlayerFromGame(...)? Perhaps - again - with a prefix for the reason (e.g. snoopy has been forced to spectate! Reason: (mod-invoked) AFK for 3 minutes) I personally don't think, though, that mods should be able to manage bans. Such would go pretty extensive... and it's stuff you can't even reliably perform with ConsoleCommand either.

(0004892) Dusk (developer) 2012-10-01 10:58 edited on: 2012-10-01 11:01	For consolecommand(puke), I made this in response: 'https://bitbucket.org/CrimsonDusk/neurosphere/changeset/2222e8bce025c5a8d2ddfe1f76ad057cae4a1939 [^]' Basically it's a function that executes an ACS script on the opposite peer. The client-side end rids need of consolecommand(puke) and the server-side end adds another network feature that could be used to execute a clientside script on one client and that only. hmm.. now that I think of it, there should be an "always" parameter instead of two functions again..

(0004895) Blzut3 (administrator) 2012-10-01 12:55	Regarding the afk-autoremover. Shouldn't that be an engine feature? Especially with Zandronum being open source, it would be easy enough to have a modified server binary that kicks afk servers. Regarding the networked execute stuff, I would probably keep the functions separate for consistency. I still stand by that having the client do calculations to send back to the server in ACS is really bad design though, but I'm not going to waste my time arguing that again.

(0004896) Dusk (developer) 2012-10-01 13:41	Quote Regarding the networked execute stuff, I would probably keep the functions separate for consistency. I still stand by that having the client do calculations to send back to the server in ACS is really bad design though Perhaps not calculations but stuff like user interface and menu selection stuff. Preferences, local cvar settings... stuff like this that the server can't otherwise know.

(0004898) Qent (updater) 2012-10-01 16:03	Another use for ConsoleCommand at the moment is dynamically adjusting winlimits (and other limits) based on player count.

(0004899) Torr Samaho (administrator) 2012-10-01 20:03	Quote from Blzut3 I still stand by that having the client do calculations to send back to the server in ACS is really bad design though, but I'm not going to waste my time arguing that again. I fully agree that the client shouldn't be doing any calculations whose results have to be send back to the server. Picking up Dusk's remark, at least at first glance I'd say that sending configurations settings from the client to the server via ACS would still be a reasonable wish though. Dusk's proposed ACS_NetworkExecute is a step in this direction, but since we are discussing things in general right now, we should think about adding a mechanism that is explicitly designed for sending client selections/configurations via ACS to the server (and nothing else). The only valid reason I see right now, why a client should be able to puke a script on the server is a workaround to transfer information about a choice made by the player to the server. If this functionality is available directly, ConsoleCommand("puke") and ACS_NetworkExecute shouldn't be necessary at all anymore (at least not for the client->server direction). Quote from Qent Another use for ConsoleCommand at the moment is dynamically adjusting winlimits (and other limits) based on player count. I think we could add a SetGamemodeLimit ACS function for this.

(0004902) Dusk (developer) 2012-10-01 20:30	Quote we should think about adding a mechanism that is explicitly designed for sending client selections/configurations via ACS to the server (and nothing else). Works for me. I'd still want to have ACS_NetworkExecute, even if only for the server->client mechanism. At the moment there's nothing I'm aware of that can perform script execution like that on one client only. Maybe we need custom userinfo fields here?

(0004903) Blzut3 (administrator) 2012-10-01 21:35	Regarding interface selections, I assume this is to do mouse pointers without lag? Shouldn't it be possible to calculate the mouse position both on the client and server. Use the client side script for rendering and the server side script for actually performing the click? I've already stated that dealing with cvars is almost always a idea, so the local cvars thing is a moot point. The mod_ cvar thing is a decent idea and of course Zandronum could be programmed to sync those cvars with the server. I guess local mod preferences would also make MENUDEF/KEYCONF more useful overall though, but I'm not fully convinced on local mod storage. Regarding targeting scripts to a single player. I haven't thought about any possible side-effects from this, but what if there was additional logic where "if the activator is a player, execute only on that client?" I have no problems with extra functions to do targeted client side executes, but it's worth exploring automation possibilities. In an ideal world the mod author shouldn't have to think about net code optimization.

(0004911) Watermelon (developer) 2012-10-02 13:36	I did the 'render on client, send click to server' and it works perfectly. So far though, the only way I could send a click to the server is to have 'puke #' done. So far the only way I think this can be done is to create a new kind of execution that goes from client -> server, though from what I read in a thread that I made... the client to server checking doesn't really happen, which means there'd need to be some kind of reliable packet sending done. Another solution is to have a synced variable between the server and client, though that raises the same issues.

(0004912) Watermelon (developer) 2012-10-02 13:55 edited on: 2012-10-02 13:55	BTW how did my post change this from "Feedback" to "new"? 2012-10-02 09:36 Watermelon Status feedback => new Possible glitch? I don't recall having operator powers or such

(0004913) ZzZombo (reporter) 2012-10-02 15:23	No, you have answered (gave your feedback) thus the status is no longer needed to be "feedback". BTW recent maintance work seems to lose all localization of status messages so I see "feedback" and not "нужен отклик". But I don't recall having operator powers or such too :P

(0004914) Blzut3 (administrator) 2012-10-02 16:43	ZzZombo, 0001072 should explain the now missing translations. Watermelon, if a click is registered by firing a weapon then in theory you can track the position of the mouse on both the client and server (two concurrent scripts with the client doing rendering as well as tracking). When the weapon fires it triggers another script which reads the position and does the action. Does this not work? I guess I could try it myself if this is not clear.

(0004915) Watermelon (developer) 2012-10-02 17:44 edited on: 2012-10-02 17:46	I've successfully been able to do the above, though I'm unsure of how to send the mouse data to the server without flooding it. My way of doing it was having the pseduo-renderer doing it's own clientside thing, then a clientside script monitoring the mouse movement, when a click is performed it did something like puke (script) click_type mouse_x, mouse_y I was always worried of having something constantly feed mouse updates to the server. I figure 8 bytes of info (excluding headers/script numbers/additional size for the packet being sent) * 35 tics per second = 280 bytes/second for one player. The way I did it above only sends a puke when the clientside script detects a click (or rather, when the player clicks and then lets go), thus only sending a single script command whenever it's set up. My only worry is how to emulate this effectively if console command was to be removed. So far I just tried a test with a few scripts If you go from Server -> Client -> Server with only ACS_ExecuteAlways, when the Client calls ACS_ExecuteAlways on a script that does not have NET nor CLIENTSIDE, it treats it as a clientside script. Thus I don't see any way for the clients to send data to the server. I was testing around with using GetPlayerInput, and it is successful for in game players to not have to worry. The only problem is for spectators. I requested a thing that can grab spectator data but its only clientside. If I wanted to do something that allowed spectators to participate I have to force them to join the game. EDIT: Disregard my previous server -> client thing, though one potential problem that could arise is if two seperate scripts are running (one on the server, one on the client) and they somehow desync... that'd cause some problems. I wonder if it's possible to desync since they're not really interacting. Though this is where Dusk's update for "common variables" shared between players/server would come in.

(0004968) Llewellyn (reporter) 2012-10-05 19:28	As a modder, I love ConsoleCommand. It has many uses, such as one being: ConsoleCommand("-use"); Delay(1); ConsoleCommand("+use"); Delay(1); ConsoleCommand("-use"); This particular example causes the player to "Respawn" in the event that the server operator wants to have instant respawns off in my mod. There are so many uses, but if you do end up trying to "Replace" it, here are things that I would like to see at a minimum: The ability to add server CVARs for a mod (like dusk suggested) and client cvars. I use these for options that the player wants, like in Minigolf. I also showed TerminusEST13 how to do the same for Samsara. Server variables MUST be saved afterwords, otherwise some functions I've written for a mod would be worthless. The ability to use admin-functions from ACS. This sounds a bit controversial but things like KickFromGame_IDX, Ban, etc. I recently made an admin-mod that gives moderators a clientside menu, and allows admins to allow "moderators" access to limited ranges of admin commands (Had to bypass the "so and so may be cheating by puking a script") I've actually found it possible to desynchronize client and server (intentionally) for a mod by using Cvars. This also opened up a range of possibilities that I hadn't considered because I can make one client see something and another client see something completely different.

(0005987) Ijon Tichy (reporter) 2013-02-10 21:04 edited on: 2013-02-10 21:07	For client->server communication, I think two functions are in order: SetClientOption(str optionName, int optionValue) and GetClientOption(int idx, str optionName). This should give a good idea of their usage:'http://pastebin.com/55tSuirn [^]' Basically, SetClientOption will set the option $optionName to the value $optionValue on the server for the client executing it, and GetClientOption will retrieve option $optionName for client $idx. Running SetClientOption on the server will do nothing, and GetClientOption on the client will return nothing. Client options would be cleared when a client disconnects, so as to not cause any weirdness with a client disconnecting with IDX 2, and a new client connecting, taking that IDX, and having options that don't apply to him screw up his game. This will still allow GUIs to be rendered on the client and processed on the server. Have the client set the options "mouse_tic" to Timer(), "mouse_x" to wherever the pointer's X coordinate is, and "mouse_y" to wherever the pointer's Y coordinate is whenevr a click is done. This doesn't require wasting a script number, the server can take these values with a grain of salt, and it's an explicity defined interface that doesn't have the pitfalls of ConsoleCommand. Then you get a crazy bastard who does something like have a client set an entire Tetris field worth of options, but as long as clients have the ability to communicate to servers programmatically, that problem will exist. At least no permanent damage would be done; all that would be lost is RAM, and temporarily at that. As for setting CVars, I'm thinking that you would have to define a CVar prefix in KEYCONF, or else SetCVar wouldn't work. Besides that, Dusk's suggestion would work well, and would play much more nicely with StrParam (if you even require it, which you do if you want arbitrary CVar setting with ConsoleCommand). edit: CVar names would be defined as "${cvarPrefix}_${cvarName}". So if you had "cvarprefix samsara" in your KEYCONF, SetCVar("cl_wolfmove", 1, 1); would do the equivalent of "set samsara_cl_wolfmove 1; archivecvar samsara_cl_wolfmove".

(0005995) ZzZombo (reporter) 2013-02-11 08:16 edited on: 2013-02-11 08:22	Oppose. I have an intro level in my mod, there I use the command to script player actions. The player is scripted to advance through a predefined route and use equipment when needed, the actual player just watches his actions. The only thing that I find extremely useful in SourceMod is a parameter to GetCVAR() to specify what player's CVAR you want to retrieve.

(0005999) Ijon Tichy (reporter) 2013-02-11 13:17	The thing is, UseInventory exists. Just use that.

(0006000) ZzZombo (reporter) 2013-02-11 15:39	:/ +use/fire/forward/etc can't be scripted in that way. Quote the actual player just watches his actions The thing is, I just "press" the buttons to script player's movement. It's the easiest way to make a scripted demo of your mod without huge Decorate and ACS scripts.

(0006001) Watermelon (developer) 2013-02-11 16:14	Can't you use ThrustThing/Z to emulate +forward/back/side and SetActorState to emulate firing?

(0006003) Torr Samaho (administrator) 2013-02-11 17:30	To get the ball rolling, I started to work on SetCVar. Here is a very first implementation which may still change completely. The syntax is "SetCVar (str cvarName, str cvarValue, int archiveCvar )" and you need to add -107:SetCVar(3), to your zspecial.acs to use it. SetCVar does not allow to alter built-in CVars (that's why I didn't add a suffix), does not allow to create CVars with a name that's already used by a console command and only allows alphanumeric characters and underscores in the name.

(0006007) Blzut3 (administrator) 2013-02-11 22:38	I can't say much since you don't seem to have a patch to examine, but here are a few thoughts I have. First, cvarValue should probably be an int since getcvar returns an int. The archiveCvar parameter probably needs to have more thought put into it. There are two types of cvars that I see as useful (perhaps someone can name a few more). 1. Client side performance parameters. These would probably be archived. In theory they may be restricted to setcvar calls within clientside scripts. I could explain the reasoning for the restriction, but it basically comes down to an idea of a strict mode which ensures deterministic behavior outside of client side scripts. 2. Game mode settings. These should be CVAR_LATCH\|CVAR_SERVERINFO so they get saved into demos and save games.

(0006009) bluewizard (reporter) 2013-02-11 23:01	Personally, I'm using console command to save a bunch of variables in a players config to make a hiscore system (Like, games won, etc). So if the player were to disconnect and reconnect the next day everything would be fine. If there's a good alternative to this, then I'd be in support of removing consolecommand().

(0006010) Dusk (developer) 2013-02-11 23:25	I believe SetCVar should have the name be prefixed with "user_" or "mod_" or whatever. This way you would have no conflicts with any console commands or variables.

(0006011) ZzZombo (reporter) 2013-02-12 03:31	Watermelon: the thrust functions would be used with multiple jumping functions to determine when to start/stop/turn/etc, essentially resulting in ugly looking in multiplayer from both thrusting (bad prediction) and jumping (no client-side handling). On the other hand, issuing the commands from the client would work as almost natively as possible. Also, I would need to animate proper walking states manually yet again using jump functions.

(0006013) Torr Samaho (administrator) 2013-02-12 06:22	Quote from Blzut3 I can't say much since you don't seem to have a patch to examine I attached the current version of the patch. Quote from Dusk I believe SetCVar should have the name be prefixed with "user_" or "mod_" or whatever. This way you would have no conflicts with any console commands or variables. The current implementation makes sure that there are no conflicts with existing commands or variables by checking whether the names are already used for built-in things. This will not prevent mods though to use names now that may be used as commands/vars in later versions of Zandronunm. I can easily add a suffix (possibly based on the variable type Blzut3 proposed). In this case I would renamed SetCVar to SetModCVar or something like this.

(0006014) Blzut3 (administrator) 2013-02-12 18:30	All right. Thinking about this more and looking at the patch I have a question for those who are looking to set cvars: Ignoring persistent data saving, is there a reason to want to set cvars from ACS? The reason I bring it up is the two types I mentioned in my last post are variables that would be set by the user, not the mod. Instead what we should use for creating those cvars is a keyconf command. From what I can tell the only variables that people want to set are the built in cvars to control the GL renderer or whatever. A much more suitable solution to this is more mapinfo settings (as I'm sure in mentioned above somewhere). That finally leaves setting point limits based on the number of players. There may be some merit in a SetLimit(int limit, int amount) function which the server can ignore if need be. Actually, something to think about would be moving CMPGNINF to a series of ACS commands. As far as persistent data goes, as I mentioned in the forums. Probably the most well defined solution is to have a persistent session save. Over at ZDoom the biggest argument against persistent data in ACS (outside of hard disk thrashing) is that new game should be just that. However, if an command line option was given to specify a session store file (global variable dump) then these issues are avoided. Since this is just a partial save, it doesn't break determinism. (Would be the same as loading a save game and then warping to another map.) Ultimately this method would require no API changes to ACS.

(0006015) Theshooter7 (reporter) 2013-02-12 21:33 edited on: 2013-02-12 21:36	(Copied and modified from the forum post) I use ConsoleCommand() in WDI to automatically set up appropriate DMFlags etc for the server. It's not entirely NECESSARY (in fact, the server owner can even disable it with a custom cvar), but it's nice to have. One thing that is necessary, and extremely useful, however, are these two lines from the above mentioned code: if(getcvar("sv_applylmsspectatorsettings") == False && WDI_GameState() != GAMESTATE_GAMEOVER) Consolecommand("sv_applylmsspectatorsettings true"); else if(getcvar("sv_applylmsspectatorsettings") == True && WDI_GameState() == GAMESTATE_GAMEOVER) Consolecommand("sv_applylmsspectatorsettings false"); These lines automatically allow players to talk to eachother after a round ends (during the tally board). Without it, dead players can't talk to players still alive. I received a lot of positive feedback when I implemented this, and it would be a shame to see it go. If there were an alternative to handle this, that would be greatly welcome! Oh, and lastly, on that note, WDI has for some time abandoned changing user settings and simply modifies the server flags. ConsoleCommand() is no longer used to change client settings as I disapproved of it myself (though at the time there was no other real option around it; it was in later SkullTag releases that the different server DMFlags came along)

(0006090) Gez (reporter) 2013-03-01 22:32	Quote from Ijon Tichy As for setting CVars, I'm thinking that you would have to define a CVar prefix in KEYCONF, or else SetCVar wouldn't work. Besides that, Dusk's suggestion would work well, and would play much more nicely with StrParam (if you even require it, which you do if you want arbitrary CVar setting with ConsoleCommand). edit: CVar names would be defined as "${cvarPrefix}_${cvarName}". So if you had "cvarprefix samsara" in your KEYCONF, SetCVar("cl_wolfmove", 1, 1); would do the equivalent of "set samsara_cl_wolfmove 1; archivecvar samsara_cl_wolfmove". Rather than KEYCONF, the place to declare a mod's prefix should be in MAPINFO/GameInfo section. Alternatively, the engine could autogenerate a prefix from the file name. There are functions already in the C++ code to know which file a given lump comes from, so you can know which archive contained the behavior or library lump from which the running script comes. In the absence of a GameInfo "gamename" key, this could be used.

(0006110) XutaWoo (reporter) 2013-03-13 00:45	A problem with that, Gez: Different versions of mods tend to have different file names, meaning those playing the mod throughout the versions would end up with a bunch of CVars and their settings not saving between versions.

(0006313) Ijon Tichy (reporter) 2013-05-03 20:17	@Gez: Why MAPINFO or GAMEINFO? Those are for purely game sessions, and CVars go far beyond the game. KEYCONF is for stuff that lives in the console, like binds and aliases; having it handle CVars is hardly a stretch. I'd see it as very weird to have something dealing with the console in a file otherwise completely ignorant of the console.

(0006314) Gez (reporter) 2013-05-04 15:52	Funny that you bring that up, Gooberman had the same objection. But Graf Zahl sides with me. "Stuff like this is supposed to be done with MAPINFO now because that's the one lump that's used to configure the engine for a mod." Hence, the GameInfo section of MAPINFO. (Not the GAMEINFO lump which is completely different and should have been named LOADINFO to prevent confusions but this is far too late for that now.)

(0006332) Ijon Tichy (reporter) 2013-05-15 18:46 edited on: 2013-05-15 18:48	I just remembered compat_clientssendfullbuttoninfo. Mods like Samsara need this to be on, otherwise the SO's shotguns won't work when dual wielding, among other things. It forces it on by ConsoleCommand("compat_clientssendfullbuttoninfo 1"). We need a way to force this flag to be on for a mod without using ConsoleCommand (or ACS at all, preferably). @Dusk: Cyberrunner uses forcescaled, and it's Zandronum-only.'https://github.com/TerminusEst13/cyberrunner/blob/master/pk3/SBARINFO.txt [^]'

(0006335) AgentME (reporter) 2013-05-15 22:00	@Ijon: MAPINFO can already set compat flags for specific maps. Does that include compat_clientssendfullbuttoninfo? I'd think that could be put inside an adddefaultmap or gamedefaults block but I don't think that would affect previously made map definitions. Maybe another type of MAPINFO block which is additive and affects all (previous and future) map definitions is needed too. (Alternatively, the mod could check if that setting is set or not (after checking whether it's Zandronum in use), and put a warning message about it for the admin to see.)

(0006336) Dusk (developer) 2013-05-15 22:22	@Ijon: interesting, I'll have to take that to use. One less of these little buggers...

(0006427) Dusk (developer) 2013-06-11 23:44	I'd suggest that since this ticket is becoming rather lengthy, sub-issues for replacements for ConsoleCommand's use cases be made separate tickets. They can then be linked in with relationships so we can keep track of everything.

(0006477) Mr. Wint (reporter) 2013-06-22 21:35	Opposed. I just released a mod that forces people to play random classes. Mega Man 8-Bit Deathmatch has a big problem in Capture the Flag, where everyone always plays as the fastest characters. I rely on ConsoleCommand("playerclass random") to fix this.

(0006479) Dusk (developer) 2013-06-23 00:49 edited on: 2013-06-23 00:49	.. isn't that abuse? Changing the players' settings like that is exactly what we don't want modders to be able to do.

(0006496) Mr. Wint (reporter) 2013-06-24 01:33	The Cutstuff community doesn't seem to mind. 'http://www.cutstuff.net/forum/viewtopic.php?f=28&t=5757 [^]' Some classes for Mega Man 8-Bit Deathmatch are considered unbalanced.

(0006497) Dusk (developer) 2013-06-24 01:42	Then shouldn't these classes be re-balanced..? Though the main point is that you're forcing people to play as a random class by changing their user settings. If it really is desired to have forced random classes, there should be a mod option to force classes to be random (thus not altering user settings).

(0006498) Qent (updater) 2013-06-24 06:43 edited on: 2013-06-24 06:43	Being able to force a random playerclass -- or better yet, any arbitrary distribution of classes -- would be nice. However, I would hardly consider Mr. Wint's method as a reason to keep ConsoleCommand! At best, it will punish non-random classes with death; at worst, with a kick for user info change flood.

(0006499) Dusk (developer) 2013-06-24 11:24	And in either case a messed up user config.

(0006500) Balrog (reporter) 2013-06-24 14:56	I don't think Wint here understands how to file a proper ticket. 'http://zandronum.com/tracker/view.php?id=1378 [^]'

(0006501) Dusk (developer) 2013-06-24 19:41	:) Marked as related.

(0006505) Mr. Wint (reporter) 2013-06-25 02:57	As long as you can resolve that ticket before you totally remove ConsoleCommand(), I'm down with it. Also, somebody else uses ConsoleCommand(). 'http://www.cutstuff.net/forum/viewtopic.php?p=240481#p240481 [^]' And finally, trying to balance over 60 classes is not a trivial task, especially given the wide variety of game modes available.

(0006507) Dusk (developer) 2013-06-25 17:21	Quote As long as you can resolve that ticket before you totally remove ConsoleCommand(), I'm down with it. That's why it was marked as a "child" of this ticket in the first place. The function isn't gonna be removed until the use cases are covered. Quote http://www.cutstuff.net/forum/viewtopic.php?p=240481#p240481 Can't this be done by applying the FallingDamage flag to the defaultmap?

(0006517) Balrog (reporter) 2013-06-27 22:54	Quote Can't this be done by applying the FallingDamage flag to the defaultmap? No, because that use case needs it to be turned on and off on demand. ACS can't touch MAPINFO, can it?

(0006988) Torr Samaho (administrator) 2013-08-11 07:15	A thought on how to stay compatible with old mods after we blocked ConsoleCommand: We could keep a list of md5 hashes of existing mods that would break without ConsoleCommand in zandronum.pk3 and allow those mods explicitly listed (and only those) to still use ConsoleCommand.

(0006990) ZzZombo (reporter) 2013-08-11 08:24	Uh, okay, but... my scripted intro level was very liked by my first testers... should I suppose I'm out of luck? Or will you add the checksums of my mod when it will be released?

(0006992) Torr Samaho (administrator) 2013-08-11 08:37	Before we block ConsoleCommand we plan to provide proper alternatives for all legitimate uses of ConsoleCommand. So if your mod is not released at the time when we start blocking ConsoleCommand, you should change your mod to use the alternatives instead of ConsoleCommand before you release it.

(0006994) Konar6 (reporter) 2013-08-11 14:00	How would you get a hold of all possible mods that would break without ConsoleCommand to hard-list them in zandronum.pk3? The solution needs to be more dynamic.

(0006996) ZzZombo (reporter) 2013-08-11 17:00	CCblockexemptlist.txt where admins could manually add hashes of hosted mods?

(0006997) Torr Samaho (administrator) 2013-08-11 20:47	The solution once ConsoleCommand is fully blocked is intentionally supposed to be not dynamic. If we want the blocking to be effective, the server may have no way to force clients to execute ConsoleCommand on their end.

(0008127) StrikerMan780 (reporter) 2014-01-23 19:45 edited on: 2014-01-23 20:09	I personally think a set of hard-coded CVar flags akin to Source Engine would be better than Killing ConsoleCommand. (These flags could also be applied to new CVars you create, so you can control what can/can't be done with them by servers/clients, etc. Very useful stuff.) CVars would be given said flags: FCVAR_NOTIFY = Notifies Clients in console/chat when this CVar is changed on a server FCVAR_ARCHIVE = This CVar is archived in the Config. FCVAR_CHEAT = Requires sv_cheats 1 to alter this cvar. FCVAR_SERVER_CAN_EXECUTE = Can be executed/changed on a client by the server. FCVAR_PROTECTED = Internal CVar that can be displayed, but never changed manually by client or server. (Stuff for scripts, etc) FCVAR_REPLICATED = Sends the value of this CVar to all clients. FCVAR_SERVER_CANNOT_QUERY = Server is not allowed to retrieve the value of this cvar from a client. Perhaps these could apply for SetCVar as well... Personally, this would be much cleaner than having a crapload of new functions for assorted-but-similar things.

(0008510) Toxicity (reporter) 2014-04-06 22:31 edited on: 2014-04-06 22:32	I think that too big of a deal is being made about this. I think ConsoleCommand should remain in Zandronum, in its entirety. Almost no one abuses it, the only instance I recall happening (at least to me) was when playing the infamous UACMN. There's no major, permanent damage that can be done to a client's computer just through ConsoleCommand. So what if it changes your name to "FAGGOT" and unbinds all your keys? That's why everyone should keep a backup of their Zandronum INI file. I'm also pretty sure that word will get around FAST about your wad doing malicious shit, and after that everyone will avoid it like the plague. If anything, I think clients/servers should be notified with a simple message the first time a script calls ConsoleCommand (but not every time cuz that might create flood) and would say what command was run. It just seems like too much of a hassle to not only create new commands for every specific ConsoleCommand use, but also attempt to keep discontinued projects compatible using MD5 whitelists. Howbout just a simple MD5 BLACKlist for all mods which have been confirmed to abuse ConsoleCommand? You shouldn't have to punish all modders just because some retards abused this useful tool in the past.

(0008527) ibm5155 (reporter) 2014-04-09 19:36	^ doesn't alt+f4 when this happen avoid to zandronum update your ini file? And, now thinking better, it's too much work for just one or two maps that abused from it (+ they were jokewads) I think a simple "allow maps change your ini file YES/NO" would fix almost all bad stuff

(0008529) Dusk (developer) 2014-04-09 19:43 edited on: 2014-04-09 19:48	Quote There's no major, permanent damage that can be done to a client's computer just through ConsoleCommand FYI up till Zandronum 1.1 it was possible to overwrite arbitrary files by changing the sv_banfile CVAR. And there's been cases where mods posing as versions of popular WADs such as GVH have essentially made ini files bogus. Who knows what else is out there. ConsoleCommand is by design a security hole and should be treated as such. And since you seem to have not read the ticket, it's not getting axed before all (or at least most) known plausible use cases have been covered.

(0009583) Watermelon (developer) 2014-06-18 21:03	Quote else if ( ( Flags & CVAR_NOSETBYACS ) && ( ACS_IsCalledFromConsoleCommand() ) ) return; Is it possible to change this to Quote else if ( ( Flags & CVAR_ALLOWSETBYACS ) == 0 && ( ACS_IsCalledFromConsoleCommand() ) ) return; Or something whitelist based like Dusk suggested?

(0009636) Watermelon (developer) 2014-06-22 04:39	Also since we have a database now with accounts, the majority of CVAR client storage would be moved into the DB, which removes the only major reason I could think of for using ConsoleCommand.

(0011620) Dusk (developer) 2015-02-08 00:01 edited on: 2015-02-08 16:12	So I've been looking into an alternative to just blocking off the ConsoleCommand calls and hardcoding checksums; I've been working on a prototype of a ConsoleCommand replacement implementation that parses the command strings and interprets whatever is allowed in a safe manner. This way we can safely deprecate the function. Note that ideally it would not mess with any CVars whatsoever so I'll probably need to add additional functionality to deal with that stuff. I've been looking around for use cases of ConsoleCommand and, while this is in no way an extensive list, found these: * Setting of dmflags. These can be covered with a new ACS function that changes level setup (as defined by MAPINFO, not by cvars). * I found a few unfortunate cases where it literally sets 'dmflags 12345678'. I could possibly parse the number here and mask-check for known flags and act accordingly. * map and changemap -- easy to translate to ChangeLevel() calls * Gamemode limits (fraglimit, winlimit, etc) -- should these be allowed? * Userinfo -- I found one script that allows a player to easily set their colors. I think WDI uses something like this to easily let the murderer rotate their color and camouflage into the populous? I think that particular use case could be replaced with an alias in KEYCONF though. I don't think ACS should be allowed to mess with userinfo at all. * Currently it allows setting of CVars that were not defined by the source (i.e. CVAR_AUTO) to remain compatible with the old way of defining custom server and client CVars. archivecvar may also be called on these CVars. * Gamemodes (switching between deathmatch, lms, etc). I don't know what to do here...

(0011645) Catastrophe (reporter) 2015-02-09 00:45 edited on: 2015-02-09 02:17	> * Gamemode limits (fraglimit, winlimit, etc) -- should these be allowed? > * Gamemodes (switching between deathmatch, lms, etc). I don't know what to do here... I have setup pukes on my mods to automatically set the dmflags, gamemode, point limits, startmap, and mapinfo (via addmap + sv_usemaprotation consolecommand). This was added to make it easier to both test my mod quickly, and let players setup a server without any effort. I'd like if those stayed.

(0011646) Torr Samaho (administrator) 2015-02-09 07:05	Can't the default values / settings be supplied with an alias defined in KEYCONF? I'd prefer not to allow mods to enforce certain dmflags. It should be up to the server admin to decide which flags are used.

(0011647) Blzut3 (administrator) 2015-02-09 19:49	Kind of contradicting what I said earlier in this ticket (but I'm mostly just trying to remind people this exists pretty much for this exact purpose): For easy setup of "good defaults" wouldn't extending CMPGNINF support be a better idea? Could have cvars to enable using the defaults given there.

(0011649) Torr Samaho (administrator) 2015-02-10 07:05	So a CVAR that enforces the CMPGNINF settings in multiplayer? Could work too.

(0012807) Dusk (developer) 2015-06-27 01:52 edited on: 2015-06-27 01:52	A very WIP build here, courtesy of WaTaKiD:'https://www.dropbox.com/s/nih90sj50mp9ggb/zandronum-3.0-150627-0146-adca3f3-windows.zip?dl=0 [^]' Mostly exists to gauge exactly how badly mods are broken with this setup.

(0017426) Fused (reporter) 2017-04-29 18:02 edited on: 2017-04-29 18:02	I noticed with the recent build, ConsoleCommand doesn't seem to work at all anymore. I understand the devteam does not care too much about it since it has to dissapear, but it would be nice to see it fixed to keep support for mods available still, like WhoDunIt. Shall I make a wad to try ConsoleCommand, so it can be fixed? EDIT: I tried Crouch, +Crouch, and various Set commands and none of them worked with the new build. They did work before that.

(0017427) Torr Samaho (administrator) 2017-04-29 18:05	ConsoleCommand is still supposed to work in 3.0. So yes, please make a minimal example wad.

(0017429) Fused (reporter) 2017-04-29 18:25 edited on: 2017-04-29 19:25	Sorry. This actually appears to be a compiler error rather than an engine error. I use GDCC-ACC to compile, and it works with ACC. I can't figure out why it doesn't work, but I noticed I can't find the command being defined anywhere in ACC, whilst GDCC-acc has 'void {133, 134}:ConsoleCommand(str)'. I can't remove that without getting an error. I use the compiler linked at'http://acsutils.strangled.net/doku.php?id=using_acsutils [^]' EDIT: apparently ACC has the function build into the EXE. EDIT: Turns out GDCC is just very unstable with these new functions. It works with a different version of GDCC without the functions added. Ignore that post.

(0019195) HellBlade64 (reporter) 2018-05-06 05:21	Except for the fact that Zandronum and other forks of ZDoom specifically have a system in place that prohibits ConsoleCommand from operating in an undesirable\malicious way. In my testing it works just fine to stop me from making a player say something like "I'm gay!" if the script is only called once. But if you brute force the script, that is, have another script repeatedly call the script containing the ConsoleCommand function on a one tick delay, the engine's internal command prohibition check won't keep up with the amount of times the command is being called which is a command each tick. Thirty-five ticks is a second, so about 2100 ConsoleCommand("say I'm gay!")s happen in a minute. Then again, I did that around three\four years ago, and there have been plenty of changes to the engine. So they may have already patched that out.

(0019452) Ivan (reporter) 2018-08-30 10:41	Make sure to provide functions that make spectators spectate certain players, and/or expose the "spynext" and "spyprev" commands as functions if this is removed. I can make a seperate ticket for this if needed.

(0019456) Leonard (developer) 2018-08-30 12:34	Does using ChangeCamera on another player's body work? If not then yes making a ticket is a good idea.

(0019457) Ivan (reporter) 2018-08-30 14:22 edited on: 2018-08-31 00:20	I just made a test wad. It appears the view is transferred properly but the hud information still shows the main player and not the one being watched. I guess that's not a big problem when the information would be hidden, but if there was ever an option to see them then this would be lacking. Here's the test file:'https://www.dropbox.com/s/o8vd4kbqwa7l0zg/cameratest.pk3?dl=0 [^]' -- Just join the same server twice and "puke 100" as players besides player 2, and you'll see that player's view. So the question is: Should a new ticket be made to extend it to show, that, if a player is being watched, their health, ammo etc.? BIG CORRECTION: Players desync, height doesn't refresh (player is thought to be the first height I start watching them), their weapons don't bob... This is just a mess.

Only registered users can voice their support. Click here to register, or here to log in.
Supporters:	unknownna Dusk Ijon Tichy AgentME Esum Thetis Leonard Lollipop MaxRideWizardLord WubTheCaptain mifu WaTaKiD
Opponents:	Balrog ZzZombo Toxicity ibm5155 Monsterovich

Issue History
Date Modified	Username	Field	Change
2012-09-26 15:15	Watermelon	New Issue
2012-09-26 15:31	Watermelon	Note Added: 0004811
2012-09-26 15:38	Qent	Note Added: 0004812
2012-09-26 17:45	MazterQyoun-ae	Note Added: 0004813
2012-09-26 17:45	MazterQyoun-ae	Note Edited: 0004813	View Revisions
2012-09-26 17:46	MazterQyoun-ae	Note Edited: 0004813	View Revisions
2012-09-26 17:51	MazterQyoun-ae	Note Edited: 0004813	View Revisions
2012-09-27 19:54	Torr Samaho	Note Added: 0004830
2012-09-29 22:49	Blzut3	Note Added: 0004850
2012-09-30 23:56	Dusk	Note Added: 0004887
2012-10-01 00:03	Edward-san	Note Added: 0004888
2012-10-01 00:06	Dusk	Note Edited: 0004887	View Revisions
2012-10-01 00:11	Dusk	Note Added: 0004889
2012-10-01 00:13	Dusk	Note Edited: 0004889	View Revisions
2012-10-01 00:14	Dusk	Note Edited: 0004889	View Revisions
2012-10-01 00:14	Dusk	Note Edited: 0004889	View Revisions
2012-10-01 10:58	Dusk	Note Added: 0004892
2012-10-01 10:58	Dusk	Status	new => feedback
2012-10-01 11:01	Dusk	Note Edited: 0004892	View Revisions
2012-10-01 12:55	Blzut3	Note Added: 0004895
2012-10-01 13:41	Dusk	Note Added: 0004896
2012-10-01 16:03	Qent	Note Added: 0004898
2012-10-01 20:03	Torr Samaho	Note Added: 0004899
2012-10-01 20:30	Dusk	Note Added: 0004902
2012-10-01 21:35	Blzut3	Note Added: 0004903
2012-10-02 13:36	Watermelon	Note Added: 0004911
2012-10-02 13:36	Watermelon	Status	feedback => new
2012-10-02 13:55	Watermelon	Note Added: 0004912
2012-10-02 13:55	Watermelon	Note Edited: 0004912	View Revisions
2012-10-02 15:23	ZzZombo	Note Added: 0004913
2012-10-02 16:43	Blzut3	Note Added: 0004914
2012-10-02 17:44	Watermelon	Note Added: 0004915
2012-10-02 17:46	Watermelon	Note Edited: 0004915	View Revisions
2012-10-05 19:28	Llewellyn	Note Added: 0004968
2013-02-10 21:04	Ijon Tichy	Note Added: 0005987
2013-02-10 21:07	Ijon Tichy	Note Edited: 0005987	View Revisions
2013-02-11 08:16	ZzZombo	Note Added: 0005995
2013-02-11 08:22	ZzZombo	Note Edited: 0005995	View Revisions
2013-02-11 13:17	Ijon Tichy	Note Added: 0005999
2013-02-11 15:39	ZzZombo	Note Added: 0006000
2013-02-11 16:14	Watermelon	Note Added: 0006001
2013-02-11 17:30	Torr Samaho	Note Added: 0006003
2013-02-11 22:38	Blzut3	Note Added: 0006007
2013-02-11 23:01	bluewizard	Note Added: 0006009
2013-02-11 23:25	Dusk	Note Added: 0006010
2013-02-12 03:31	ZzZombo	Note Added: 0006011
2013-02-12 06:16	Torr Samaho	File Added: setcar.patch
2013-02-12 06:16	Torr Samaho	File Deleted: setcar.patch
2013-02-12 06:17	Torr Samaho	File Added: setcvar.patch
2013-02-12 06:22	Torr Samaho	Note Added: 0006013
2013-02-12 18:30	Blzut3	Note Added: 0006014
2013-02-12 21:33	Theshooter7	Note Added: 0006015
2013-02-12 21:34	Theshooter7	Note Edited: 0006015	View Revisions
2013-02-12 21:36	Theshooter7	Note Edited: 0006015	View Revisions
2013-03-01 22:32	Gez	Note Added: 0006090
2013-03-13 00:45	XutaWoo	Note Added: 0006110
2013-05-03 20:17	Ijon Tichy	Note Added: 0006313
2013-05-04 15:52	Gez	Note Added: 0006314
2013-05-15 18:46	Ijon Tichy	Note Added: 0006332
2013-05-15 18:47	Ijon Tichy	Note Edited: 0006332	View Revisions
2013-05-15 18:48	Ijon Tichy	Note Edited: 0006332	View Revisions
2013-05-15 22:00	AgentME	Note Added: 0006335
2013-05-15 22:22	Dusk	Note Added: 0006336
2013-06-11 23:42	Dusk	Relationship added	parent of 0001351
2013-06-11 23:44	Dusk	Note Added: 0006427
2013-06-22 21:35	Mr. Wint	Note Added: 0006477
2013-06-23 00:49	Dusk	Note Added: 0006479
2013-06-23 00:49	Dusk	Note Edited: 0006479	View Revisions
2013-06-24 01:33	Mr. Wint	Note Added: 0006496
2013-06-24 01:42	Dusk	Note Added: 0006497
2013-06-24 06:43	Qent	Note Added: 0006498
2013-06-24 06:43	Qent	Note Edited: 0006498	View Revisions
2013-06-24 11:24	Dusk	Note Added: 0006499
2013-06-24 14:56	Balrog	Note Added: 0006500
2013-06-24 19:41	Dusk	Note Added: 0006501
2013-06-24 19:41	Dusk	Relationship added	related to 0001378
2013-06-24 19:42	Dusk	Relationship deleted	related to 0001378
2013-06-24 19:42	Dusk	Relationship added	parent of 0001378
2013-06-25 02:57	Mr. Wint	Note Added: 0006505
2013-06-25 17:21	Dusk	Note Added: 0006507
2013-06-27 22:54	Balrog	Note Added: 0006517
2013-07-04 20:15	RusselCS	Note Added: 0006572
2013-07-05 22:40	RusselCS	Note Deleted: 0006572
2013-07-20 01:27	Blzut3	Relationship added	related to 0001415
2013-07-22 23:53	Dusk	Relationship added	related to 0001426
2013-08-10 12:55	Torr Samaho	Note Revision Dropped: 6972: 0003926
2013-08-11 07:15	Torr Samaho	Note Added: 0006988
2013-08-11 08:24	ZzZombo	Note Added: 0006990
2013-08-11 08:37	Torr Samaho	Note Added: 0006992
2013-08-11 14:00	Konar6	Note Added: 0006994
2013-08-11 17:00	ZzZombo	Note Added: 0006996
2013-08-11 20:47	Torr Samaho	Note Added: 0006997
2014-01-23 19:45	StrikerMan780	Note Added: 0008127
2014-01-23 19:48	StrikerMan780	Note Edited: 0008127	View Revisions
2014-01-23 20:03	StrikerMan780	Note Edited: 0008127	View Revisions
2014-01-23 20:03	StrikerMan780	Note Edited: 0008127	View Revisions
2014-01-23 20:04	StrikerMan780	Note Edited: 0008127	View Revisions
2014-01-23 20:09	StrikerMan780	Note Edited: 0008127	View Revisions
2014-01-29 20:19	Dusk	Relationship added	related to 0001688
2014-04-06 22:31	Toxicity	Note Added: 0008510
2014-04-06 22:32	Toxicity	Note Edited: 0008510	View Revisions
2014-04-09 19:36	ibm5155	Note Added: 0008527
2014-04-09 19:43	Dusk	Note Added: 0008529
2014-04-09 19:44	Dusk	Note Edited: 0008529	View Revisions
2014-04-09 19:45	Dusk	Note Edited: 0008529	View Revisions
2014-04-09 19:46	Dusk	Note Edited: 0008529	View Revisions
2014-04-09 19:48	Dusk	Note Edited: 0008529	View Revisions
2014-04-09 19:48	Dusk	Note Edited: 0008529	View Revisions
2014-06-18 21:03	Watermelon	Note Added: 0009583
2014-06-22 04:39	Watermelon	Note Added: 0009636
2014-06-25 10:18	Dusk	Relationship added	parent of 0001858
2015-02-08 00:01	Dusk	Note Added: 0011620
2015-02-08 00:01	Dusk	Assigned To	=> Dusk
2015-02-08 00:01	Dusk	Status	new => assigned
2015-02-08 00:03	Dusk	Note Edited: 0011620	View Revisions
2015-02-08 00:05	Dusk	Note Edited: 0011620	View Revisions
2015-02-08 00:07	Dusk	Note Edited: 0011620	View Revisions
2015-02-08 16:12	Dusk	Note Edited: 0011620	View Revisions
2015-02-08 16:12	Dusk	Note Edited: 0011620	View Revisions
2015-02-09 00:45	Catastrophe	Note Added: 0011645
2015-02-09 00:46	Catastrophe	Note Edited: 0011645	View Revisions
2015-02-09 02:17	Catastrophe	Note Edited: 0011645	View Revisions
2015-02-09 07:05	Torr Samaho	Note Added: 0011646
2015-02-09 19:49	Blzut3	Note Added: 0011647
2015-02-10 07:05	Torr Samaho	Note Added: 0011649
2015-06-27 01:52	Dusk	Note Added: 0012807
2015-06-27 01:52	Dusk	Note Edited: 0012807	View Revisions
2016-04-30 12:38	Dusk	Relationship added	parent of 0002715
2017-04-29 18:02	Fused	Note Added: 0017426
2017-04-29 18:02	Fused	Note Edited: 0017426	View Revisions
2017-04-29 18:05	Torr Samaho	Note Added: 0017427
2017-04-29 18:25	Fused	Note Added: 0017429
2017-04-29 18:27	Fused	Note Edited: 0017429	View Revisions
2017-04-29 19:25	Fused	Note Edited: 0017429	View Revisions
2017-10-29 21:00	Dusk	Relationship added	parent of 0003313
2018-03-23 12:14	Leonard	Relationship replaced	parent of 0001688
2018-05-06 05:21	HellBlade64	Note Added: 0019195
2018-08-30 10:41	Ivan	Note Added: 0019452
2018-08-30 12:34	Leonard	Note Added: 0019456
2018-08-30 14:22	Ivan	Note Added: 0019457
2018-08-30 14:23	Ivan	Note Edited: 0019457	View Revisions
2018-08-30 14:23	Ivan	Note Edited: 0019457	View Revisions
2018-08-31 00:20	Ivan	Note Edited: 0019457	View Revisions
2018-10-21 12:21	Leonard	Relationship added	parent of 0003556
2018-10-21 12:21	Leonard	Relationship added	parent of 0003557
2019-06-04 21:54	Dusk	Status	assigned => new
2023-04-05 13:46	WaTaKiD	Relationship added	parent of 0004122
2023-04-05 13:47	WaTaKiD	Relationship added	parent of 0004123
2023-04-05 13:47	WaTaKiD	Relationship added	parent of 0004124
2023-04-05 19:10	Kaminsky	Relationship added	parent of 0004125
2023-04-05 19:10	Kaminsky	Relationship added	related to 0004126
2023-04-05 19:11	Kaminsky	Relationship deleted	related to 0004126
2023-04-05 19:11	Kaminsky	Relationship added	parent of 0004126
2024-04-22 01:09	Kaminsky	Relationship added	parent of 0004236