[CF-Devel] attack messages and GTK client

[Mark Wedel]

Tim Rightnour wrote:

>
     
     
     >
     
      The random factor works out alot better than what you suggest IMHO, because
     
     >
     
      then you have to track what message number you are on in each player.
     
     >
     
      Additionaly, I can tune messages with the random factor by messagetype, because
     
     >
     
      some are more frequent than others.  The random values really are predictable..
     
     >
     
      because basically.. we are expecing that if a message is displayed 1/6 times,
     
     >
     
      overall you will get 1/6th the messages.  It's done on a per-message basis.
     
     
 Ok.  Didn't realize that some messages would appear more often than other based
on random type.  Tracking one or two values in the player structure of how many
messages we have not sent out would not be hard, but if there are 20 different
categories, that is more of a pain.

 Vaguely related to this, at some time I do want to redo how messages are sent
to the client.  Instead of the server specifying color, it would instead specify
content (eg, NDI_SPELL_LIST, NDI_PLAYER_KILLED_SOMETHING, NDI_PLAYER_WAS_KILLED,
etc, although maybe not that refined).

 Then the client (player) can decide how to display those messages.  For
example, maybe the player decides he wants the messages that when he killed
something to be in blue, but have level gains be bold black or the like (no
reason the selection for what each message looks like can't include a font -
this is especially useful for things like lists which the server does try to
format, although perhaps those should be redone so that the server just puts a
tab or the like for the seperator in columns,and the client (knowing that
message type) formats appropriately.

 Reason this is vaguely related is that if such tags are done, then perhaps also
a importance tag could be added to the new_draw_info calls, and the player can
set something like 'ignore messages below priority 12' or the like.  Perhaps
under such a scheme, the random factor could be the priority, so some would end
up really high, others really low.

 I'm not planning on doing this immediately (at least a few other things of
higher importance on my list), but it could be reasonable to keep that in mind
so when that is done, it will be easier for whoever is doing that to figure out
the priority (or, right now, you could define a simple function that takes the
priority, but just discards it as it calls new_draw_info without that)