Listen level?

[Leaf]

Has anyone tested, figured out or documented what the various listen levels filter out?

What is the default listen level?

For those wondering, the syntax is 'listen # (ex: listen 1, listen 2, etc. - listen 10) and can block things out such as shout.

[Atan]

Default listen level seems to be 9. I tried the different levels a week or two ago because I was annoyed by all the spam about what my pets were hacking, but annoyingly enough this is not suppressed before listen 2 if I remember well, and then almost everything else is suppressed. IMHO the listen levels are not presenty implemented in a useful way, and are strictly undocumented (I looked for docs in all the usual places when I was experimenting a bit)

EDIT: Actually it was with diseases I was practicing, not with pet monsters, when I did the aforementioned tests, and had disease running in several rooms at once whose effects scrolled very fast, which is bad with cfclient, with no separate window for tells, shouts, etc... Suppressing those messages needed a very low listen level, and thus presumably suppressed a lot of other (possibly more relevant) information at the same time.

[Salathar]

Creating a brand new character on localhost sets listen level to 9.

crossfire/socket/info.c, lines 163-193 has the function which sends the messages to the client

Code: Select all

/**
 * Sends message to player(s).
 *
 * flags is various flags - mostly color, plus a few specials.
 *
 * pri is priority.  It is a little odd - the lower the value, the more
 * important it is.  Thus, 0 gets sent no matter what.  Otherwise, the
 * value must be less than the listening level that the player has set.
 * Unfortunately, there is no clear guideline on what each level does what.
 *
 * pl can be passed as NULL - in fact, this will be done if NDI_ALL is set
 * in the flags.
 *
 * If message is black, and not NDI_UNIQUE, gets sent through output buffers.
 *
 */

void new_draw_info(int flags,int pri, object *pl, const char *buf)

client/common/newclient.h, lines 163-193 has some tips on colour representation of various levels.
I played around with grep a little and tried filtering out various uses of colours to determine what each one is used for, this is should be close to a complete list:

Code: Select all

#define NDI_BLACK       0       Kills, hits, quits, welcome back, praying, meditation,
                                seems like everythong from the bottom client window
#define NDI_WHITE       1       Party messages, but client is clever to print them in black
#define NDI_NAVY        2       'Client side commands'  'help, reding signs, traps, god, spell effect msgs
#define NDI_RED         3       Shouts, server, script, 'frosen by DM', diseases
#define NDI_ORANGE      4       Mail/Tells, 'you feel like your head is going to explode'
#define NDI_BLUE        5       Dragon 'you have gained ability',  'chat        /* Actually, it is Dodger Blue */
#define NDI_DK_ORANGE   6       Entered/left game                       /* DarkOrange2 */
#define NDI_GREEN       7       motd and initial greeting               /* SeaGreen */
#define NDI_LT_GREEN    8       Dm arrived/gone                          /* DarkSeaGreen,  which is actually paler */
                                                                        /* Than seagreen - also background color */
#define NDI_GREY        9
#define NDI_BROWN       10                                              /* Sienna */
#define NDI_GOLD        11      Not used anywhere
#define NDI_TAN         12      Not used anywhere                       /* Khaki */

Note: These are not one to one mappings to various listen levels, but only what is displayed in what colours. I just hope it it will be of some help

Another note: I did not make a typo in line numbers, this is just a bizarre coincidence

[Avion]

The numbers you show for the colours are not related to the listen levels.
The values shown are the define encodings and the text is a remark on what the colour should be used for (but there is no code to enfoce it).

There was a good exposition on listen levels in the mailing list archives a while ago. Basically I recall system messages are 0, shout is 1, other messages are usually 2 and join/death is 5 - there may be more and as you say at listen level 9 you get all messages.

Shout is set to 1 for a reason it wasn't supposed to be easy to filter out since it wasn't meant for conversaiton, just important messages. This is why noshout was written to prevent abuse. So you set listen level to 4 to filter out join/death messages, set it to 1 to filter out group chat and tell and set it to 0 to filter out shout. You can't filter out system messages.

[Casper]

In that case it is an excellent idea, if it gets implemented, to get rid of listen levels complely. Instead have some sort of pattern matching algorithm applied to the argument of listen, running from left to right. eg 'listen +all-chat-shout should enable everything except for chat and shout.

The command should act differentially to present setting, so commanding 'listen -kills should only disable kills, and 'listen +shout should only enable shout.

They can also be grouped for simpler control, like 'listen -all+comms-chat should enable all communication commands but chat.

[cavesomething]

Wouldn't this require that the message sending standard be changed? or maybe have the server store listen preferences for each client?

It might be easier to just use split window mode, shade the info window and run a script to do the same thing, using some custom filtering. I have done something similar myself in the past.
I still have the script somewhere.... [digs out old perl script from july]

Code: Select all

#!/usr/bin/perl
$|=1;
print STDERR "script is runnnig";
print "watch drawinfo\n";
while($output = <STDIN>){
if (((split ' ', $output)[2])==3){
print STDERR $output;
}}

This prints all messages with value 3 by them, can't remember off-hand what that was (might have been shouts), but certainly it should be trivial to change/extend to filter what you need....