nicolas.weeger at laposte.net wrote: > 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' > 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). > Maybe player will remember what channels they are in between sessions, > as to not have to rejoin all the time when connecting. Sure, but only persistant channels > > 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? I don't think that is bad - The server should be the dispatcher and currently I would just use something like: "... NDI_UNIQUE | <channelcolour>, 3, <channel members>, ... " to actually send the messages. Future changes to NDI to offload more message formatting to the client would automatically apply to the channel stuff then. - as an aside, anyone have real objection if I change the priority of tell and reply to 1? You should be able to block this with listen and putting it to the same level as shout (lower - maybe a 2?) makes sense, no? _______________________________________________ crossfire-devel mailing list crossfire-devel at lists.real-time.com https://mailman.real-time.com/mailman/listinfo/crossfire-devel