[crossfire] channels
tchize
tchize at myrealbox.com
Wed Apr 27 15:08:30 CDT 2005
First 'out of bound' is a bad word, sorry, i suppose it shouldn't write mail
when my eyes want to close.
I just mean data are send with another server->client command than draw_info.
Just a matter of slight protocol improvement. This is working great here with
all combinaison of old/new client/server, finalizing code for commit today or
tomorrow. Backward compatible.
Now to explain the 'flavor'. Client request a to get a 'type of data' send
using the new command instead of the old draw_info one.
a 'type of data' is, for example, books.
a 'type of data' in its conception regroups all textual datas which can be
graphically presented using a common scheme client side. Books could be
written inside a picture showing a book.
Letters& scrolls is another type of data, written on top of a flat piece of
paper.
signs is a thrid type, with left, right, square signs.
messages of the day in another one. And so on.
and channel, obviously, is another 'type of data' too :)
Now, to give more flexibility for client, each type can be separated in
'flavors' (or subtype if you prefer the coder way to speak).
Books, for example, have a flavor for nice red book, a flavor for claps, a
flavor blue magical books ,and so on.
There is enough space to add new book style easily. If client don't understand
the flavor, it just has to fall back to a default. As i am bad at coding gtk,
currently all books falls back to default which is a tab in a books windows,
without graphicals improvements, but this way, the path is open in the
protocol.
MOTD have only one flavor yet coded because, well, i see no use of flavor
there, anyway, let's use the common scheme. Here, the motd is shown inside
the 'type username' dialog window as suggested on irc as it will force
players to read the motd a bit.
Other main type values have been reserved but are not yet coded (scrolls,
monuments, signs).
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.
Hope i was clear. Anyway, when code gets in, it will be much more clear ;)
To give an idea of easyness this give to client implementation, here is a part
of code from MOTD handling in gtk on my desk:
at application startup, gx11 does this call:
setTextManager(MSG_TYPE_MOTD,motd_callback);
not at all difficult :)
and to manage this MOTD, here is the content of motd_callback:
char* last_motd=NULL;
void motd_callback(int color, int type, int subtype, char* message){
if(last_motd)
free(last_motd);
last_motd = malloc(strlen(message)+1);
if (last_motd==NULL)
LOG(LOG_ERROR,"gtk::motd_callback","Outa memory, no save of motd");
else
strcpy(last_motd,message);
}
the book version is a bit more lenghty because it manipualtes gtk windows and
extract the first line of 'message' to consider it as a title.
>
ok then, excellent, I can stop trying to abuse hexadecimal arithmatic
>
then....
Poor abused hexadecimal child!
>
Also should I still ignore the colour information in each call and fetch from
>
channel, or should I revert that and leave in the hardcoded channel info?
The new command get a message, a message type, a message flavor and a color,
though in case of book and motd this is ignored by the message handler. I
kept colors as it only take up a very small additional bandwidth compared to
the text following most of the time.
>
one check though, If I understand you correctly there is a function
>
draw_info_ext() in addition to new_draw_info?
yep, in case of books, this is how it is used for now, msgtype is a common
structure i use to split various readables like scrolls, books, aso in a
typ,flavor pair. It is of no use for channels so don't care about:)
draw_ext_info(NDI_UNIQUE | NDI_NAVY, 0, op, msgType->message_type,
msgType->message_subtype, buf, nicebuf);
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 did not put the logic inside draw_info because, as you see, there are cases
were messages to send are to be different in the two protocols.
Not to mention there are places in code were a single operation (like reading
a book) ends in a series of draw_info, so there has to be some work to be
done function caller side anyway.
Now i wrote this long email and have no more time to code today. cleanup will
be for tomorrow ;)
>
shouldn't this be folded into the same function, with the check for which to
>
use done there?
Le Mercredi 27 Avril 2005 03:22, Brendan Lally a écrit :
On Tuesday 26 Apr 2005 18:58, tchize wrote:
>
Ok, to resume the analysis, your patch makes the server able to split
>
message in 'channels' and client to choose 'ok send me this channel, but i
>
don't need this channel , this one and this one'. It also allow users to
>
create their own chat room.
>
However your patch is limited in the realm of client identification of
>
channels. It is based on slight modification of the old draw_info command,
>
embedding informations inside the color parameter.
Yes.
>
Now i have on my computer a draft patch which allow client to request
>
certain datas to be identifiable.
>
If server doesn't support identification, all goes in main channel.
>
If client doesn't request a special treatment for a specific information
>
category, it goes to the main channel.
>
If client connect to an old server, which doesn't support the separation of
>
data, it receive information thru main channel.
>
What i name the 'main channel' is simply draw_info
>
>
Seems i do the part you patch behave poorly on (according to various post
>
on this thread i did not test it, neither go in details) and you do the
>
part my patch never thought about (my purpose was not to filter out
>
informations but to clearly identify it's type)
But if it can be used for both purposes, then that would seem like the way to
go....
>
for now, server on my side behave like this, in pseudo code:
>
>
--
>
if (client requested out of bound data for information type MSG_TYPE_BOOK)
>
send out of bound data (player, MSG_TYPE_BOOK, message flavor(book),
>
book title + book content)
>
else
>
draw_info (player, color, "you open the book and start reading..."+book
>
content)
>
--
>
>
This could be easy to add a new type MSG_TYPE_CHANNEL as this is made to be
>
extensible.
ah, so to apply that to what I have done, the call would be
send_out_of_bound_data (pl, CHAN_FOO, messageflavour "channel", playername,
message).
am I understanding you corrrectly here? (I'm not sure what you mean by 'out
of bound' data, it isn't forbidden in some way is it?)
>
on the wire, the following command is send:
>
draw_info_ext <int type> <int flavor> <int color> <char[] message>
>
>
so for channel, i could easily add
>
draw_info_ext <MSG_TYPE_CHANNEL> <MSG_TYPE_CHANNEL_SHOUT> <red> <shouting
>
player>:<shout message>
>
draw_info_ext <MSG_TYPE_CHANNEL> <MSG_TYPE_CHANNEL_SAY> <black> <saying
>
player>:<say message>
>
draw_info_ext <MSG_TYPE_CHANNEL> <MSG_TYPE_CHANNEL_CHAT> <channel
>
color?black?> <chatroom>:<chatting player>:<chat message>
>
draw_info_ext <MSG_TYPE_CHANNEL> <MSG_TYPE_COMM_SPELL_EFFECT> <red>
>
<chatroom>:<chatting player>:<chat message>
ok, that looks more complicated, I think I'll just trust that you have the
networking bit sorted :)
>
Really, the message part is mainly dependent on the msg_type, but not on
>
the flavor, because client request a msg_type, but not a specific flavor.
>
Client is supposed, for each message type requested, to implement a
>
default flavor. This is quite easily done as , client side, main work is
>
already done in common. All the ui has to do is register to the common part
>
a textmanager for type MSG_TYPE_CHANNEL
>
>
Ha yes, a last argument for using draw_info_ext instead of the old
>
draw_info,
well I thought you were doing reasonably well with the whole 'me not needing
to change the client bit' tbh....
>
this command is supposed to handle media tags, inside []s.
>
>
This way a book can contain [i]italic[i] and [b]bold[/b] character,
>
[u]underlined[/u] ones are supported too.
>
[color=green]colored text[color=black],
>
[fixed] fixed fonts
>
[arcane] magical fonts
>
[strange]undecipherable fonts
>
[normal] and the normal fonts :)
>
of course, [hand] hand written letter are also available
>
[normal] impressive?
>
Perhaps i'll had also support for ingame images like below
>
[image=beholder.111] which was suggested as useful on monster description
>
books.
>
Perhaps in future, motd could also contain
>
[url=
http://crossfire.metalforge.net/rules.html:Marvelous
rules links]!
>
>
Media tags are just an hint to the ui, it is allowed to drop them or only
>
understand a part of them, but this allows for richer content. For old
>
client, server would use the classical draw_info and drop the [] parts of
>
text.
and having some of these in normal chat would be [i]nice[/i]... (probably not
the pictures though, that would seem rather abusable....)
>
So here is my proposition: you finalize your patch to handle filterout of
>
channel. But you drop the client identification of channels part.
ok then, excellent, I can stop trying to abuse hexadecimal arithmatic
then....
>
You just
>
keep sending information the classical way with draw_info, so special play
>
with colors. When my change is ready (a matter of days) you integrate an
>
new MSG_TYPE_CHANNEL and put channels using them.
>
>
What do you think about it?
This idea I like.
one check though, If I understand you correctly there is a function
draw_info_ext() in addition to new_draw_info?
shouldn't this be folded into the same function, with the check for which to
use done there?
Also should I still ignore the colour information in each call and fetch from
channel, or should I revert that and leave in the hardcoded channel info?
_______________________________________________
crossfire mailing list
crossfire at metalforge.org
http://mailman.metalforge.org/mailman/listinfo/crossfire
--
--
Tchize (David Delbecq)
tchize at myrealbox.com
Public PGP KEY FINGERPRINT:
F4BC EF69 54CC F2B5 4621 8DAF 1C71 8E6B 5436 C17C
Public PGP KEY location:
http://wwwkeys.pgp.net/pgpnet/wwwkeys.html
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url :
http://shadowknight.real-time.com/pipermail/crossfire/attachments/20050427/618be1f7/attachment-0001.pgp
More information about the crossfire
mailing list