[crossfire] channels

[Brendan Lally]

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?