[crossfire] channels

[Mark Wedel]

Brendan Lally wrote:
>
     
     
     >
     
      well, you could do filtering client side, but if that is the case then there 
     
     >
     
      are two different means of filtering comms.
     
     >
     
     
     >
     
      I intend to have a total of 3 different classes of channel.
     
     >
     
     
     >
     
      system
     
     >
     
      server
     
     >
     
      and player.
     
     >
     
     
     >
     
      system channels are the ones defined in c_chat.c currently.
     
     >
     
      server ones are ones that the server admin would be able to define. (shout and  
     
     >
     
      chat would be two of these, which would be the default, but big servers like 
     
     >
     
      mf and cat2 might want a 'helpme' channel, or a trade channel, or an announce 
     
     >
     
      channel, or a off-topic channel, or a roleplay channel, or what have you).
     
     >
     
      player ones are the ones I had working as of yesterday, they are simply for 
     
     >
     
      players to use as they see fit. 
     
     >
     
     
     >
     
      In IRC terms then, system messages are NOTICES, server messages are channel 
     
     >
     
      traffic, and player messages are actually kinda a cross between /msg and IM 
     
     >
     
      'chat's
     
     
  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.

  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).

  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.

  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.

  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.

  Also, just as another note, the reason the newclient.h file (and NDI_ values 
exist) is because both the client and server must have a common reference for 
what values mean.  So if you send the channel info along the draw info (which I 
agree there is space in the value to do so), it does limited good unless the 
newclient.h file is updated to know what the values mean (the reason they are 
all in that file is that file can then just be copied to the client.)  That is 
also one reason I like the idea if extending the NDI flags, since that mechanism 
and definition already are established in the protocl and file itself.