[crossfire] channels

[Brendan Lally]

On Tuesday 26 Apr 2005 07:41, Mark Wedel wrote:
>
     
        I guess the issue I see is that you add channels to basically every
     
     >
     
      draw_info call, without there really being a need to do so.
     
     >
     
     
     >
     
        IMO, it would be sufficient to have channels just for the chat related
     
     >
     
      stuff - that would have been a much more modest patch and probably
     
     >
     
      basically given the level of functionality needed.
     
     
it wouldn't have tied in so nicely with the listen levels though, because the 
listen levels would all be different, ranging from 0 to 15. numerous 
assumptions are made that they are now 

>
     
        From your list of defined COMM channels, there is either the case of the
     
     >
     
      channel being vary narrowly focused (COMM_JOINQUIT) and in other cases,
     
     >
     
      very broad (COMM_EFFECT, COMM_ACTION).
     
     
Well, pretty much comm_effect is something that should be on always unless you 
are running a script or long keybinding. comm_action is a buffered 
comm_effect.

bots will want to turn these channels (and almost all others) off.

>
     
        There is nothing inherently wrong with the patch.  I just look at it and
     
     >
     
      think "it's taken a lot of work to change all the new_draw_info() calls,
     
     >
     
      but doesn't go far enough to actually fix up the client preference/styling
     
     >
     
      side of things". So with all those changes, the following item from the
     
     >
     
      TODO list basically remains:
     
     >
     
     
     >
     
      - Change draw_info so that server tells client what type of message it is
     
     >
     
         instead of the color.  Client can then decide what color to draw it
     
     >
     
         or other special handling.
     
     >
     
     
     >
     
        which will have to get done in the future.
     
     
yeah, except that instead has roughly mutated into 'as well' (at least 
temporarily).

I can use the high nybble of new_draw info for the channel number. That gives 
16 values immediatly, so I budge the existing system messages into 13 of 
those values (16*channel_number) with 0 used for custom channels. (shout and 
chat would be 'server' channels under the new definition).  
then the client can check only the high nibble and assign colours to those 
messages in it's own little dialog.

the colour value definitions would remain as a way to not affect old clients, 
noticably and 6-12 months later get removed. (which would make old clients 
display everything in black....). At that point custom channels could take 
the low nibble values. with channel number value being defined as.... 
mod(15)+(value-mod(15)) (no, probably isn't the nicest thing to do, but it 
will break the least.)

(optional) at that point add a get_channel_name in the protocol, to let the 
client label the tabs better. 

>
     
        and I still don't like the fact that you have added subscribe ability to
     
     >
     
      many messages which are currently priority 0 (you always get them). 
     
     >
     
     
     >
     
      I just 
     
     >
     
      don't see any compelling reason why those were put into channels - as said
     
     >
     
      before, the problem is sure to arise that smeone will unsubscribe, and all
     
     >
     
      sorts of problems arise.  At some level, you don't give users the choice to
     
     >
     
      disable basic functionality, and IMO this falls into the case.
     
     >
     
     
     >
     
        The obvious fix is then to make it some certain channels can't be
     
     >
     
      unsubscribed, but then the question is what is the purpose of those
     
     >
     
      channels.
     
     
actually, setting listen 0 currently will turn them all off (I guess that has 
just never been done by accident before). It could probably be counted as a 
bug, but if so it is one that is relied on occasionally.

comm_respond should probbably be fixed on though.
arguably so should comm_ext.

>
     
        I'm just stuck looking at patch and thinking that to handle that TODO
     
     >
     
      point above, most of the changes you make will be undone/redone, which
     
     >
     
      does't make me really happy.  But probably isn't a reason to necessary not
     
     >
     
      do the patch - it just doesn't make me really happy.
     
     
er, I'd only really need to 
1) change the arguments of new_draw_info (I've changed the function itself 
already, so literally just 
1a) backup and make a seperate copy of c_chat.c
2) for i in $(ls server/*); do cat server/$i | sed s/NDI_UNIQUE \|/ / >$i.new; 
cat server/$i | sed s/NDI_[:alpha:]\,/ / > $i 
(I'll need to check the syntax on that)
3) compile and manually change some corner cases (and c_chat.c).
4) set the colour value in the channels as described earlier.

removing infomation is much easier than adding it....