[crossfire] channels

[Mark Wedel]

  Few quick notes:
>>
     
       I estimated that there'd be around 20-30 different NDI_<message type>
     
     >>>
     
      fields.
     
     >
     
     
     >
     
     
     >
     
      well, how about if I actually count them?
     
     
  <snip>

  I don't mean how many there are right now.  I mean how many different unique 
ones there should be.  The item on the TODO list is to redo these messages, so 
like most things on the TODO list, bears little relation to what is there now.

>>
     
       That is one problem I have with both having channels and colors - from a
     
     >>>
     
      user perspective, how do I control preferences then?  For example, suppose
     
     >>>
     
      the preference I describe is based on channels.  How do you handle messages
     
     >>>
     
      that come in on that channel in a different color?  You can't really have a
     
     >>>
     
      selection for all those posibilities, so the client has to assume some
     
     >>>
     
      behaviour.  does it just use the defaults the user selects (tab, font,
     
     >>>
     
      color)?  Does it use the color it comes in as, but otherwise use same tab
     
     >>>
     
      and font?  etc.  That is why having only 1 attribute for all draw_info
     
     >>>
     
      calls makes things much easier to handle - if there is only 30 message
     
     >>>
     
      types, easy to present all those in a window to the user to choose their
     
     >>>
     
      defaults.
     
     >
     
     
     >
     
     
     >
     
      hmm, a thought that occurs is that one way that could work is if I changed the 
     
     >
     
      way the value was stored in pl->listening, so that the player could store 
     
     >
     
      their own colour for it there. -1 would be off, -2 banned >=0 would be on in 
     
     >
     
      the appropriate colour. 255 would be 'use what you are told to use'
     
     >
     
     
     >
     
      then if the player has a colour preference defined, their choice of colour is 
     
     >
     
      sent, otherwise, the channel one is.
     
     >
     
     
     >
     
      this could be parsed client side (by a script maybe?), so that you have a 
     
     >
     
      window to list the channels with an on/off button and an override colour 
     
     >
     
      option.
     
     >
     
     
     >
     
      do you want me to do that instead?
     
     
  If a channel only will use one color and only one color, that isn't much a 
problem.  The problem right now is that your both have channels and colors, eg, 
attack channel messages may come in several colors.  This makes handling 
preferences very difficult.

>>
     
       Note that these preferences are also stored client side.  So this makes
     
     >>>
     
      dynamic channels harder to handle - channel 25 may change its meaning run
     
     >>>
     
      to run, or perhaps even server to server.  I don't have a good solution for
     
     >>>
     
      that one.
     
     >
     
     
     >
     
     
     >
     
      which was why I was doing it server side.
     
     >
     
     
     
  Which I'm not sure is the right approach.  IMO, client appearance issues 
should be stored with the client, not on the server.  One way to think about 
this is that if I do set prferences for those 30 channels, I really don't want 
to have to do that again for each player I may start, and/or each server I play on.

  The general design philosphy is that anything that can be done on the client 
should be done on teh client.  Only stuff that can't be done on the client 
securely should be done on the server (securely in this context means not giving 
the client info it shouldn't have).  there are several reasons behind this 
philosphy, but mostly it boils down to trying to keep the server code as simple 
as possible (reduces CPU usage, less likely to be exploits, etc).

  But the problem, IMO, is beyond just storing it on the server.  Since channels 
are dynamic, a channel that exists one time I am playing may not exist (or may 
exist with a completely different purpose) the next day when I play.  So storing 
that on the client or server doesn't really make any difference - either way, 
the preferences I set before may no longer apply.  But I don't have a good 
solution to that either way - my real point that trying to set preferences on 
such dynamic channels will be very hard to deal with.