[crossfire] channels

[Brendan Lally]

On Wednesday 27 Apr 2005 21:08, tchize wrote:
>
     
      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 :)
     
     
ah, I like this idea....

>
     
      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 ;)
     
     
the only thing with this is that it might be a bit of a bandwidth leech, since 
some messages can be sent quite frequently. (still shouldn't be too much if 
buffering is kept though...)

>
     
      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);
     
     >
     
      }
     
     
ok then, great, the server can set the tabs as it wants, and can even use 
regexps to assign to tabs if needed (don't think it is).

the client will know exactly what channel has been sent, so knows just what to 
do.

type of channel can even be encoded there, so whilst a number (base 36 char?) 
would be best for the system channels (bandwidth concerns) the full title can 
be used for other channels, and tabs can be assigned as needed.

>
     
      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.
     
     
/me wonders about tabs which have a pane with the people on the channel in....

>
     
      >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.
     
     
well then, the channel can send it and the client can ignore or not as needed.

so everything should be fine :)