[crossfire] channels

[Brendan Lally]

First point I'm going to make is that I posted an updated diff on the tracker.

On Monday 25 Apr 2005 04:43, Mark Wedel wrote:
>
     
        Looking at the patch, it in no way extends or lets the client know what
     
     >
     
      is on what channel.
     
     
Yeah, I mostly haven't got round to that bit yet. I've been focusing more on 
player created channels. However, I have already absorbed that in the process 
of implementing shout and chat as channels.

>
     
        The patch filters the different levels on the server and nothing more. 
     
     >
     
      IMO, that is of limited usefulness (I'd argue in many cases, a potentially
     
     >
     
      bad thing as a player could inadvertently turn of notification of
     
     >
     
      relatively important events).
     
     
good point, initialstate 2 should mean mandatory. and be used for COMM_RESPOND
this can be a TODO...

>
     
        The client itself still won't know what channel a message belong to, so
     
     >
     
      doesn't help in the case of different tabs for different messages.  So from
     
     >
     
      the original RFE, really only implements a portion of it.
     
     
In the latest version of it, which I have been playing with today, the 
channels are linked to NDI values too. I'm using this for chat and shout at 
the moment, as well as letting custom channels have their colour altered.

>
     
        What I'd much rather see is a changing of the NDI values to be
     
     >
     
      descriptive of the message (the com levels you describe would make good new
     
     >
     
      NDI values).  If we're going to change all the new_draw_info_.. calls, less
     
     >
     
      change them to that.
     
     
ok then, so if I alter new_draw_info to remove (or at least ignore) the 
'colour' flag (and then fetch from the channel def) then that will achieve 
what you describe. it is then merely a case of adding a NDI_FIXED_FONT 
define, and including it in the flags for COMM_RESPOND and COMM_LITERATURE

>
     
        This then does give the client the info on what the command is then about
     
     >
     
      (reply, literature, kills, etc) and so the client can decide what to do
     
     >
     
      with it. That could include deciding not to display it.
     
     
If it is server side (as it is at the moment) then it is possible to have a dm 
command to check that a player recieved a message. and for a channel owner to 
see who is listening to them. It is also needed for the channel names to 
become commands. (as they now do). If all the channels set their own NDI 
flags, then client filtering would still be possible too (things like 
Tchize's books).

>
     
      some day, NDI levels will get redone, making the change of listen levels
     
     >
     
      pretty much moot (as important can be gleaned from the NDI message type).
     
     
it does seem very much like we are looking at the same problem from opposite 
directions. You want to replace listen levels with NDI flags, I want to (and 
mostly have, bar a few minor modifications to the array in init_channels, and 
a small tweak in new_draw_info) absorb NDI flags into listen levels.