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

[Mark Wedel]

Kevin Bulgrien wrote:
> The message types in the system are consecutive numbers from 1 to 20.  They are:
<snip>
> 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:

  First question I have would be can a message be of multiple types?  By having 
distinct (non bitmask values), a message can only be of one type.

  There probably isn't a wrong or right answer to that question, but that should 
be answered because it can affect future game decisions, and as you note below, 
by allow customizable routing one needs to now how they will work.  What you 
probably want to avoid is the case of assuming a message will only have a single 
bit set, and writing support for that, and then someone setting multiple bits on 
a message and then filing bugs saying support for that is broken.

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

  I personally don't see any issue with that statement in itself - it's fairly 
clear in what it does and efficiency doesn't really matter.

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

  It would seem to me that the easiest thing to do would be convert the message 
type to a bit value upon receipt.  Eg, something like:

  client_message_mask = 1 >> server_message_type

  That gets you the bitmask for easy compares, but does not break compatibility 
of existing message types, and does still enforce a message can only be a single 
type.

  It also means that if message types do increase beyond a 32 bit value, it is 
just a client change that is needed (to store in a larger size) vs potential 
server and protocol changes.

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

  Long term, I think a table with actions is the most flexible solutions.  To 
me, these are attributes you may want to apply to the message:

mergeable - should we try to merge message

which pane(s) the message is drawn to.  Drawing to multiple panes would need to 
be an option IMO - one of the biggest uses I would see for this is that I might 
have pane where everything goes to, but in course of combat, etc, that could get 
filled up pretty easily, so I would want chat type messages to also go into 
another pane so that I can review that pane after the battle.  But I'd still 
like those to go to the main pane, so if things are quiet, I can still see the 
messages and I don't need to switch among several panes to find all the messages.

color & font information - this is currently done via themes, but those are not 
especially friendly for end user editing - having an in-game way to set these 
values would be nice - it also lets you more easily see why a message may have 
shown up in some way (oh, that message was red because it was an attributed 
related message).

  The bitmask is useful if your just looking at global value (mergable message). 
  But once you start dealing with message panes, it starts looking less good, 
because now you are having something like:

  if (message_bit & pane1) { draw_in_pane(1) }
  if (message_bit & pane2) { draw_in_pane(2) }

  and that still doesn't cover font and/or color information (I'm not really 
sure how you would do those with bitmasks).

  But those are just my thoughts - the gui to deal with all this is some work, 
but I always just thought of displaying it basically as a table, something like:


	pane1		pane2		pane3		style info
book	X				X		drawn in color/font
card	X
paper	X
sign	X		X
....

  Where you just use checkboxes to decide where messages go.  That said, there 
is a huge number of options, but I'm not sure how long it would take to make 
those choices.

  Also, just thinking on that, might even be a column to denote the message is 
mergeable or not - don't know.