Terminal dosen't show logs when it's related to a player

So the problem is, that when I try to log something that a player triggered, it won’t show it in the server terminal.

Tested on server version 5848 and it worked well, meaning it was caused by some update.

  1. Client (production/canary) and FXServer version: Client unrelated | Server FXServer-master v1.0.0.6037 Linux
  2. What you expected to happen: When a player triggers some function that supposes to print something, it will log it in the server terminal. As it worked until some update broke it.
  3. What actually happens: If a player triggers something that should print something in the terminal, it won’t show it. But if the server triggers it, it will show it just fine.
  4. Category of bug (eg. client, server, weapons, peds, native): server.
  5. Reproducible steps, preferably with example script(s):

a. Have this script (server sided):

RegisterCommand("testteleport", function(source, args, rawCommand)
	for k, v in pairs(GetPlayers()) do
        print(k, v)
		SetEntityCoords(GetPlayerPed(v), 0.0, 0.0, 70.0)
	end
	print("Teleporting all players, executed by: "..source)
end)

b. Enter the server and try executing this command from the server terminal.
It should teleport all the players and print something that looks like that:

[      script:runcode] 1	1
[      script:runcode] Teleporting all players, executed by: 0

c. Try running it again from a client that is connected.
You’ll see that as before, all players will be teleported, but no console log will be printed at all on the server terminal.

This is an intentional change from another user request (Remove "access denied" console print - #6 by d-bubble) and there’s a configuration option to change this filter (con_channelFilter stuff).

However, I’m not sure if this is meant to filter stuff from script: prefix too by default (I believe the default filter was set to cmd only?) so it might be a random bug there anyway.

Nope, the default is indeed to filter any forwarded output, likely because there were other cases where people got confused at the server console containing ‘client output’ for commands.

Running con_removeChannelFilter forward:*/* noprint should put back the old behavior though by then you might want to use con_addChannelFilter forward:*/cmd* noprint if you e.g. want to hide permission-denied messages.

It’s weird that it turned to be a default behavior…

Okay, can you explain what makes it ‘weird’, then, while the original behavior is somehow not weird? Output from a console command executed by a client gets redirected to the client executing it. If the output is something like a ‘list_stuff’ command listing stuff, it’d be ‘weird’ for the list of stuff to be output to the server console as well every time a client requests said stuff, especially given the use case mentioned in @Keyinator’s topic where ‘the server console is used to see if anything is wrong with the server’.

As mentioned in the other topic, this is unrelated to the concept of diagnostic output, and using diagnostic output in this way would be weird, since the requesting client would also see said diagnostic output in their console/chat, which is a tad unexpected. Instead, in the future, some other means for diagnostic output should be added, which may indeed be handled by a specific channel prefix or such- hard to tell at this time, and why this feature also wasn’t added yet until someone got pushy about it, since it would ideally be done at the same time as all the other output/diagnostics-related tasks.

Again, it’s really difficult to tell in advance what is and isn’t ‘weird’ or ‘unexpected’, so… yeah. Once this build would’ve been bumped to ‘recommended’ and gotten a changelog written it would’ve been noted as a change, of course, but that isn’t the case yet.

Because its just so basic that if you do console.log on server side, it will be printed on the server, meanwhile if you console.log on the client, it will be printed on the client that is executing it.
There is no wrong about also sending the output to the client who’s executing the command, but its just makes sense to display it on the terminal as well - because as the scripting command say Console Log, meaning it should log it in the console. If I don’t want it to show there, I wouldn’t use it and send a log through an event myself.
Also it’s not doing it only on commands, also on events that being triggered by clients, etc…

What happened to me is that I restarted a resource and had an error on a server script initial, and it didn’t output the error because it sent it to the client that executed the restart, which wasn’t able to print it because the restarting resource is the listener for this printMessage event (that I was also planning on removing, because I don’t need the clients to know the output from commands), and it didn’t load yet. Resulting that it just didn’t show the error and had me test it for about more 30 minutes.

Bottom line, I can understand how this is acceptable, but I wouldn’t think it should have been a default as I wouldn’t think it would behave like that. Makes sense I posted it as a bug report.

I also asked some friends why they think this is happening and none of them said it could have been planned, we all thought it was a bug or a typo of some sort, by a programmer

Except, as shown in @Keyinator’s request and other people being confused by that, apparently not.

… that’s the name it has for compatibility with JS libraries. Similarly, even by that definition, it does ‘log it in the console’, on the side that executed the command.

Impossible, this prefix only gets used for forwarded console commands. If that is the case, it’d be a bug and you should provide a repro for that.

The rest of your message is just you assuming everyone is you and thinks like you, including stuff like ‘remove the print listener […] don’t need the clients to know the output from commands’ (i.e. you’re already having non-default requirements and expectations) and otherwise for whatever reason refusing to understand and accept the explanation and context here.

(in fact, you’d not have run into this issue if you’d not somehow messed with ‘the print listener’ for this god-knows-what reason)

Similarly, instead of asking ‘some friends’ who also instead of looking into it just use their own myopic assumptions, you could’ve just asked here or anywhere, without making it a ‘bug report’.

Behavior like this is why any time you post anything, I get extremely stressed since you keep behaving like this, acting as if anything we do here is ‘useless’ and ‘wrong’ and ‘everyone thinks it sucks’ and so on, as also evidenced by you somehow tearing down default behavior for whatever reason, and then when other behavior is changed to fit the existing default behavior better, you then just come out of nowhere being even weirder, blaming for changing the defaults because they conflict with your ‘printMessage event’ whatever-the-hell.

And then, instead of conceding and going ‘ah, okay’, you just continue on and on and on, trying to provide more and more and more blame, seriously?

I’m done with this discussion. Really not going to get any better.