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

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

<snipped some parts away>

>
     
      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.
     
     
Hum, so one player creates only one channel, but can be on multiple 
ones... sounds fair to me.

>
     
       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. 
     
     
Sounds fair to me, again. But I'd add an option for DMs to make channels 
permanent. Like 'newbie' channel, that could exist even without an owner...
Also possibility to transfer ownership to another player, provided s/he 
didn't create a channel either. And of course channel disband :)

>
     
      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. 
     
     
In this case, maybe we could reimplement the 'shout' like a general 
channel everyone is subscribed to?
This way, even if shout still exists, it's still managed the same way as 
other channels.

>
     
       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? 
     
     
For current clients, indeed, it'll soon become a real pain. But if 
channels names are short, as you mention, it's faster.
Also the client can be improved for channel handling. Shouldn't be hard 
to parse message string, recognize 'channel: player says bla bla' and 
put it in a separate floating window for instance (one window per 
channel -> no need to use 'csay' or 'cshout' when typing in this window).
The aim would be to provide compatibility with current clients and 
letting the chat interface be improved in the future.

>
     
       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. 
     
     
Storing channels on server exit (btw, how do you close the server 
properly? Only way i know, under Windows, is good old ctrl+c) could be 
done. Though closing server isn't something that happens often, so 
savings channels is maybe _not_ that big a priority.

Joining channels a player was in, maybe that could also be delayed. What 
I see coming (is someone working on that? Or should i tackle that 
myself?) is client-side improvements like macros or plugins.
So we could imagine when the player logs out client stores chanels s/he 
is in, and auto-join on reconnect (like IRC clients do sometimes). Or 
possibility for players to add commands to execute at game entry, so 
obviously channel join.

I think the first step is implementing, server-side, the basic channel 
logic. Then improve with permanent / saved channels, auto-rejoin, and such.

>
     
       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. 
     
     
Agreed here.

I think it's been mentioned too, but we could do message types (like: 
player joins/leaves game, player death, monster kill, ...). So listen 
could be changed to something ressembling new pickup, ie listen 
join/leave + death but not monster kill.

Nicolas 'Ryo'


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