[crossfire] channels

Wed Apr 27 12:28:17 CDT 2005

On Wednesday 27 Apr 2005 06:50, Mark Wedel wrote:
>

        But the problem I see is that you don't add enough new channels that all

     >

      the NDI_... is now redundant.

ok then, suggest some more to add, and I'll add them.

The problem is that much NDI information now is redundent, or at least bears 
little relation to message content.

>

        I estimated that there'd be around 20-30 different NDI_<message type>

     >

      fields.

well, how about if I actually count them?

from a clean CVS checkout this morning...

bear in mind that this first count includes the colour definitions:

crossfire/colour_count/crossfire $for i in NDI_BLACK NDI_WHITE NDI_NAVY 
NDI_RED NDI_ORANGE NDI_BLUE NDI_DK_ORANGE NDI_GREEN NDI_LT_GREEN NDI_GREY 
NDI_BROWN NDI_GOLD NDI_TAN NDI_UNIQUE NDI_ALL; do echo $i $(grep -R $i * | wc 
-l); done
NDI_BLACK 24
NDI_WHITE 15
NDI_NAVY 31
NDI_RED 19
NDI_ORANGE 8
NDI_BLUE 17
NDI_DK_ORANGE 9
NDI_GREEN 2
NDI_LT_GREEN 5
NDI_GREY 2
NDI_BROWN 3
NDI_GOLD 1
NDI_TAN 1
NDI_UNIQUE 1376
NDI_ALL 25

also we will check for all those messages that combine a colour and NDI_UNIQUE

crossfire/colour_count/crossfire $for i in NDI_BLACK NDI_WHITE NDI_NAVY 
NDI_RED NDI_ORANGE NDI_BLUE NDI_DK_ORANGE NDI_GREEN NDI_LT_GREEN NDI_GREY 
NDI_BROWN NDI_GOLD NDI_TAN NDI_UNIQUE NDI_ALL; do echo NDI_UNIQUE $i $(grep 
-R $i * | grep NDI_UNIQUE | wc -l); done
NDI_UNIQUE NDI_BLACK 2
NDI_UNIQUE NDI_WHITE 4
NDI_UNIQUE NDI_NAVY 28
NDI_UNIQUE NDI_RED 13
NDI_UNIQUE NDI_ORANGE 7
NDI_UNIQUE NDI_BLUE 13
NDI_UNIQUE NDI_DK_ORANGE 8
NDI_UNIQUE NDI_GREEN 1
NDI_UNIQUE NDI_LT_GREEN 4
NDI_UNIQUE NDI_GREY 0
NDI_UNIQUE NDI_BROWN 2
NDI_UNIQUE NDI_GOLD 0
NDI_UNIQUE NDI_TAN 0
NDI_UNIQUE NDI_UNIQUE 1376
NDI_UNIQUE NDI_ALL 20

from this I conclude that the vast majority of messages are  unique black text 
(that is default)

TAN and GOLD are unused (only defined)
GREY is used uniquely once. in polymorph melt (so it never appears anymore). 
(spell_effect.c 224)

NDI_BROWN is used twice, in relation to keyrings (one of these is an odd call, 
it sets the listen level not the colour - probably a bug). (player.c 1842 and 
1876) - possibly one channel.

NDI_GREEN is used only for the MOTD which Tchize is in the process of 
replacing anyway. (player.c 94)

NDI_LT_GREEN is used soley for dm leave/quit messages. (I used COMM_JOINQUIT 
on these, which turns the DK_ORANGE, but you could have another channel here 
too I guess) (scattered through c_wiz.c) - possibly another channel

NDI_DK_ORANGE is used soley for joining and quitting messages (all NDI_UNIQUE 
|

      NDI_ALL) - already a channel

NDI_ORANGE is used for tell, by unmuzzling messages (but curiously not for 
muzzling ones) and by the python code, it is also abused to provide a listen 
level. (I use it in COMM_TELL). - possibly another channel, COMM_PLUGIN I 
guess you could have COMM_UNMUZZLE too if you really wanted.....

that leaves 5 colours, of which two, NDI_BLACK and NDI_WHITE, are the same 
anyway (they just appear in different places). 

the calls to coloured messages that aren't unique are effectively so anyway, 
since they occur so rarely. 

oh, one more thing, global messages.

for i in NDI_BLACK NDI_WHITE NDI_NAVY NDI_RED NDI_ORANGE NDI_BLUE 
NDI_DK_ORANGE NDI_GREEN NDI_LT_GREEN NDI_GREY NDI_BROWN NDI_GOLD NDI_TAN 
NDI_UNIQUE NDI_ALL; do echo NDI_ALL $i $(grep -R $i * | grep NDI_ALL | wc 
-l); done
NDI_ALL NDI_BLACK 0
NDI_ALL NDI_WHITE 0
NDI_ALL NDI_NAVY 0
NDI_ALL NDI_RED 2
NDI_ALL NDI_ORANGE 0
NDI_ALL NDI_BLUE 0
NDI_ALL NDI_DK_ORANGE 8
NDI_ALL NDI_GREEN 0
NDI_ALL NDI_LT_GREEN 4
NDI_ALL NDI_GREY 0
NDI_ALL NDI_BROWN 0
NDI_ALL NDI_GOLD 0
NDI_ALL NDI_TAN 0
NDI_ALL NDI_UNIQUE 20
NDI_ALL NDI_ALL 25

DK_ORANGE and LT_GREEN messages here are currently COMM_JOINQUIT, the red 
messages are dm banishment and kick messages, I guess they could have their 
own channels too.... - (possibly 1 more channel?)

so 5 colours, NDI_BLACK is already covered by several channels, 
that leaves 4.

so 4 more channels. that is a total of
15 already + 4 (main colours) +5 (corner cases.). = 24

>

        I was thinking about this some more, and we may be addressing it from the

     >

      wrong side of things - the server side.  What really counts is the

     >

      interface to the player - if the interface isn't good, all of this is

     >

      basically meaningless because no one will ever use it.

agreed

>

        My personal thought is that I probably want a max of 5 different message

     >

      tabs in my client - anything more than that seems excessive for the number

     >

      of messages I typically see while playing on metalforge.

     >

>

        I certainly _don't_ want 1 tab per channel - I don't want to have 30 tabs

     >

      in my client.  I also don't want something like 'if you don't have that

     >

      specific tab, everything gets dumped into a default tab'.

AFAICT that is something that tchize will address with his draw_info_ext() 
function.

>

        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?

>

        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.

>

        What is also the expected plan for people actually chatting on these

     >

      channels? I'm presuming there will need to be some command to do so, but I

     >

      don't see that in your patch right now, so not sure how that will be

     >

      handled.  Keep in mind you need to provide some way for players with older

     >

      clients to both see and chat on these new channels.

That's the point, I've dealt with that already. It works now, it maybe isn't 
where you might think though.

I modified execute_new_server command. in c_new.c when a command is run, if 
(and only if) it can't find it in the command arrays, instead of getting 'no 
such command' it checks the channels that exists, and if channel->canpost is 
at a value that the player can post to the channel, then they send the 
message. if they have a channel called that, and they can't post there, they 
get an explanation as to why.

this means each channel is posted to by using its name as the send command. so 
certainly Redbot (which has been on #crossfire-bs and now works) would 
probably find itself modified to 
login
channel create irc
then send 'irc (whatever is said on #crossfire-bs)'
which the command parser will convert to a message on the IRC channel, so 
anyone who has done
listen irc
will hear it.

the thing I have to do still is put a check in channel creation to stop 
someone creating a channel called 'quit' :)
That isn't overly complex to do however.