[crossfire] MSG_TYPEs vs in-Client configuration of routing and message folding.

[Kevin Bulgrien]

The message types in the system are consecutive numbers from 1 to 20.  They are:

#define MSG_TYPE_BOOK          1
#define MSG_TYPE_CARD          2
#define MSG_TYPE_PAPER         3
#define MSG_TYPE_SIGN          4
#define MSG_TYPE_MONUMENT      5
#define MSG_TYPE_DIALOG        6   /* NPCs, magic mouths, and altars */
#define MSG_TYPE_MOTD          7
#define MSG_TYPE_ADMIN         8
#define MSG_TYPE_SHOP          9
#define MSG_TYPE_COMMAND       10  /* Responses to commands, eg, who */
#define MSG_TYPE_ATTRIBUTE     11  /* Changes to attributes (stats, */
                                   /* resistances, etc) */
#define MSG_TYPE_SKILL         12  /* Messages related to using skills */
#define MSG_TYPE_APPLY         13  /* Applying objects */
#define MSG_TYPE_ATTACK        14  /* Attack related messages */
#define MSG_TYPE_COMMUNICATION 15  /* Communication between players */
#define MSG_TYPE_SPELL         16  /* Spell related info */
#define MSG_TYPE_ITEM          17  /* Item related information */
#define MSG_TYPE_MISC          18  /* Messages that don't go anyplace else */
#define MSG_TYPE_VICTIM        19  /* Something bad is happening to player */
#define MSG_TYPE_CLIENT        20  /* Messages originated by the client */

I would like to consider changing the message types to bit values so that it
is easier to use masks to detect message types instead of having to do
sequential tests for individual values.  There are two immediate reasons for
this:

1) I want to the gtk-v2 client to easily allow in-client message routing by
   type.  The short-term goal is to allow players to pick which messages go
   to the so-called "critical messages" window.  In the longer term, an idea
   was expressed that it might be nice to allow players to set up their own
   number of text windows and route messages as they pleased.  In any case,
   with the current message type numbering, one has to have statements like:

     if (type == MSG_TYPE_ATTRIBUTE
     ||  type == MSG_TYPE_COMMUNICATION
     ||  type == MSG_TYPE_DIALOG
     ||  type == MSG_TYPE_VICTIM)

   For in-client configuration, this type of thing might be done by searching
   a list, which seems silly, or perhaps a table lookup.  The table lookup is
   not really too bad, but it seems like it would be really nice to just use
   a bit mask instead.

2) The client now has an output-count/sync function.  It would be nice to be
   able to select which message types are processed for duplicate suppression
   and which are not.  Again, a bit mask selector for this would be great.

A table lookup scheme isn't that bad, and could be fairly natural to set up
a GUI control for, but the idea of using bit masks is more appealing at the
moment, and with only 20 values in use, it seems quite reasonable to assume
that 32 bits allows for adequate for future expansion.

I see no real reason to modify the subtypes at this time, except perhaps for
consistency.  They also could be converted to bit values quite easily as the
highest number of subtypes in one type is 18.  I suppose the message routing
or buffering could even offer control down to the subtype, but at first blush
that seems a bit of overkill as a GUI control could get quite cluttered with
so many options.

If anyone has any feedback to offer on conversion of the message type values
to powers of two, and/or considerations for message routing and configuration
of output-count and sync, it might be worth airing them for consideration
while I'm interested in doing the work.

Kevin