Zandronum Chat on our Discord Server Get the latest version: 3.1
Source Code

View Issue Details Jump to Notes ] Issue History ] Print ]
IDProjectCategoryView StatusDate SubmittedLast Update
0001070Zandronum[All Projects] Suggestionpublic2012-09-26 15:152024-04-22 01:09
Assigned ToDusk 
PlatformOSOS Version
Product Version1.0 
Target VersionFixed in Version 
Summary0001070: Phasing out the dangerous ConsoleCommand for various additional/improved ACS commands
DescriptionAs brought up before, ConsoleCommand has been a very useful tool for modders to access things on the server that they can't normally access. However, there are mods that use this to set things that confuse the player or do malicious things to a connecting players computer. To prevent malicious things from happening, the best thing would be to either limit what can be done with ConsoleCommand, or to remove it and replace it with something like SetCVar(str cvar, [bool] archiveCvar), and maybe any other features also get their own ACS command that mod developers can use (like InvokeCrashError(str reason) instead of allowing ConsoleCommand("error Improper player setup, please contact server host")).

There are a few problems that come to mind, such as:
- ConsoleCommand("unbindall")
- ConsoleCommand("set some obscure variable here that will mess up the player like autoaim off or models to 0 or something weird to true that messes with the renderer")
- [for loop] str newString1..9999999 ConsoleCommand("flood console with crap variable here by setting and archiving junk with the purpose of flooding computer space")

So far there is a use for ConsoleCommand and no one has really done the above (we'll there was one guy who tried something in ZDW but that's been taken care of). The best thing to do is find things that mod developers use it (or rather, exploit it for) and create new functions around this that safeguard ridiculous stuff.

For example, AOW uses it to force HUD_Scale true, which to someone like me is fine because I just turn it off after I'm done, though newbies who don't know anything about cvars or such end up going into other matches complaining that their screen is massively large. The best solution I think is a compatflag for 'large scale doom hud size' or something.
In addition, most mod developers like myself only really use consolecommand

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), of which both of those will have to be used to protect native cvars so mod developers cannot mess with it. Sometimes we like to check those cvars however to make sure someone isn't cheating or abusing them for an advantage (like turning textures off to see things better, or making lights extremely bright).
Attached Filespatch file icon setcvar.patch [^] (2,479 bytes) 2013-02-12 06:17 [Show Content]

- Relationships
parent of 0001351closedTorr Samaho Backport ZDoom revisions r4280, r4283, r4292 (Official CVar and User CVar support in ACS) 
parent of 0001378closedTorr Samaho sv_forcerandom: Force the use of a random player class 
parent of 0001688resolvedKaminsky GetPlayerChasecam and SetPlayerChasecam ACS functions. 
parent of 0001858closedDusk Client-to-server mechanism to ACS_Execute to supersede ConsoleCommand("puke") 
parent of 0002715resolvedKaminsky Scripting access to dmflags and co 
parent of 0003313resolvedKaminsky ACS Function to switch Game mode. 
parent of 0003556resolvedKaminsky Letting modders change player class without ConsoleCommand 
parent of 0003557closed Letting modders change game mode without ConsoleCommand 
parent of 0004122needs testingKaminsky SetPlayerSkin and skin related functions 
parent of 0004123resolvedKaminsky Functions for adding and removing bots 
parent of 0004124new A method of enforcing Zandronum client cvars 
parent of 0004125new A function that replicates `map` (and `changemap`) 
parent of 0004126resolvedKaminsky ACS function to open specific OptionMenus 
parent of 0004236closed ACS function to create temporary CVars 
related to 0001415closedTorr Samaho Prevent the error_fatal and error commands from being used with ConsoleCommand() 
related to 0001426new Make ConsoleCommand whitelist-based 
Not all the children of this issue are yet resolved or closed.

