[crossfire] channels

[tchize]

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.

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)

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.

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>

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, 
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.

So here is my proposition: you finalize your patch to handle filterout of 
channel. But you drop the client identification of channels part. 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?
-- 
--
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/20050426/41f3ddc5/attachment.pgp