[CF-Devel] Re: [CF-Devel] New comunication commands. 'me and 'set_reply

[crossfire-devel-admin at archives.real-time.com]

>
     
      Here's what I propose for channels & such, based on what has been said previously. And if everyone agree, i'll implement that :)
     
     >
     
      * ability to create channels, with or without password
     
     >
     
      * persistent ones, at DM's discretion (newbie, admin, ...)
     
     >
     
      * channel list, but without password protected ones
     
     >
     
      * players can join any channel, provided they know the password if there is one
     
     >
     
      * new command like csay (channel say) taking channel name argument
     
     >
     
      * messages are sent to client in the form 'channel:<player> says something'
     
     
  Seems reasonable.  My only concern is players being able to create channels. 
There are two real considerations:
1) If the number of channels is static, all channels could get used up - all it 
takes is one abusive player.
2) if dynamic, you could get a huge list of channels, making it unwieldy.

  Perhaps the solution is to allow one player to only create/have one active 
channel at a time.  If the player wants to create another one, they get a 
message saying they have to close the one they currently have.

  Thus, unlikely to ever get a large number of channels, simply because there is 
a typical limit of number of players that would log in.

  This also presumes that channelsthe player creates go away when they log 
out/connection dies.  That could be annoying if the party is using the channel, 
and the person who created it has their client crash (hence, logout).  One 
thought might be to have some time delay when player connection terminates, and 
the connection actually dies.

  Eg, each channel normally has a expiration time of 0, denoting that it never 
goes away.  When the owner of the channel goes away, the expiration time is now 
set to time() + some number of seconds (300 - 5 minutes perhaps?)  At the same 
time, a message to all players on the channel goes out saying something like 
'owner of channel is gone, type adopt <channelname> to take over this channel'.

  It also means that if the player who created it comes back soon enough, they 
could re-adopt the channel they had previous created.  Players can't adopt a 
channel if they already have one, as once someone adopt is, the expiration time 
goes back to zero.  At some check in check_specials() that checks to see if 
there are any channels that should be terminated because the expiration time has 
been reached.

>
     
     
     >
     
      Maybe player will remember what channels they are in between sessions, as to not have to rejoin all the time when connecting.
     
     >
     
     
     >
     
      This way, current clients can use the new features right away, and read messages plainly.
     
     >
     
      And future versions will parse the text to know which channel is concerned.
     
     >
     
      As right know you could parse the '<name> tells you' message to see who asys what.
     
     >
     
     
     >
     
      Of course, that means the server manages channels... Maybe not that great an option?
     
     
  If done in a simple enough fashion, perhaps not terrible.  I'd just really 
don't want to see it become a huge mess of code to implement communication in 
crossfire.  Of course, one could argue from a realism standpoint (the R word 
again) that this isn't especially realistic, eg, how can someone on a map far 
away tell the player next to you something and you not be able to hear it.  But 
we'll ignore that point.

  Perhaps combine/clean up the current gsay type commands, and just implement 
them as a channel also?  Eg, you create a party, and it creates a channel for 
that party where people likewise use the same commands to communicate.

  The biggest issue on this is how to deal with it on the client.  at some 
level, typing 'cshout channelname blah blah blah' would get tiring, but at the 
same time, using bindings for 'cshout channelname' seem non ideal, simply on the 
basis of how do you know the channelname will always be that?

  Also, storing channels in the saved player file, while doable, has to be 
considered.  Should you share private channels that are password protected (if 
so, how do we know the player has the correct password next time they join? 
Perhaps someone else is using the same channel name with different passwrod).

  I'd personally expect most channel names to be relative short (just to reduce 
typing), so chance of collision/reuse would probably be fairly high.  You could 
certainly save all the permanent channels.

Todd Mitchell wrote:

>>
     
     
     >
     
      I would prefer it be cshout since it is not local like say or personal 
     
     >
     
      like tell/reply.
     
     >
     
      I would like it also if the channels had a consistent format (currently 
     
     >
     
      a just a colour but in the future a style for the client to render) and 
     
     >
     
      used a message priority of say 3 (so you can use listen to block these 
     
     >
     
      messages but still recieve shouts).
     
     
  It seems odd to set a listen level for these.  You've subscibed to the channel 
- that suggests you want to hear them.  If you don't want to hear them, 
unsubscribe from the channel.


_______________________________________________
crossfire-devel mailing list
     
     crossfire-devel at lists.real-time.com
     
     
     https://mailman.real-time.com/mailman/listinfo/crossfire-devel