(or add an option to disable it)
… any more context as to how you’re causing this in the first place?!
Fair point 
It’s using the C# api’s [Command] decorator
[Command("clear", Restricted = true)]
private void Clear(int source, List<object> args, string raw) {
TriggerEvent("txaLogger:CommandExecuted", raw);
TriggerClientEvent("Keyinator:Chatmanager:ClearInstruction");
}
Maybe add another parameter for the decorator.
Alternatively one could make the function return a bool defining “shouldPrintOnFail”.
I think the many outputs are triggered by someone having this bound on a frequently used key.
Maybe some servers have a clear command to clear props for more fps or something.
Any update on this?
The output is making the built-in permission-system a pain.
No, this is a little more complex than removing this specific print or adding a toggle for it, and is rather a sign of a broader issue (client command output is still printed to the server console in addition to being printed to the invoking client, which is desirable for some cases but less desirable for other cases), and has various possible solutions including a generic ‘suppress output by channel’ feature and prefixing client commands with this channel, potentially adding multiple routing outputs for different spew channels.
Again, we don’t do half-measures. Removing the print in itself would be confusing in cases where it is desired as part of user diagnostics, and ‘adding an option’ would be silly since now there’s yet another option for yet another tiny thing that has to be maintained for all eternity, potentially leading to users again being confused about cases where it doesn’t show this output and then you find out ‘oh yeah it got disabled by some script I installed/someone suggested it/…’ which also doesn’t help.
How does this output make the subsystem printing said output ‘a pain’ in itself? You’re likely expecting to see something else in the console output, which is ‘a pain’ due to any ‘unwanted’ output, which in your case just happens to be this, but it could just as well be anything else.
This sounds way more easily resolved for your use case by e.g. grep -v’ing console output depending on what else you’re trying to see in there that becomes ‘a pain’ as a result of this, since again the issue of ‘console output is hard to parse for only significant things’ is a way more broader concern than just this print.
I just checked this, by the way, and running FXServer +exec blah | grep -v "Access denied for command" does correctly suppress this output from showing in the console, so if this request were that urgent for you to need to bump it, you’d be able to mitigate it fairly easily yourself as well. 
(by the way, on Windows you can easily get grep and other utilities using MSYS2)
Finally, you bumping a low-priority and fairly complex feature request after a little over a week with just ‘any update?’ is a little bit hostile, if you’d check the GitHub commits you’d see there’s barely any ‘update’ on anything this past week, even on way higher-priority things that have been in the backlog for way longer, in fact the only commits have been for super trivial things which this is not, or blocker bugs/regressions.
Vaguely bumping something this low-priority is only going to get your request covered with fear of even looking at it, especially since neither ‘removing’ it nor ‘adding a toggle’ is going to happen, and now the more complex implementation is also covered in random fear.
1 Like
Implemented, in a way, via tweak(server): prefix forwarded/rcon command channels · citizenfx/fivem@9715c26 · GitHub and feat(console): early support for channel 'filters' · citizenfx/fivem@1ddf3e4 · GitHub.
Documentation for these commands will hopefully follow in the near future, but the default should match your use case, while still showing output to the originating client, and allowing this to be enabled as well.
This implements part of the client->server command forwarding improvements work item that was apparently added to the eternal backlog on October 14th as a result of this request - other parts I believe pertained to the chat fallback being suppressed for manual bind inputs.
1 Like
First of all: Thanks a lot for the updates on this.
The Any update on this? was not meant as Has there been any progress since this week? but rather due to the fact that my original post was lacking a lot of information which I then updated. I wanted to make sure that the problem has (just) been acknowledged with the further information I provided.
depending on what else you’re trying to see in there that becomes ‘a pain’ as a result of this .
My main concern was that I use the console as a first way of checking for any unwanted discrepancies from expected server operation (script errors, etc.). However as shown above. The prints were pretty long and thus hindered us a lot.
Thanks for the commits. I’ll look into how we can use them 
Right, and this is understandable. I believe no acknowledgment was posted mainly because the actual request itself wouldn’t be implemented, and as such said acknowledgment (“this has been noted but won’t be implemented in this way”) could lead to a negative response in return (“why don’t you implement this simple thing? it’s so annoying”).
Not responding indeed was a bit open to interpretation, too, though. 
A ‘Noted.’ could’ve worked but could also have been too… empty.
… which is in itself a different issue yet again, see also the long-standing todo entry of an ‘issues tab’ of sorts being needed so that there’s a more persistent and structured place to show anything actionable.
Updating to a newer server version should be enough to use such, the default is to not print any output from client-forwarded commands, assuming that’s what is causing these prints.
1 Like