[crossfire] channels

[Mark Wedel]

Brendan Lally wrote:
>
     
      I've attached a rather bulky patch to casper's RFE at 
     
     >
     
     
      http://sourceforge.net/tracker/index.php?func=detail&aid=1183961&group_id=13833&atid=363833
      
      
     >
     
     
     >
     
      It is now at a state that it can be considered ready for wider review/testing.
     
     >
     
     
     >
     
      If there is anyone who has time on their hands, there are two versions, one is 
     
     >
     
      the patch itself, one is a diff of only the files that have code changes, and 
     
     >
     
      is therefore sane to attempt to read. (as well as being less likely to break 
     
     >
     
      next server code update :) )
     
     >
     
     
     >
     
      Any comments would be greatly appreciated.
     
     
  Looking at the patch, it in no way extends or lets the client know what is on 
what channel.

  The patch filters the different levels on the server and nothing more.  IMO, 
that is of limited usefulness (I'd argue in many cases, a potentially bad thing 
as a player could inadvertently turn of notification of relatively important 
events).

  The client itself still won't know what channel a message belong to, so 
doesn't help in the case of different tabs for different messages.  So from the 
original RFE, really only implements a portion of it.

  What I'd much rather see is a changing of the NDI values to be descriptive of 
the message (the com levels you describe would make good new NDI values).  If 
we're going to change all the new_draw_info_.. calls, less change them to that.

  This then does give the client the info on what the command is then about 
(reply, literature, kills, etc) and so the client can decide what to do with it. 
  That could include deciding not to display it.

  The client would have to communicate to the server (in form of a setup 
command) that it understands these new NDI values.  For the case that the client 
doesn't, it wouldn't be hard to have a simple mapping table of old to new (eg, 
NDI_TELL should be orange, NDI_CHAT is ...).

  Now there is some wastefullness in the server sending something to the client 
that the client then will not display, but IMO, I don't see that as much an 
issue - I can't see the bandwidth wastage being at all significant.

  what I describe is IMO what the original requestor is really looking for. 
Changing the NDI levels has been on the TODO list for a long time - it also has 
other advantages:

1) Lets user customize which window/tab messages go into (Described above)
2) Lets user customize color and font of messages
2b) Lets us use fixed width fonts for messages that would display better that 
way (shop listings, who, map, other commands that try to put things in tables)
3) Makes it easier for client to grab certain messages if it wants to (I can't 
really see much reason, but perhaps scripts might want to).

  So all that said, while very quickly glancing over your patch, I don't see 
anything particularly wrong with it, overall, it isn't moving things in the 
direction they need to move, so I don't see much point in applying it.  some 
day, NDI levels will get redone, making the change of listen levels pretty much 
moot (as important can be gleaned from the NDI message type).


>
     
     
     >
     
      _______________________________________________
     
     >
     
      crossfire mailing list
     
     >
     
     
      crossfire at metalforge.org
      
      
     >
     
     
      http://mailman.metalforge.org/mailman/listinfo/crossfire