-  Notes
User avatar (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)?
User avatar (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.
User avatar (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).

User avatar (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...
User avatar (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 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).
User avatar (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.

User avatar (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...
User avatar (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.

User avatar (0004892)
Dusk (developer)
2012-10-01 10:58
edited on: 2012-10-01 11:01

For consolecommand(puke), I made this in response:
' [^]'

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..

User avatar (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.
User avatar (0004896)
Dusk (developer)
2012-10-01 13:41

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.
User avatar (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.
User avatar (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.
User avatar (0004902)
Dusk (developer)
2012-10-01 20:30

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?
User avatar (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.
User avatar (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.
User avatar (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

User avatar (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
User avatar (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.
User avatar (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.

User avatar (0004968)
Llewellyn (reporter)
2012-10-05 19:28

As a modder, I love ConsoleCommand.
It has many uses, such as one being:

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.
User avatar (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:' [^]'

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".

User avatar (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.

User avatar (0005999)
Ijon Tichy (reporter)
2013-02-11 13:17

The thing is, UseInventory exists. Just use that.
User avatar (0006000)
ZzZombo (reporter)
2013-02-11 15:39

+use/fire/forward/etc can't be scripted in that way.
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.
User avatar (0006001)
Watermelon (developer)
2013-02-11 16:14

Can't you use ThrustThing/Z to emulate +forward/back/side and SetActorState to emulate firing?
User avatar (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

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.
User avatar (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.
User avatar (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().
User avatar (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.
User avatar (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.
User avatar (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.
User avatar (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.
User avatar (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)

User avatar (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.
User avatar (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.
User avatar (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.
User avatar (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.)
User avatar (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.' [^]'

User avatar (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.)
User avatar (0006336)
Dusk (developer)
2013-05-15 22:22

@Ijon: interesting, I'll have to take that to use. One less of these little buggers...
User avatar (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.
User avatar (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.
User avatar (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.

User avatar (0006496)
Mr. Wint (reporter)
2013-06-24 01:33

The Cutstuff community doesn't seem to mind. ' [^]' Some classes for Mega Man 8-Bit Deathmatch are considered unbalanced.
User avatar (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).
User avatar (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.

User avatar (0006499)
Dusk (developer)
2013-06-24 11:24

And in either case a messed up user config.
User avatar (0006500)
Balrog (reporter)
2013-06-24 14:56

I don't think Wint here understands how to file a proper ticket.

' [^]'
User avatar (0006501)
Dusk (developer)
2013-06-24 19:41


Marked as related.
User avatar (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(). ' [^]'

And finally, trying to balance over 60 classes is not a trivial task, especially given the wide variety of game modes available.
User avatar (0006507)
Dusk (developer)
2013-06-25 17:21

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.


Can't this be done by applying the FallingDamage flag to the defaultmap?
User avatar (0006517)
Balrog (reporter)
2013-06-27 22:54

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?
User avatar (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.
User avatar (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?
User avatar (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.
User avatar (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.
User avatar (0006996)
ZzZombo (reporter)
2013-08-11 17:00

CCblockexemptlist.txt where admins could manually add hashes of hosted mods?
User avatar (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.
User avatar (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.

User avatar (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.

User avatar (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
User avatar (0008529)
Dusk (developer)
2014-04-09 19:43
edited on: 2014-04-09 19:48

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.

User avatar (0009583)
Watermelon (developer)
2014-06-18 21:03

else if ( ( Flags & CVAR_NOSETBYACS ) && ( ACS_IsCalledFromConsoleCommand() ) )

Is it possible to change this to

else if ( ( Flags & CVAR_ALLOWSETBYACS ) == 0 && ( ACS_IsCalledFromConsoleCommand() ) )

Or something whitelist based like Dusk suggested?
User avatar (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.
User avatar (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...

User avatar (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.

User avatar (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.
User avatar (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.
User avatar (0011649)
Torr Samaho (administrator)
2015-02-10 07:05

So a CVAR that enforces the CMPGNINF settings in multiplayer? Could work too.
User avatar (0012807)
Dusk (developer)
2015-06-27 01:52
edited on: 2015-06-27 01:52

A very WIP build here, courtesy of WaTaKiD:' [^]'
Mostly exists to gauge exactly how badly mods are broken with this setup.

User avatar (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.

User avatar (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.
User avatar (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' [^]'

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.

User avatar (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.
User avatar (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.
User avatar (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.
User avatar (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:' [^]' -- 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.

Issue Community Support
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

Questions or other issues? Contact Us.


Copyright © 2000 - 2024 MantisBT Team
Powered by Mantis Bugtracker