Log, A_Log to active player

[Hetdegon]

I just noticed Log() in ACS and A_Log() in DECORATE print the message to every active player if online. I'd like to request for it to be possible to use that for the activator player only as print() does.

The reason is that multiple messages (item pickups, obituaries, etc) are displayed in the "message area", log() does as well, but print() doesn't, and is really inflexible with no position options other than "in the way of your aiming". Furthermore, it doesn't appear to be possible to pass strings as arguments for calling scripts from DECORATE, which makes an ACS replacement troublesome.

As example, let's say a simple healing item that fails if you health is full, and logs that to let you know you can't use it now. That message is really not worthy of appearing in the middle of your aiming area, specially during combat. A_Log()/Log() print it as intended, but then every player will receive that message as well.

So my options are either to hardcore all strings (making life harder if people wants to examine/expand the code) in ACS and write my own line printer, which isn't really complicated, but would require disabling all other messages, or force all ACS messages to go in another area, cluttering the screen, and since it's not possible to send strings as parameters to scripts, item pickup messages would need to be hardcoded in ACS, difficulting readability and expansion of the code further on (and given the large amount of items in my particular case, it's beyond unwieldy) ... not to mention the messages wouldn't be logged to console if someone misses them. Or, I can force the game to be single-player only, but that might not be a welcomed move if it turns out fine.

As for implementation, given that some mods rely on the multicasting ability of Log(), a "log2()/echo()/msg()" function call or similar, with an equivalent DECORATE action function, would be the best option, as it would never clash with the original's behavior.

Please consider the addition of this feature.

[NeuralStunner]

It may not be necessary to make a new function, if a flags parameter can be added.

In addition to a "local" (activator only) flag, a "server only" flag could help with debug/administration for Client-Server ports. (In ZDoom, it could possibly log to the arbitrator.)

While this in mind, I would also like to see options to colorize the message based on user settings for pickups, obituaries, &c. Whether a flags field would be appropriate for that, I'm hesitant. (Since only one will apply at a time.) Once we have an idea where the function is going parameter-wise, I can post a new suggestion for that.

[Hetdegon]

Yes, that sounds good to me as well. The "server only" has limited uses but I can already think of a few things, so it's also a good idea. I think a simple integer flag should be able to cover those 3 cases (0 for default behavior, 1 for local only, 2 for server only, etc).
I recall it's possible to colorize log() output now, since a few git revisions ago (must double-check, not too sure, but can't do it from here), in that case it could be left to user implementation rather than adding more code to it.

[NeuralStunner]

I believe colorization is possible, yes, but not really practical (since you have to manually check the relevant CVar and interpret that number into a color code).

[Hetdegon]

Yeah just double checked and Log() and A_Log() can be colorized the same way as Print(), including TEXTCOLO definitions, so not too sure what you mean.
For the sake of clarity, though, and please take no offense, it'd be better to file that as a separate suggestion, to not detract from the original request. Which is having Log() and A_Log() so they can be targeted to activator instead of all players, aesthetics can definitely be left to implementation with existing capabilities.

[Matt]

I would love to have this. (Glad I searched "log" as well as "a_log" or there'd be 2 threads about this by now)

Sometimes you just want to give the player a hint or reminder that works aesthetically much better as a low-key text message in your console than a big, hard-ruled print popping up in the middle of your screen (and potentially interrupting the shooty stuff).

[arookas]

This would be awesome to have. It could also be used to make dynamic pickup messages for items.

[The Zombie Killer]

I'm pretty sure you can get similar functionality with HudMessage with a certain flag, but it's not perfect. I'd certainly like to have this feature as well

[NeuralStunner]

There ought to be [wiki=Print#Colors]color codes[/wiki] for the other message types, though. That would allow you to make messages configuration-friendly without weird hacks.

[Xaser]

I made a similar suggestion ages ago, so +1 for sure. Psychic's quickbuy messages currently spam all players across a network game and it'd be great to make it less so.

[Matt]

I'm pretty sure you can get similar functionality with HudMessage with a certain flag, but it's not perfect. I'd certainly like to have this feature as well

Now that I take a look at the wiki...

HUDMSG_LOG

I'll have to give this a try! (though even if it works it would be nice to have an A_Log so you don't need to define an ACS script for literally every message you want for this that might be called in ACS. Not sure what other limitations or weirdness might distinguish this from a log...) EDIT: see below

[Matt]

Problems with HudMessage so far:

- really painful to remember format.
- mandatory parameters mean extra bloat.
- ACS only, you'll have to define a new script every time you want DECORATE access.
- still surrounds the message with hard rules like print.
- logging to console does not mean it appears in the usual place, but the logged message is hidden until you bring up the console, while the ingame displayed text is on its usual distinct HudMessage layer.

Definitely not an acceptable replacement. As far as I can tell it's impossible to replicate equivalent "local log" function with this (though the logging does, in fact, appear restricted to the calling player).

[The Zombie Killer]

Yeah, that's what I meant by "not perfect" (I was on my phone, away from home at the time, hence why I didn't type out all the reasons)

[Matt]

Given this I had assumed "not perfect" implied some minor side effects or glitches, rather than fundamentally not doing what was required.

[Kinsie]

Gonna have to ask for something like this too. I like using A_Log for messages that cleanly interact with every other player message (ala quake), having them always broadcast to every player is a pain.