[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