Menu
▾
▴
#34 Improved communication channels
Replace listen levels with communication channels.
This will allow better configurability of what people hear.
for example joins/leaves, quits, say, dm_announce,
trade. GTK2 client can then be made to create/destroy
tabs and add/remove channels to those tabs. GTK1 client
should probably be made to understand them too and dump
everything subscribed to into one of the two boxes.
I know people may say "we don't want to re-implement
IRC", but why not? IRC is for communicating. Being a
multiplayer game CF has the need for players to
communicate, and IMO channels is a very good way of
doing that. With tabs in GTK2 client this seems a
sensible step forward.
Logged In: YES
user_id=1084627
ok, the following patch works, kinda.
It modifies the listen command so that listen n toggles
listening to channel n instead of all channels above and
below it.
It is not completely usable yet. I had to disable channel
saving and loading to make it work.
Still to do:
a) fix saving and loading.
b) have an array linking channel names to numbers.
c) have a 'channels' command to print the channel numbers,
names and statuses.
d) #define the channel names also and use the defines
everywhere new_draw_info or new_draw_info_format is called.
e) let the listen command take channel names too
(c) (e) and (b) won't be too difficult, (a) might be a
little more interesting. (probably either a begin .... end
setup like the messages, or else a comma seperated list -
this might not cope well with changing numbers of channels
though..... (d) will be merely time-consuming.
I'll do this myself in a couple of weeks (deadlines IRL get
in the way until then.....), unless someone gets there first.
Logged In: YES
user_id=1084627
never underestimate the ability of deadlines to get
unrelated stuff done :)
new patch, supercedes the old one.
have implemented (d) and (c) in the list above (used listen,
instead of creating a new command, since listen with no
options is currently not used for much)
(a),(b) and (e) remain to be done.
I have defined the following channels:
#define COMM_ERRORS 0 /* when the player is told 'no you
can't do that'. */
#define COMM_RESPOND 1 /* response from a command sent to
the server... */
#define COMM_EFFECT 2 /* the effects of player actions */
#define COMM_DESCRIBE 3 /* descriptions of items and map
squares, etc */
#define COMM_LITERATURE 4 /* books, signs, scrolls, etc */
#define COMM_ALCHEMY 5 /* alchemy messages */
#define COMM_COMBAT 6 /* you hit the foo/the foo hits you
type messages */
#define COMM_KILLS 7 /* you killed the foo/the foo killed
you. */
#define COMM_DEATHS 8 /* of other players */
#define COMM_EXT 9 /* things which are done outside the
player's control */
#define COMM_JOINQUIT 10 /* foo enters the game, foo leaves.. */
#define COMM_SHOUT 11 /* shout command */
#define COMM_CHAT 12 /* chat command */
#define COMM_TELL 13 /* tell command */
#define COMM_PARTY 14 /* communication with your party -
gsay etc */
#define COMM_LOCAL 15 /* stuff on the current map - say
currently goes here, this should soon change */
#define COMM_OTHERSKILLS 16 /* another player killed the foo */
Expect those to change by the next patch....
Had to gzip patch 'cos it is too big for tracker :)
Logged In: YES
user_id=1084627
ok, patch 3, (b) and (e) are done, only (a) remains
there is a hack in here which should be fixed at some point,
COMM_TOTAL is ugly, and I want to remove it., for now it is
needed though.
Logged In: YES
user_id=1084627
ok then, some major changes here, everything has been
robustified, and there is far more sanity checking. player
loading saving and migration is in, and AFAICT works.
Channels are now sorted by a guesstimate of use, this is to
reduce the amount of iterating through the array.
my list of things to do in my earlier comment is now complete.
This patch is now at the point where it can be considered
for review with a view towards consideration for inclusion
in CVS.
Questions that remain:
should the channel functions be in c_chat.c, if not where?
is 100 channels a high enough maximum?
should COMM_TOTAL be in define.h or config.h?
Are the channels that are defaulted to sane? are there any
omissions?
Are all uses of them sensible? I have had to guess at the
intent of a few of the strings, and some are ambiguous
should the new_draw_info commands use prototypes that must
be matched to the Channels array, or should the channel
names be used?
using the numbers directly would be unclear, calling
get_channel_number("foo") everytime might be slow. Passing
string pointers directly would work, but would change one of
the most widely used functions in the sourcecode.
other things which are possible TODO's. - comments on these
points are welcomed.
change tell_map to take priorities too, make say go on a
different channel to COMM_LOCAL
give channels 'owners'
let the server admin have a 'channels' file to specify some
default channels. - have shout and chat in here by default
let players create new channels, and remove the ones they own.
let created channels have posting rights (none, dm only,
owner only, subscribers only, or all).
let channels be parsed after all commands are. - remove
shout and chat as commands. - channels can deal with them.
save player created channels across reboots (maybe?)
have a timeout for their destruction. (no posts after n days).
record traffic levels in all channels (messages per hour),
show it with the listen command.
allow limiting the scope of channels - to world, region or map.
Logged In: YES
user_id=1084627
owing to the extreme size of this patch, I have constructed
a small version, this contains only the files with
modifications to logic, not all the new_draw_info changes.
This should prove easier to read than the single big patch.
(note, there are still new_draw_info lines in there, but
there are sufficiantly fewer that they can be ignored).
Logged In: YES
user_id=1084627
oops, included loader.c in the main diff, since this is an
autogenerated file it shouldn't be patched....
Logged In: YES
user_id=1084627
ok new version,
from the things mentioned in the TODO 3 comments before I
have implemented points 2,5, 6 and half of 4 (channel
addition is in, channel removal isn't, channel number
assignement is rather dumb atm, this also needs fixed).
also not included is checking for channel names matching
commands (the commands will take precedence though, so this
isn't as bad as it sounds), and limits to the amount of
channels a player can create.
also missing is mandatory channels, and channel description
modification.
Several other major changes to the channel structure to
incorporate all this..
Logged In: YES
user_id=1084627
channels_patch9.diff.gz and channels_patch9s.diff (being a
subset of the main one to more easily see the differences,
and not something that is compilable)
new_draw_info now disregards the flags passed to it, and
gets them from the channel number instead.
all channels are defined with vaguely sane options for the
colour values., mostly to keep the settings close to what
they were previously. (though there may need to be a little
tweaking for the channel of some of the more obscure strings)
new_draw_info(flags, pri, pl, message) could now be changed
to new_draw_info(pri, pl, message) with no loss of function.
no changes have been made to player created channels beyond
those in the last patch.
Logged In: YES
user_id=1084627
ok then, patch 10, channel removal is in, mandatory channels
should be working now (though none are defined yet), and the
save code is more robust (now it will store all channels not
in their default state, then flip the state of the channels
listed on login)
more sanity checking in various places, and other minor
tweakage.
Logged In: YES
user_id=1144360
This seems to be getting along very nicely.
This is slightly off topic, and should probably go into a
different patch instead of clobering this one up, but this
is sort of rellevant. You could also add a server-wide
ignore command:
ignore <player_name>
Toggle the displaying of messages from this player.
Channel owner should also have the authority to kick a
player from the channel, and a DM should have the authority
to kick and ban a player from any arbritrary channel. This
will replace the muzzle command.
channels kick <channel> <player>
Unsubscribes player from the channel and prevents them from
posting to it.
channels ban [<channel> ...] <player>
Unsubscribes player from channel, prevents them form posting
to it, and prevents them from subscribing to it. A DM can
then make an alias for a standard muzzle (when alias support
is implemented in the client?) and still use the muzzle
command as before, but which would be translated by the
client into a ban command.
Also, I suggest a change of the (default) output format of
'channels list to:
<num> <name>
Then 'channels describe (<num>|<name>) can output
<num> <name>
<description>
Owner: <owner>
Finally, 'channels who <name> should list channel subscribers
Logged In: YES
user_id=1084627
hmm, banning and kicking can be implemented quite easily
with an extra number in the current state.
what you describe as a kick command would simply set the
state to kicked. (that would be 3 IIRC) you would then have
a banned state, which would be 4. how permenent should the
ban be? if you want it to survive login/logout, then it will
be a little more difficult to implement. (need to store the
channels that a player is banned from too....)
also, who should be able to do this? my vote is channel
owner only for the player channels (kicking as well as
banning), after all, it is their channel. dms for the system
channels I agree with..
the point about changing channel list and having a channel
describe is an interesting one, I would think that maybe
owner/category should appear rather than description, this
will still fit on one line (/me realises there is currently
no length limitation on channel names)....
in terms of consistant syntax though, it would want to be
'channel foo describe' not 'channel describe foo.'
wrt channels who... I can do better than that, it can list
the who output for the players quite easily (this would make
'channel who shout' pretty much identical to 'who world')
ignore imho is a different RFE, although related, it doesn't
actually affect this.
hmm, the only thing you don't mention is op, I'm not sure
whether that needs to be allocatable seperatly from channel
owner (I suspect it is overkill though, TBH).
I'm a little busy over the next few days, so some of this
might take a while to get in, but then it seems that I need
to wait to sync with tchize anyway....
8th channels patch, kicking.
Logged In: YES
user_id=1084627
just in case anyone was misled into thinking that I could go
an entire day without posting yet another jumbo patch up
here.....
kicking is included.
TODO
banning
adjusting save code to cope with banning.
changing format of channel list
channel foo describe
channel foo who
limit the length of channel names.
set some channels to be mandatory.
let channels be set to canpost dm only (by dms).
let channel description be changed (by owner)
massively cut back version of channels patch, almost certainly broken.
Logged In: YES
user_id=1084627
ok, I've returned to this patch again.
I've removed entirely the adjustments to NDI_* values that
were meeting some degree of opposition. The result is a much
smaller patch.
I have fixed enough of it so that it compiles again, but it
doesn't actually /work/ and could even leave other stuff
completely broken.
Logged In: YES
user_id=1084627
ok, I've fixed much of the brokenness of the previous patch,
it now works, but still has serious issues that should stop
it being committed yet.
slightly less broken patch.
yet another channel patch.
Logged In: YES
user_id=1084627
most everything functionally neccessary for this patch to
work is now in.
only a few minor tidy-ups remain, and possibly the
introduction of banning.