[crossfire] draw_ext_info/message update/redo

[Mark Wedel]

  I'm going through the server and updating the new_draw_info calls with the 
draw_ext_info calls.  I had done a few files several weeks back, but decided I 
should just go through and do them all so that it is consistent and we can then 
get rid of the old new_draw_info function (at the protocol level, the old 
drawinfo will continue to stick around for some time).

The main advantages I see of the drawextinfo is this:
- Support for the media tags (bold text, different fonts, etc).  I'd expect 
these to be infrequently used, as in general the global tag/attribute should be 
used.  But I think use in NPC messages giving clues what can be discussed with 
them by doing bold or underline would be very good (we should probalby decide 
what the form for that syntax highlighting it is, so that it is consistent 
accross all the maps/NPCs)

- Instead of the server telling the client the color to use and the client 
blindly following it, the client now knows the type of messages.  So with some 
extra logic, I could decide that I want the level gain message to be in a 
specific font in bright green, even though the server says those should be in 
red.  It would also allow for easier filtering (if chat/say/shout have their own 
types, easier to have a conversation pane, etc).

  The gtk1 client was modified to support the extended types with popup windows 
with graphics of signs and other things.  From what I've generally heard, this 
generally didn't seem very popular (you end up having a bunch of popups, and if 
you want to keep the info around, you need to keep the popup around, etc). 
OTOH, it seems the general idea of pop up windows in the gtk1 client itself was 
never very popular, so the dislike may not be directly related to the content 
(otoh, you do get a lot more with the readable code)

  I modified the gtk2 client not to do that - instead, it just takes the text 
message, applies the tags, and puts it into the normal text windows.  This lets 
things like who, maps, etc, actually look nice, since it uses a fixed width font.

  A hybrid approach could be done - the GtkTextBuffer of the gtk2 client does 
support child widgets, so the graphic with text could be rendered in the text 
buffer.  This fixes the problem of having popup windows, but would mean such 
messages use up a lot more space in the text buffer than just the text (this 
could be controlled by a config option, but to keep adding config options gets a 
little excessive at some point).  The other problem is that the graphic 
themselves have a certain size, which may/probably do not match the width of the 
text window (given that players can resize it, there is of course no 'correct' 
size for this).  The images could be resized, but we'll probably run into 
problems at some point, like the text not fitting in the image, etc.

  I think we need to sort out what exactly how we want to handle this.  As of 
now, with the changes I've made so far, there are probably 150+ different 
message subtypes.  This is obvious way too many to have a user ever be able to 
configure them.  But it also leads to some points:

If we don't plan/want to render graphics, we can reduce the number of subtypes 
by a fair number - for the readable objects, there is basically 1 message 
subtype/object - if we don't want to do graphics, those can be made more general 
(book, scroll, letter, etc).

  One current problem here is that text is different - For a book, it would 
normally say something like 'the book says ...'.  However, in the gtk1 client, 
since the text is put in a book image, the server doesn't send the 'the book 
says ...' part, it just sends the message.  This means that for the gtk2 client 
(and maybe even the gtk1 client in non popup mode), you just get the message of 
the book, with no preface where that message came from.  I suppose the client 
could re-inject the 'the books says' line for the appropriate messages, but 
depending on how the messages are done/rendered, maybe the answer is that the 
server shouldn't be stripping/modifying the output text)

  In any case, a large number of message types will never have any graphics 
displayed with them.  Chat messages, level gain/loss will always just be plainly 
  printed.

  By the same token, how to exactly qualify the overall type gets tricky - I'm 
generally putting them in broad categories (attack, skill, apply, commands). 
But there is even trouble here - for buildable map code, do I put those under 
apply type, buildable subtype?  Do I make a new buildable type, etc.  Probably 
no good answer, but if anyone has thoughts, I'd be interested in hearing them 
(there are some which would seem to go in multiple categories also)

  One thing I see in a fair amount of places while doing this is some idea of 
common subtypes/states (error messages) - it gets odd in those cases - do you 
have an error subtype, or you return the subtype related to the action being 
tried, etc).  I suppose on the plus side, fixing any msg types/subtypes will be 
easier once the calls are converted over, as a sed command could perhaps be used 
- given that draw_ext_info has more parameters, one sort of has to do through 
the programs by hand to have meaningful results.  IMO, having the number of 
type/subtypes be as small as possible yet still distinctive is a nice goal - in 
that way, it is a manageable number for the player to actual choose selections 
on, yet meaningful in that the selections mean something.

  We may also want to revisit what messages are printed world wide.  For 
example, in attack.c, if you are casting a spell, are hit, and lose the spell, 
it would be printed to everyone in the game.  That seems a bit odd to me - I'd 
be more inclined that it be limited to the map or maybe party members (that 
message would only be generated if casting time config option is set, which is 
probably why you don't see it very often, but just struck me as odd).

On a broader scale, there is a problem with most of the msg/endmsg in 
maps/objects.  They are pre-formatted for a certain width.  If your text window 
is wider, it isn't terrible - it just doesn't use the full width.  If your 
window is a bit smaller, it gets really ugly, as it will display a full line, 
then perhaps 1 word, then another full line, etc.

  Ideally, I think most of the newlines from the msg/endmsg structures should be 
removed - the client is plenty smart enough to do proper wrapping.  There are 
also a few messages which should have the '[fixed]' tag added, since they are 
maps or diagrams, and just don't look right when printed with the proportional font.

  But of a long rambling message, but just various thoughts.