[crossfire] channels

tchize at myrealbox.com tchize at myrealbox.com
Thu Apr 28 09:32:46 CDT 2005


Le Jeudi 28 Avril 2005 09:10, Mark Wedel a écrit :
<snip>
>
     
        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?
     
     >
     
     
     
Any flavor you like :)

<snip>
>
     
        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).
     
     >
     
     
     nope, peoples only have one field to update it's the book->msg field.
The server just present data differently depending on the command used to send 
data (draw_info or draw_info_ext)
in fact server does this:
strncpy(buf,sizeof(buf),"You open the %s and star reading...
\n%s",ob->name,ob->msg);

Something similar is done for nicebuf. The server will also have to strip out 
media tags before sending using the draw_info command (for old clients)

>
     
        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)
     
     
working with gtk1, all i saw was samething called gtk-html, which is an 
extension not include with the main gtk code, and i doubt it will work for 
windows version :/

i choos to use something easy to handle (no closing tag, a tag just set a 
value, there is no such thing as [normal]blabla[hand]foo-bar[/hand]other 
blabla[/normal]

Parsing is quite straight forward anddoesn't involve complicated things.

>
     
     
     >
     
        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.
     
     >
     
     
     
sure, there are descriptions in protocol file


>
     
        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).
     
     >
     
     
     
msgtype, because it regroups things presenting the same way, does inherently 
have a format.
Client must request deliberatly a setup for each msgtype it support  to be 
send by server, so no suprises in format.

>
     
     
     >
     
      _______________________________________________
     
     >
     
      crossfire mailing list
     
     >
     
     
      crossfire at metalforge.org
      
      
     >
     
     
      http://mailman.metalforge.org/mailman/listinfo/crossfire
      
      
     
-- 
David Delbecq
Royal Meteorological Institute of Belgium

    
    


More information about the crossfire mailing list