[crossfire] channels

[Mark Wedel]

tchize wrote:
>
     
     
     >
     
      Now, in case of speaking channels, i obviously see a main type 
     
     >
     
      MSG_TYPE_CHANNEL
     
     >
     
      with various flavor:
     
     >
     
      SHOUT  the main speaking flavor
     
     >
     
      SAY  the map speaking flavor
     
     >
     
      TELL this one will be able have, as first line, the name of speaking player 
     
     >
     
      then the message, so client can open a new tab for each speaking player
     
     >
     
      PARTY_SAY perhaps for this flavor first line would be party name, second line 
     
     >
     
      speaker name, and the rest the message itself
     
     >
     
      CHANNEL this one will get message directe to any channel. Could have similar 
     
     >
     
      behaviour as PARTY_SAY
     
     >
     
      DM_CHANNEL a flavor dedicated to the dm?
     
     >
     
      ... whatever you speak about. The flavor is coded as a 16bits int, there is 
     
     >
     
      much freedom to define lots of flavors and you can handle the way you want. 
     
     >
     
      The content of the textual message part just has to be somewhat consistent 
     
     >
     
      inside a given main type ;)
     
     >
     
      And because flavor is just an information, server does not do anything based 
     
     >
     
      on the flavor. All it does is check client request to get the main MSG_TYPE 
     
     >
     
      and, if so, send all flavors message when they are generated.
     
     
  This is a little more than I was thinking, but was along the idea I was 
thinking with the NDI_.. redo.  So flavors like spell listing, shop listing, 
level gains, etc could also be added as flavors then?


>
     
     
     >
     
      buf may contains this:
     
     >
     
      "You open the necronomicon and start reading...\nYour soul is mine, player!"
     
     >
     
      while nicebuf may contains this.
     
     >
     
      "necronomicon\nYour soul is mine, player!"
     
     >
     
      the draw_ext_info will check if client requested msgType->message_type to be 
     
     >
     
      send using the new command, and if so issue a draw_info_ext on the wire with 
     
     >
     
      a nicebuf. If this is not the case, it will issue a classical draw_info.
     
     
  I'm a little concerned about this - my fear is that the nicebuf things won't 
get updated in any timely fashion, or people will be updating only one, and the 
two will be completely out of sync (support for this alternate msgbuf obviously 
would need to be put into the editors that people use).

  However, it also seems like you are doing 2 things here:

1) telling client types of messages so it could draw pretty frames, etc
2) extending the text field to include tags for color, bold, etc.

  I hope on #2 you are using the formatting features the GTK already has built 
in.  If so, then it makes life much easier (it'd be really stupid to have to 
write our own parser for that when GTK provides one for us)

  I'd personally like to see full documentation for the 'drawinfo_ext' command - 
the docs that will make it into the protocol file.  Coding practices for 
crossfire are that the protocol changes are to have been properly documented and 
sent to the mailing list for discussion with plenty of advance notice before 
such changes are made to CVS.

  That said, in my ideal scenario, it would look something like:

drawinfo2 <formattype><msgtype><msgsubtype><color><message>

  where formattype descirbes the format of the message (text, binary data, text 
formatted in 3 rows, text formatted for ...)

  msgtype helps identify the type of message for sorting and preference purposes.
msgsubtype is finer control.
color is color of message - probably obsolete because that will be a client 
preference based on previous fields.

  The advantage of having formattype as the key value is that there probably 
isn't a need to have too many different format types.  And regardless of the 
remaining fields, the client could display the data if it understands the format 
type (if it doesn't, it probably shouldn't try).