[crossfire] channels

[Brendan Lally]

On Sunday 24 Apr 2005 16:04, tchize wrote:
>
     
      Hello, i saw this in channels, file c_chat.c:
     
     >
     
      {"literature", 5, "The contents of signs, scrolls, and other written
     
     >
     
      texts.",1},
     
     
Yeah, this is one of the system channels I have defined. The system channels 
are where all the server coded messages should go to, messages from other 
players are going to be handled with a different set of channels. (shout and 
chat are going to disappear as 'commands' they would appear as 'channels' 
that have no owner but are postable.

>
     
      The patch am working on is based on a subscribe/notify paradigm, not made
     
     >
     
      to handle channels like yours, as i think this is a different part and you
     
     >
     
      are doing quite well in it, but made to identify all kinds of readables
     
     >
     
      send to client by sending them with another command than draw_info. The
     
     >
     
      client subscribe to the server for the send of specialized data. Client can
     
     >
     
      subscribe to receiving books in a special way, subscribe to receiving signs
     
     >
     
      in a special way, subscribe to receiving motd in a special way, ...
     
     
Ok then, that shouldn't overlap at all, although it would be quite 
straightforward to have two seperate channels, a literature and a 
'literature2' channel. That way the player could turn on both, neither or 
either channel as they chose.

instead of 

new_draw_info(NDI_UNIQUE | NDI_NAVY, COMM_LITERATURE, op, tmp->msg);

have

new_draw_info(NDI_UNIQUE | NDI_NAVY, COMM_LITERATURE, op, tmp->msg);
tchize's_new_shiney_function(arguments, it, takes, COMM_LITERATURE2, op);

however, I don't know how well that would match up with what you describe, 
which sounds more powerful and flexible.

>
     
      Now, if your patch, in this part, is just about telling server 'send me or
     
     >
     
      do not send me literature' there will be no conflict in code logic and
     
     >
     
      there will in fact be complementarity.
     
     
Yeah, it is, in order to have your books work seemlessly with this, you would 
merely need to check that get_channel_state(pl,COMM_WHATEVER) is 1 somewhere 
in your alternate new_draw_info function (wherever it is you are checking for 
the existing listen levels currently.)

>
     
      But if your patch is about 'send me literature in a way so client can
     
     >
     
      identify it as literature' there will be a conflict of use.
     
     
client identification I haven't looked at yet, mostly because that is a client 
side thing and my patch is about server side support for filtering channels 
more easily. However, a way to get the gtk2 client to parse the channels 
command and allow their assignment to tabs would be an interesting thing for 
someone who knows gtk well to play with. In any event it will involve 
altering the comm protocol to send pri, which doesn't occur atm (probably 
calls for a 'newer_draw_info' command.....)