[crossfire] channels

[Mark Wedel]

Brendan Lally wrote:
>
     
     
     >>
     
       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.
     
     
  Yes, that helps out.  Problem is, the client still can't differentiate between 
it being a channel by color vs other messages.

  For example, if one of the colors is light blue, this works pretty good most 
of the time, but the client doesn't easily have a way to filter out the chat 
type messages compared to changes in resistance.

>
     
     
     >
     
     
     >>
     
       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
     
     >
     
     
     
The long term model here is that the NDI_color values go away (except for 
compatibility with older cleans) and the NDI values are instead meaningful 
relative to the content they are providing (eg, NDI_ATTACK, NDI_DEATH, NDI_MENU, 
etc).  Basically, instead of changing the listen levels, change the NDI values. 
  A range of values could be used for the channels (there has to be some 
relatively small (<30) limit of channels I'd think).



>
     
     
     >>
     
       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).
     
     
  True.  However, DM can only really check that the message was sent to the 
client - still no way of knowing if the player actually read it.

  So for the chat related channels, it probably does make sense that they are 
subscriber based.  But for the rest (another generated by the code), they should 
just be sent pretty much no matter what the listen level is.

>
     
     
     >
     
     
     >>
     
     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. 
     
     
  The thing is, from a protocol standpoint, much easier to do it the way I'm 
talking about.

  For all messages sent to the client, 1 byte is already used for the NDI value. 
  Of which there are only actually 12 values being used, leaving 240 other 
values that can be used without any changes to the protocol.  The only change is 
the adjustment for the client to do something meaningful with those newly 
defined NDI values.

  What you haven't addressed is how you get the listen level info to the client, 
because that is what is needed for the client to do anything meaningful. 
Without know your plans on that, hard to really say for sure, but my impression 
would be you'd send the listen level to the client, which means a new protocol 
command.

  The other thing I'm think about here is simplicity.  Having both channel 
values and colors being passed to new_draw_info commands just seems complicated 
on both sides.

  On the client side, it makes things much more complicated in letting the user 
set their prefs (you now have 12 * num channel possiblities).  For example, you 
oculd have both blue and black attack messages, so now potentially letting a 
user choose a style for both of those.

  Now certainly, a large number of combinations would never be used, but there 
is no simple way of knowing that (and nothing preventing that from not being in 
the case in the future).

  So what I'm saying, is I'd like to have just one value associated with each 
new_draw_info call which determines the info sent to the client - either the 
channel number or an NDI value.  And directly related, only one of those should 
be getting passed into the draw_info calls.

  If you want to use the channels, that fine, but then remove all the NDI values 
and write up a basic channel->conversion routine for old clients.  I just don't 
want to see both values there, because only one is really needed, and it would 
have to get cleaned up at some point - I'd rather it be done now vs later, 
because experience shows that it won't be done later