[crossfire] channels

[Brendan Lally]

On Monday 25 Apr 2005 07:20, Mark Wedel wrote:
>
     
        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.
     
     
Ok then, I've posted another patch where this is resolved. all channels have 
NDI_ values attached to them, and new_draw_info fetches colour info from the 
channel instead of the flags argument.

>
     
      > 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.
     
     
but at least the 'I have it filtered' excuse doesn't work....

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

>
     
        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.
     
     
I'd send the colour value attached to the listen level to the client, which 
there is already support for.

>
     
        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.
     
     
er, blue messages would be on their own channel, seperate from black ones. If 
that is needed something like a COMM_DANGER channel could be used, just 
decide what messages should go there. 

>
     
        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
     
     
I'm not quite sure what you mean by a conversion routine. There are 2 bytes in 
new draw info. the first is used by the function, the second is sent. in 
hexidecimal that is 4 characters.
currently;
1 2 3 4
F F F F
  
4 is the colour hint. (default colour if you want to make the client be able 
to override it), all bar 3 of these are already used.
2 is the special flags, they combine with 4.
3 and 1 are unused. (though 3 is in the colour mask).

however, with only 15 system channels, they can each have a value in byte 3. 
(and colour mask can be changed to 0x0F rather than 0xFF). Do you mean then 
that I should somehow strip out the high nybble if the client isn't recent 
enough? (how do you propose to tell?)

In any event, new_draw_info still needs to have its arguments changed, but 
that is merely something easy and long-winded for when I have better things 
to avoid doing (unfortunatly I have rather too many things that meet that 
description over the next month....).