ackfuss-4.3.2/area/boards/
ackfuss-4.3.2/npcs/a/
ackfuss-4.3.2/npcs/b/
ackfuss-4.3.2/npcs/c/
ackfuss-4.3.2/npcs/d/
ackfuss-4.3.2/npcs/e/
ackfuss-4.3.2/npcs/f/
ackfuss-4.3.2/npcs/h/
ackfuss-4.3.2/npcs/i/
ackfuss-4.3.2/npcs/k/
ackfuss-4.3.2/npcs/l/
ackfuss-4.3.2/npcs/n/
ackfuss-4.3.2/npcs/o/
ackfuss-4.3.2/npcs/p/
ackfuss-4.3.2/npcs/r/
ackfuss-4.3.2/npcs/s/
ackfuss-4.3.2/npcs/w/
ackfuss-4.3.2/player/c/
ackfuss-4.3.2/reports/
#AREA
The Topmost Area~
Q 16
K helps~
L @@W{@@G SYS @@W}@@N~
N 0
I 1 1
V 32700 32766
X 0
F 15
U You here the screams of the Dead within your head.~
O Zenithar~
R Zenithar~
W Zenithar~
S Title not shown on area list.
#HELPS
-1 ICE~
ICE - the IMC Channel Extensions protocol


ICE is a response to the cesspool-like attributes that rchat, rimm, and

even rcode have acquired over the last few months. It is IRC-ish in some

ways, but hopefully it will be used more constructively than IRC.


For a quick introduction and setup guide for ICE, see ICE-INTRO


The basic ICE structure is (greatly simplified):


. Some nodes on IMC - normally hubs - run channel daemon code that

  manages channels

. Each of these nodes maintains a list of the channels they manage, and

  the various attributes of them - who owns them, and so on

. The daemons regularly tell all muds on IMC what channels they have, and

  what their attributes are

. Based on this information, the muds on IMC decide which of their local

  users can use which ICE channels. If one mud is modified to ignore these

  restrictions, then the other muds will recognize this (since they, too,

  know the restrictions) and ignore messages from that mud.


Every channel on ICE is of the form nodename:channelname, for example a

channel called hub2:IAdmin is the channel IAdmin maintained by the node hub2.

Each mud picks which channels it is interested in (see ILIST and

ISETUP) and creates a local channel name which can be used to talk on

that channel.


Generally, any admin on a mud can create a channel on any node - although

nodes can be configured to restrict who can create channels. Whoever

creates a channel owns it, and can control who can use that channel (in

whatever way they wish). The trick, of course, is to persuade the admins

of other muds that your channel has value. Creating and modifying a

channel is done via the ICOMMAND command.


Channels can be tuned into and out of on a player-by-player basis by

using the ICHAN command.


There are a variety of ways of controlling who can hear and use a channel

- see ICE-POLICY for more information.


See also: IMC ILIST ISETUP ICOMMAND ICHAN ICE-POLICY ICE-INTRO

~
-1 ICE-INTRO~
A Quick Introduction to ICE


This assumes that the code for IMC and ICE is installed and running, and

that you have an active connection to an IMC network.


1. ILIST. This will give you a list of possible channels to choose from.

   Pick one that you want to add, that has a policy of 'open'. Note its

   name (of the form node:channel).


2. Decide what command you want to use to speak on this channel on your

   mud. This is the channel's localname.


3. Type: ISETUP ADD <node:channel> <localname>


4. You should now be able to use the channel. Others can listen to and

   speak on the channel by using ICHAN <localname>.


5. You may wish to reconfigure the default local channel settings.

   ILIST <localname> will display them; ISETUP will change them.


6. Repeat for whatever other channels you wish to have.


See also: IMC ICE ISETUP ICOMMAND ICHAN ILIST

~
0 ICHAN~
Syntax:  ichan               - display current ICE channel status

         ichan <localname>   - toggle an ICE channel


IChan lets you show and toggle which ICE channels you are listening

to. Without arguments, it will show you the channels you belog to; with

an argument, it will turn on or off that channel.


Any channels you listen to must be locally configured first - see

ISETUP. ILIST can be used to see available channels.


See also: IMC ICE ILIST ISETUP

~
0 ICOMMAND~
Syntax:          icommand <command> <channel> [<data..>]

Common commands:  create <channel>           - create a channel

                  refresh <channel>          - refresh channel data

                  list [<channel>]           - list available commands

                  destroy <channel>          - destroy a channel

                  policy <channel> <policy>  - change channel policy

                  addop <channel> <name>     - add a channel operator

                  removeop <channel> <name>  - remove an operator

                  invite <channel> <name>    - add an invited name

                  uninvite <channel> <name>  - remove an invited name

                  exclude <channel> <name>   - exclude a name

                  unexclude <channel> <name> - remove an exclusion


ICommand is used to send commands to a channel daemon elsewhere on IMC.

It directly affects the channel itself - any changes made here will

affect all muds using the channel.


Since the actual commands are interpreted by the channel daemon, not your

mud, what is available may vary. To get a list of available commands, use

icommand list <nodename> for public commands, or icommand list

<node:channel> to see what commands you have for that channel.


icommand refresh asks the daemon to refresh your mud's information for a

channel, if it ever gets out of synx. Asking for a refresh of nodename:*

will refresh all channels on that daemon.


icommand create creates a new channel, with you as the owner

icommand destroy destroys a channel. You must own the channel.


icommand policy changes the basic policy of the channel (see ICE-POLICY).

You must be the owner.


icommand addop/removeop add and remove operators from a channel. You must

be the owner, and specify the operator's full user@mud name.


icommand invite/uninvite/exclude/unexcluded modify the invite and exclude

lists for a channel. You must be the owner or an operator on the channel.

Either a full user@mud or a simple 'mud' name (no @) can be specified.

See ICE-POLICY for more details.


See also: IMC ICE ICE-POLICY

~
0 ISETUP~
Syntax: isetup add <ice-channel> <localname>   - add a channel

        isetup delete <localname>              - delete a channel

        isetup rename <oldname> <newname>      - rename a channel

        isetup format1 <localname> <format>    - change format1 on a channel

        isetup format2 <localname> <format>    - change format2 on a channel

        isetup level <localname> <level>       - set channel level


ISetup allows you to change the local configuration of an ICE

channel. None of these commands have a lasting effect on the channel's

configuration on other muds.


ISetup add begins the configuration of a channel. It connects the

specified ice-channel (of the form nodename:channelname) to a local name.

For example: isetup add hub2:IAdmin IAdmin. The local name is also the

command used to speak on the channel.


When the channel is added, various default values are filled in for

format1, format2, and level.


ISetup delete removes this link. It does not affect the channel itself;

it just deletes the local configuration link for the channel.


ISetup rename changes the local name of a channel. It does not affect the

channel name itself for other muds - just the command used locally to

access it.


ISetup format1 and format2 change how a channel is displayed locally.

Each format string must have exactly two %s's within it (this is checked

for) - the first will be replaced by the speaker's name, the second by

whatever they say. Format1 is used for normal speech, format2 for emotes.

See ILIST for more information.


ISetup level sets the minimum level necessary on your mud to hear or use

the channel.


See also: IMC ICE ILIST

~
0 ILIST~
Syntax:  ilist               - list all known ICE channels

         ilist <channel>     - list details on one ICE channel


IList displays information on channels active on ICE.

Without arguments, it will produce a display similar to:


Name            Local name      Owner           Policy

hub2:IAdmin     IAdmin          Nemon@AR        open

hub2:ICode      ICode                                    (inactive)

hub2:test       (not local)     Nemon@ARtest    private


This shows the canonical name (eg. hub2:IAdmin), the local name (eg IAdmin

- which can be used as an abbreviation in ISETUP, and which is also

the command to speak on that channel), the owner of the channel (eg.

Nemon@AR), and the channel's policy (see ICE-POLICY).


If a channel is not configured locally, it will have (not local) for its

local name.


If a channel is configured locally, but is not actually active on IMC, it

will have an (inactive) flag on it.


IList with a channel name will provide detailed information on that

channel. For example:


Channel hub2:IAdmin:

  Local name: IAdmin

  Format 1:   (IAdmin) %s: %s

  Format 2:   (IAdmin) %s %s

  Level:      102


  Policy:     open

  Owner:      Nemon@AR

  Operators:  Drylock@AR

  Invited:    NiceGuy@SomeMud

  Excluded:   SomeMud


This displays the channel name, local name, policy, and owner, as above. It

also displays:


- the minimum level needed on your mud to see the channel


- the format for displaying messages from the channel. These can contain

  any color codes etc. that your mud uses.


  Format1 is the string displayed when someone speaks normally on the

  channel - the first %s is replaced by their name, the second %s by what

  they say.


  Format2 is a similar string for emotes. Again the first %s is their name,

  the second %s the text of their emote.


- any operators for the channel. This can only be changed by the owner of

  the channel. Operators can modify the 'invited' and 'excluded' fields

  via the ISETUP command.


- the invited and excluded people on the channel. See ICE-POLICY for

  more details.


See also: IMC ICE ISETUP ICOMMAND ICE-POLICY

~
-1 ICE-POLICY~
ICE Channel Policies


Channels can have one of three policies - open, closed, and private. They

also have one owner, and zero or more operators (assigned by the owner).

They also have an include and exclude list (which can specify both

individual players ['user@mud'] and entire muds ['mud']), which can be

modified by the owner and the operators.


- Open. The channel can be accessed by all muds on the network (it is a

  broadcast channel). People on the exclude list cannot use the channel,

  with the exception of people also on the invite list. This means, for

  example, if an entire mud is excluded and one player is invited, that

  player can use the channel, but the rest of the mud can't.


- Closed. The channel can be accessed by all muds on the network (it is a

  broadcast channel), but by default they will not hear or be able to use

  it. People on the invite list can use the channel, with the exception of

  people also on the exclude list.


- Private. Identical to closed, except that the channel is actually only

  physically sent to those muds that are on the invite list. This is good

  for channels specific to a small group of muds, and not of interest to

  the majority of the network.


See also: IMC ICE ICOMMAND

~
-1 IMC~
IMC (Inter-Mud Communication) provides a way for muds to connect together and

share various services: chat channels, tells, notes, who listings, and so on.


The available mortal-level IMC commands are as follows. See the help topics

for each of these for more information.


- IMCLIST : get a list of active muds that are connected to IMC.

- RCHAT   : send a message on the common chat channel.

- RWHO    : send a who request to a mud.

- RTELL   : send a tell to someone on another mud.

- RREPLY  : reply to a rtell from someone on another mud.

- RQUERY  : ask for information of some type from another mud.

- RBEEP   : "beep" another player. Use sparingly.

- RWHOIS  : find someone on IMC

- RFINGER : get information about a player on another mud

- ISTATS  : get some (interesting?) stats about IMC.

- RCHAN   : show which channels you are listening to, and modify that state.


There is also provision for inter-mud notes/mail; see 'IMC NOTES'.


IMC2 was written by Oliver Jowett <oliver@sa-search.massey.ac.nz>, aka

Spectrum. Mail me if you're interested in connecting to the IMC network.

The source code is available at ftp://sa-search.massey.ac.nz/pub/mud/imc2/

The IMC2 home page is at http://sa-search.massey.ac.nz/-oliver/imc2/

(- = tilde)

~
0 IMCLIST~
Syntax:  imclist                  - get a list of active muds on IMC

         imclist direct           - get a list of directly connected muds

         imclist config           - see the local IMC config


'imclist' lists active muds on IMC. It lists all the muds which this mud knows

about on the IMC network, and when they were last heard from. The 'route'

section is mainly for diagnostics, and indicates the route that your mud will

send packets via to get to another mud.


'imclist direct' shows direct connections from your mud to other muds.


'imclist config' shows the local IMC configuration and state.


See also: IMC RQUERY

~
0 RCHAT RIMM RCODE~
These channels are obselete, use ICE instead.

~
0 RWHO~
Syntax:  rwho <mudname>               - ask for a who listing from another mud


'rwho' asks the given mud for a 'who' listing of its current players. Depending

on the network, it may take several seconds to get a response. You should use

the mud abbreviation listed in 'imclist' when issuing a rwho.


See also: IMC IMCLIST RQUERY RWHOIS

~
0 RWHOIS~
Syntax:  rwhois <playername>          - find a player on IMC


'rwhois' asks all muds on IMC for a player with the given name. You should not

include a @mudname section - just the playername. Replies will be returned

from those muds who have a player by that name connected.


See also: IMC RWHO RFINGER

~
0 RFINGER~
Syntax:  rfinger <player@mudname>     - get information about a player


'rfinger' asks the specified mud for information about the specified player.

The information you will get back (and even its existance) depends on the

remote mud, but will typically give at least their last login time.


See also: IMC RWHO RWHOIS

~
0 RTELL RREPLY~
Syntax:  rtell <player@mudname> <message>    - send a 'tell' to another player

         rreply <message>                    - send a 'tell' to the last player

                                               to send you a rtell


rtell and rreply are the IMC equivalents of tell and reply, and work nearly

identically. To rtell, however, you need to supply both a playername and a

mudname (as shown in 'imclist'). rreply will reply to the last rtell you

received from a player - even if that player was invisible to you.


See also: IMC IMCLIST

~
0 RQUERY~
Syntax:  rquery <mudname> help         - ask for available rquery options

         rquery <mudname> <option>     - ask for information from a mud


RQuery is similar to rwho, except it requests different information from a

mud. Each mud differs in what information it supplies, but 'rquery <mudname>

help' will give you a list of options that you can ask for.


Typically at least the following are supported:


rquery <mud> who        - ask for a who listing, identical to 'rwho'

rquery <mud> info       - get general information on the mud, usually including

                          its address. This is the preferred way of finding

                          out the address of a mud on IMC - don't ask on rchat!

rquery <mud> list       - ask for a list of IMC connections, from that mud's

                          point of view. Identical to 'imclist' on the remote

                          mud.

rquery <mud> istats     - ask for some IMC statistics, identical to 'istats' on

                          the remote mud.


See also: IMC IMCLIST RWHO

~
0 RBEEP~
Syntax:  rbeep <player@mudname>     - "beep" a player over IMC


rbeep sends an audible beep to another player on another mud (the @mudname

part indicates which mud; see 'imclist'). Note that this should only be done

when you _really_ need to get their attention; abusing rbeep will usually

lead to your IMC priviliges being revoked.


See also: IMC IMCLIST

~
0 ISTATS~
Syntax:  istats                     - display use(less?) statistics


istats shows some (maybe :) interesting statistics about how much traffic your

mud is generating due to IMC.


See also: IMC IMCLIST RQUERY

~
0 RCHANNELS RCHAN RINVIS~
Syntax:  rchannels                  - display your current IMC channel state

         rchannels +<channel>       - turn on an IMC channel

         rchannels -<channel>       - turn off an IMC channel


rchannels on its own will show you which IMC channels you have access to, and

whether they are currently on or off.


rchannels with an argument will turn on or off a given IMC channel that you

have access to.


rchannels can also be used to block rtells and rbeeps if necessary.


One additional option is rinvis. rchannels +rinvis will make you totally

invisible to IMC: you cannot be contacted by rtell, rreply, or rbeep, and

you do not appear on rwho. However, you cannot use any IMC channels while

rinvis is active (you can still hear them, though). rchannels -rinvis will

reverse this state.


Immortals may allow you access to IMC channels, or revoke your access to 

them, as necessary.


See also: IMC RCHAT RBEEP RTELL

~
-1 'IMC NOTES'~
Notes (boards, mail, etc) are very mud-dependent, but in general, if they

have been connected to IMC, then you can simply write notes to player@mudname

in addition to normal 'player'.


For example, you may be able to do:


note to abcde@somemud anotherplayer immortal@someothermud


and the note would go to:

  abcde on the mud called 'somemud'

  anotherplayer on your mud

  all immortals on the mud called 'someothermud'


The 'playernames' used are interpreted by the mud that receives them, not

your mud, so be careful when writing notes to group names such as 'immortal'.


If your note cannot be delivered within 12 hours for some reason (if the

mud is down, does not exist, or refused your mail) then you will get a note

from the system telling you so.


See also: IMC

~
-1 'IMC IMMORTAL COMMANDS' RINFO~
IMC Immortal commands:


- RINFO       : A channel which the various hubs put status reports onto. Can

                be spammy at times; you may want to turn off rinfo for this

                reason.

- RSOCKETS    : displays debugging info on the current IMC connection state.

- RCONNECT    : force a connection to a directly connected mud.

- RDISCONNECT : forcibly disconnect a directly connected mud.

- RIGNORE     : ignore a player or an entire mud on IMC.

- MAILQUEUE   : show the current queue of pending inter-mud notes.

- IMC         : edit the IMC configuration for your mud (see 'IMC CONFIG')

- RCHANSET    : manage access to IMC channels/rtell/rbeep for players.

- RPING       : trace IMC connectivity


See also: IMC

~
0 RSOCKETS~
Syntax:  rsockets                   - display IMC socket usage


rsockets displays the current connection state for the direct IMC connections

that your mud has. The various fields are:


Desc  : the system-level descriptor used for this connection


Mud   : which mud this connection is for


State : how far through the connection process this connection is:

        - connecting: waiting for the other end to accept our TCP connection

        - wait1:      waiting for the password from an incoming client

        - wait2:      waiting for the server to respond to our password

        - connected:  the connection is completely 'up'


Inbuf : the size of data waiting in the input and output queues for this

Outbuf: connection.


Spam1 : spam-protection counters

Spam2 :


See also: IMC 'IMC IMMORTAL COMMANDS'

~
0 RCONNECT~
Syntax:  rconnect <mudname>                - start an IMC connection


rconnect will initiate a connection to the given mud. Note that this has to

be a _directly_ connected mud (ie. a mud in the first section of imclist).

Feedback on the state of the connection will be logged to 'wiznet imc', and 

you may want to check imclist to see if it was successful.


See also: IMC 'IMC IMMORTAL' RDISCONNECT

~
0 RDISCONNECT~
Syntax:  rdisconnect <mudname>             - terminate an IMC connection


rdisconnect reverses rconnect, severing all connections to the named mud.


See also: IMC 'IMC IMMORTAL COMMANDS' RCONNECT

~
0 RIGNORE~
Syntax:  rignore                           - list current rignores

         rignore ignore  <pattern>         - ignore player(s) or mud(s)

         rignore notrust <pattern>         - don't trust player(s) or mud(s)

	 rignore delete  <pattern>         - remove a rignore


rignore ignores or restricts the access, at a mud-wide level, everything

coming in over IMC for a specified player or group of players. Currently

two possible actions are possible: ignore and notrust.


Ignore means:


- rtells/rbeeps/rwhos will be ignored, and a rtell sent back to say that the

  mud is ignoring them.

- no messages from them on rchat, rcode, etc will appear on your mud.


Notrust means:


- any rwho/rfinger/etc requests from a mud/player matching the pattern will

  be treated as if they were from a level 1 mortal - ie. wizi imms will never

  be revealed on rwho, and rtells won't see them, etc.

- any incoming channel messages from something matching the pattern are

  stripped of wizi status - they will be visible to everyone in general.


Patterns can be one of:


  player@mud              - matches a specific player at a specific mud

  *suffix                 - matches anything ending with that suffix

                            (commonly used as *@mud)

  prefix*                 - matches anything beginning with that prefix

                            (for example, player@*)

  *substring*             - matches anything containing that substring


Use with care.


See also: IMC 'IMC IMMORTAL COMMANDS'

~
0 MAILQUEUE~
Syntax:  mailqueue                         - show current IMC mailqueue


This command simply shows the current contents of the outgoing IMC mailqueue

for inter-mud notes. Due to the internal implementation of this (static

buffers - ick), only the first 8-9 entries will be shown.


See also: IMC 'IMC IMMORTAL COMMANDS' 'IMC NOTES'

~
0 RCHANSET~
Syntax:  chanset <player>             - see a players current IMC flags

         chanset <player> +<channel>  - set 'allow' flag on a player

         chanset <player> -<channel>  - set 'deny' flag on a player

         chanset <player> =<channel>  - reset allow/deny flags on a player


This command allows you to view or change a players IMC channel priviliges.

In all cases <channel> can be the name of an IMC channel (rchat, rcode, etc)

or 'rtell' or 'rbeep'.


Setting the allow flag for a channel allows that player to see and use that

channel, regardless of their level. This can be used, for example, to give

mortals with coding experience access to rcode.


Setting the deny flag for a channel prevents that player from using or

seeing that channel, even if their level normally allows them to. This can be

used as a penalty for players who abuse the IMC channels or rtell/rbeep.


Resetting the allow/deny flags simply clears them, using only the player's

level to determing whether they can use the channel.


See also: IMC 'IMC IMMORTAL COMMANDS' RCHAT RCODE RIMM RINFO

~
0 'IMC CONFIG'~
The 'imc' command is used to configure your IMC setup:


Syntax:  imc add <mudname>            - add a new IMC connection entry

         imc set <...>                - set the details of an IMC connection

         imc delete <mudname>         - remove an IMC connection

         imc rename <old> <new>       - rename an IMC connection

         imc reload                   - load a new IMC config file from disk

         imc localname <name>         - set the local IMC name

         imc localport <port>         - set the local IMC port


Add, delete, and rename should be self-explanatory. The name of an IMC

connection MUST match the name which the other end is using.


Reload destroys the version of the configuration in memory, and reloads it

from disk. This is useful if you have hand-edited the config file and want

to load your changes without rebooting. 'imc reload' also reloads the

rignores file.


The set command has several forms:


imc set <mudname> all <data...>     - set all values for a mud

                  host <hostname>   - set the hostname to connect to

                  port <portnum>    - set the remote IMC port to connect to

                  clientpw <pw>     - set the case-sensitive client password

                  serverpw <pw>     - set the case-sensitive server password

                  rcvstamp <value>  - set the receivestamp

                  noforward <value> - set the noforward bitmask

                  flags <value>     - set the connection flags


The 'all' form takes a series of values:


imc set <mudname> all <host> <port> <clientpw> <serverpw> <rcvstamp>

                      <noforward> <flags>


For information on the exact details of each field, see the IMC documentation.


The localname and localport commands set the IMC name and port of -your- mud.

Use with care.


See also: IMC 'IMC IMMORTAL COMMANDS'

~
-1 ICE~
ICE - the IMC Channel Extensions protocol


ICE is a response to the cesspool-like attributes that rchat, rimm, and

even rcode have acquired over the last few months. It is IRC-ish in some

ways, but hopefully it will be used more constructively than IRC.


For a quick introduction and setup guide for ICE, see ICE-INTRO


The basic ICE structure is (greatly simplified):


. Some nodes on IMC - normally hubs - run channel daemon code that

  manages channels

. Each of these nodes maintains a list of the channels they manage, and

  the various attributes of them - who owns them, and so on

. The daemons regularly tell all muds on IMC what channels they have, and

  what their attributes are

. Based on this information, the muds on IMC decide which of their local

  users can use which ICE channels. If one mud is modified to ignore these

  restrictions, then the other muds will recognize this (since they, too,

  know the restrictions) and ignore messages from that mud.


Every channel on ICE is of the form nodename:channelname, for example a

channel called hub2:IAdmin is the channel IAdmin maintained by the node hub2.

Each mud picks which channels it is interested in (see ILIST and

ISETUP) and creates a local channel name which can be used to talk on

that channel.


Generally, any admin on a mud can create a channel on any node - although

nodes can be configured to restrict who can create channels. Whoever

creates a channel owns it, and can control who can use that channel (in

whatever way they wish). The trick, of course, is to persuade the admins

of other muds that your channel has value. Creating and modifying a

channel is done via the ICOMMAND command.


Channels can be tuned into and out of on a player-by-player basis by

using the ICHAN command.


There are a variety of ways of controlling who can hear and use a channel

- see ICE-POLICY for more information.


See also: IMC ILIST ISETUP ICOMMAND ICHAN ICE-POLICY ICE-INTRO

~
-1 ICE-INTRO~
A Quick Introduction to ICE


This assumes that the code for IMC and ICE is installed and running, and

that you have an active connection to an IMC network.


1. ILIST. This will give you a list of possible channels to choose from.

   Pick one that you want to add, that has a policy of 'open'. Note its

   name (of the form node:channel).


2. Decide what command you want to use to speak on this channel on your

   mud. This is the channel's localname.


3. Type: ISETUP ADD <node:channel> <localname>


4. You should now be able to use the channel. Others can listen to and

   speak on the channel by using ICHAN <localname>.


5. You may wish to reconfigure the default local channel settings.

   ILIST <localname> will display them; ISETUP will change them.


6. Repeat for whatever other channels you wish to have.


See also: IMC ICE ISETUP ICOMMAND ICHAN ILIST

~
0 ICHAN~
Syntax:  ichan               - display current ICE channel status

         ichan <localname>   - toggle an ICE channel


IChan lets you show and toggle which ICE channels you are listening

to. Without arguments, it will show you the channels you belog to; with

an argument, it will turn on or off that channel.


Any channels you listen to must be locally configured first - see

ISETUP. ILIST can be used to see available channels.


See also: IMC ICE ILIST ISETUP

~
0 ICOMMAND~
Syntax:          icommand <command> <channel> [<data..>]

Common commands:  create <channel>           - create a channel

                  refresh <channel>          - refresh channel data

                  list [<channel>]           - list available commands

                  destroy <channel>          - destroy a channel

                  policy <channel> <policy>  - change channel policy

                  addop <channel> <name>     - add a channel operator

                  removeop <channel> <name>  - remove an operator

                  invite <channel> <name>    - add an invited name

                  uninvite <channel> <name>  - remove an invited name

                  exclude <channel> <name>   - exclude a name

                  unexclude <channel> <name> - remove an exclusion


ICommand is used to send commands to a channel daemon elsewhere on IMC.

It directly affects the channel itself - any changes made here will

affect all muds using the channel.


Since the actual commands are interpreted by the channel daemon, not your

mud, what is available may vary. To get a list of available commands, use

icommand list <nodename> for public commands, or icommand list

<node:channel> to see what commands you have for that channel.


icommand refresh asks the daemon to refresh your mud's information for a

channel, if it ever gets out of synx. Asking for a refresh of nodename:*

will refresh all channels on that daemon.


icommand create creates a new channel, with you as the owner

icommand destroy destroys a channel. You must own the channel.


icommand policy changes the basic policy of the channel (see ICE-POLICY).

You must be the owner.


icommand addop/removeop add and remove operators from a channel. You must

be the owner, and specify the operator's full user@mud name.


icommand invite/uninvite/exclude/unexcluded modify the invite and exclude

lists for a channel. You must be the owner or an operator on the channel.

Either a full user@mud or a simple 'mud' name (no @) can be specified.

See ICE-POLICY for more details.


See also: IMC ICE ICE-POLICY

~
0 ISETUP~
Syntax: isetup add <ice-channel> <localname>   - add a channel

        isetup delete <localname>              - delete a channel

        isetup rename <oldname> <newname>      - rename a channel

        isetup format1 <localname> <format>    - change format1 on a channel

        isetup format2 <localname> <format>    - change format2 on a channel

        isetup level <localname> <level>       - set channel level


ISetup allows you to change the local configuration of an ICE

channel. None of these commands have a lasting effect on the channel's

configuration on other muds.


ISetup add begins the configuration of a channel. It connects the

specified ice-channel (of the form nodename:channelname) to a local name.

For example: isetup add hub2:IAdmin IAdmin. The local name is also the

command used to speak on the channel.


When the channel is added, various default values are filled in for

format1, format2, and level.


ISetup delete removes this link. It does not affect the channel itself;

it just deletes the local configuration link for the channel.


ISetup rename changes the local name of a channel. It does not affect the

channel name itself for other muds - just the command used locally to

access it.


ISetup format1 and format2 change how a channel is displayed locally.

Each format string must have exactly two %s's within it (this is checked

for) - the first will be replaced by the speaker's name, the second by

whatever they say. Format1 is used for normal speech, format2 for emotes.

See ILIST for more information.


ISetup level sets the minimum level necessary on your mud to hear or use

the channel.


See also: IMC ICE ILIST

~
0 ILIST~
Syntax:  ilist               - list all known ICE channels

         ilist <channel>     - list details on one ICE channel


IList displays information on channels active on ICE.

Without arguments, it will produce a display similar to:


Name            Local name      Owner           Policy

hub2:IAdmin     IAdmin          Nemon@AR        open

hub2:ICode      ICode                                    (inactive)

hub2:test       (not local)     Nemon@ARtest    private


This shows the canonical name (eg. hub2:IAdmin), the local name (eg IAdmin

- which can be used as an abbreviation in ISETUP, and which is also

the command to speak on that channel), the owner of the channel (eg.

Nemon@AR), and the channel's policy (see ICE-POLICY).


If a channel is not configured locally, it will have (not local) for its

local name.


If a channel is configured locally, but is not actually active on IMC, it

will have an (inactive) flag on it.


IList with a channel name will provide detailed information on that

channel. For example:


Channel hub2:IAdmin:

  Local name: IAdmin

  Format 1:   (IAdmin) %s: %s

  Format 2:   (IAdmin) %s %s

  Level:      102


  Policy:     open

  Owner:      Nemon@AR

  Operators:  Drylock@AR

  Invited:    NiceGuy@SomeMud

  Excluded:   SomeMud


This displays the channel name, local name, policy, and owner, as above. It

also displays:


- the minimum level needed on your mud to see the channel


- the format for displaying messages from the channel. These can contain

  any color codes etc. that your mud uses.


  Format1 is the string displayed when someone speaks normally on the

  channel - the first %s is replaced by their name, the second %s by what

  they say.


  Format2 is a similar string for emotes. Again the first %s is their name,

  the second %s the text of their emote.


- any operators for the channel. This can only be changed by the owner of

  the channel. Operators can modify the 'invited' and 'excluded' fields

  via the ISETUP command.


- the invited and excluded people on the channel. See ICE-POLICY for

  more details.


See also: IMC ICE ISETUP ICOMMAND ICE-POLICY

~
-1 ICE-POLICY~
ICE Channel Policies


Channels can have one of three policies - open, closed, and private. They

also have one owner, and zero or more operators (assigned by the owner).

They also have an include and exclude list (which can specify both

individual players ['user@mud'] and entire muds ['mud']), which can be

modified by the owner and the operators.


- Open. The channel can be accessed by all muds on the network (it is a

  broadcast channel). People on the exclude list cannot use the channel,

  with the exception of people also on the invite list. This means, for

  example, if an entire mud is excluded and one player is invited, that

  player can use the channel, but the rest of the mud can't.


- Closed. The channel can be accessed by all muds on the network (it is a

  broadcast channel), but by default they will not hear or be able to use

  it. People on the invite list can use the channel, with the exception of

  people also on the exclude list.


- Private. Identical to closed, except that the channel is actually only

  physically sent to those muds that are on the invite list. This is good

  for channels specific to a small group of muds, and not of interest to

  the majority of the network.


See also: IMC ICE ICOMMAND

~
-1 IMC~
IMC (Inter-Mud Communication) provides a way for muds to connect together and

share various services: chat channels, tells, notes, who listings, and so on.


The available mortal-level IMC commands are as follows. See the help topics

for each of these for more information.


- IMCLIST : get a list of active muds that are connected to IMC.

- RCHAT   : send a message on the common chat channel.

- RWHO    : send a who request to a mud.

- RTELL   : send a tell to someone on another mud.

- RREPLY  : reply to a rtell from someone on another mud.

- RQUERY  : ask for information of some type from another mud.

- RBEEP   : "beep" another player. Use sparingly.

- RWHOIS  : find someone on IMC

- RFINGER : get information about a player on another mud

- ISTATS  : get some (interesting?) stats about IMC.

- RCHAN   : show which channels you are listening to, and modify that state.


There is also provision for inter-mud notes/mail; see 'IMC NOTES'.


IMC2 was written by Oliver Jowett <oliver@sa-search.massey.ac.nz>, aka

Spectrum. Mail me if you're interested in connecting to the IMC network.

The source code is available at ftp://sa-search.massey.ac.nz/pub/mud/imc2/

The IMC2 home page is at http://sa-search.massey.ac.nz/-oliver/imc2/

(- = tilde)

~
0 IMCLIST~
Syntax:  imclist                  - get a list of active muds on IMC

         imclist direct           - get a list of directly connected muds

         imclist config           - see the local IMC config


'imclist' lists active muds on IMC. It lists all the muds which this mud knows

about on the IMC network, and when they were last heard from. The 'route'

section is mainly for diagnostics, and indicates the route that your mud will

send packets via to get to another mud.


'imclist direct' shows direct connections from your mud to other muds.


'imclist config' shows the local IMC configuration and state.


See also: IMC RQUERY

~
0 RCHAT RIMM RCODE~
These channels are obselete, use ICE instead.

~
0 RWHO~
Syntax:  rwho <mudname>               - ask for a who listing from another mud


'rwho' asks the given mud for a 'who' listing of its current players. Depending

on the network, it may take several seconds to get a response. You should use

the mud abbreviation listed in 'imclist' when issuing a rwho.


See also: IMC IMCLIST RQUERY RWHOIS

~
0 RWHOIS~
Syntax:  rwhois <playername>          - find a player on IMC


'rwhois' asks all muds on IMC for a player with the given name. You should not

include a @mudname section - just the playername. Replies will be returned

from those muds who have a player by that name connected.


See also: IMC RWHO RFINGER

~
0 RFINGER~
Syntax:  rfinger <player@mudname>     - get information about a player


'rfinger' asks the specified mud for information about the specified player.

The information you will get back (and even its existance) depends on the

remote mud, but will typically give at least their last login time.


See also: IMC RWHO RWHOIS

~
0 RTELL RREPLY~
Syntax:  rtell <player@mudname> <message>    - send a 'tell' to another player

         rreply <message>                    - send a 'tell' to the last player

                                               to send you a rtell


rtell and rreply are the IMC equivalents of tell and reply, and work nearly

identically. To rtell, however, you need to supply both a playername and a

mudname (as shown in 'imclist'). rreply will reply to the last rtell you

received from a player - even if that player was invisible to you.


See also: IMC IMCLIST

~
0 RQUERY~
Syntax:  rquery <mudname> help         - ask for available rquery options

         rquery <mudname> <option>     - ask for information from a mud


RQuery is similar to rwho, except it requests different information from a

mud. Each mud differs in what information it supplies, but 'rquery <mudname>

help' will give you a list of options that you can ask for.


Typically at least the following are supported:


rquery <mud> who        - ask for a who listing, identical to 'rwho'

rquery <mud> info       - get general information on the mud, usually including

                          its address. This is the preferred way of finding

                          out the address of a mud on IMC - don't ask on rchat!

rquery <mud> list       - ask for a list of IMC connections, from that mud's

                          point of view. Identical to 'imclist' on the remote

                          mud.

rquery <mud> istats     - ask for some IMC statistics, identical to 'istats' on

                          the remote mud.


See also: IMC IMCLIST RWHO

~
0 RBEEP~
Syntax:  rbeep <player@mudname>     - "beep" a player over IMC


rbeep sends an audible beep to another player on another mud (the @mudname

part indicates which mud; see 'imclist'). Note that this should only be done

when you _really_ need to get their attention; abusing rbeep will usually

lead to your IMC priviliges being revoked.


See also: IMC IMCLIST

~
0 ISTATS~
Syntax:  istats                     - display use(less?) statistics


istats shows some (maybe :) interesting statistics about how much traffic your

mud is generating due to IMC.


See also: IMC IMCLIST RQUERY

~
0 RCHANNELS RCHAN RINVIS~
Syntax:  rchannels                  - display your current IMC channel state

         rchannels +<channel>       - turn on an IMC channel

         rchannels -<channel>       - turn off an IMC channel


rchannels on its own will show you which IMC channels you have access to, and

whether they are currently on or off.


rchannels with an argument will turn on or off a given IMC channel that you

have access to.


rchannels can also be used to block rtells and rbeeps if necessary.


One additional option is rinvis. rchannels +rinvis will make you totally

invisible to IMC: you cannot be contacted by rtell, rreply, or rbeep, and

you do not appear on rwho. However, you cannot use any IMC channels while

rinvis is active (you can still hear them, though). rchannels -rinvis will

reverse this state.


Immortals may allow you access to IMC channels, or revoke your access to 

them, as necessary.


See also: IMC RCHAT RBEEP RTELL

~
-1 'IMC NOTES'~
Notes (boards, mail, etc) are very mud-dependent, but in general, if they

have been connected to IMC, then you can simply write notes to player@mudname

in addition to normal 'player'.


For example, you may be able to do:


note to abcde@somemud anotherplayer immortal@someothermud


and the note would go to:

  abcde on the mud called 'somemud'

  anotherplayer on your mud

  all immortals on the mud called 'someothermud'


The 'playernames' used are interpreted by the mud that receives them, not

your mud, so be careful when writing notes to group names such as 'immortal'.


If your note cannot be delivered within 12 hours for some reason (if the

mud is down, does not exist, or refused your mail) then you will get a note

from the system telling you so.


See also: IMC

~
-1 'IMC IMMORTAL COMMANDS' RINFO~
IMC Immortal commands:


- RINFO       : A channel which the various hubs put status reports onto. Can

                be spammy at times; you may want to turn off rinfo for this

                reason.

- RSOCKETS    : displays debugging info on the current IMC connection state.

- RCONNECT    : force a connection to a directly connected mud.

- RDISCONNECT : forcibly disconnect a directly connected mud.

- RIGNORE     : ignore a player or an entire mud on IMC.

- MAILQUEUE   : show the current queue of pending inter-mud notes.

- IMC         : edit the IMC configuration for your mud (see 'IMC CONFIG')

- RCHANSET    : manage access to IMC channels/rtell/rbeep for players.

- RPING       : trace IMC connectivity


See also: IMC

~
0 RSOCKETS~
Syntax:  rsockets                   - display IMC socket usage


rsockets displays the current connection state for the direct IMC connections

that your mud has. The various fields are:


Desc  : the system-level descriptor used for this connection


Mud   : which mud this connection is for


State : how far through the connection process this connection is:

        - connecting: waiting for the other end to accept our TCP connection

        - wait1:      waiting for the password from an incoming client

        - wait2:      waiting for the server to respond to our password

        - connected:  the connection is completely 'up'


Inbuf : the size of data waiting in the input and output queues for this

Outbuf: connection.


Spam1 : spam-protection counters

Spam2 :


See also: IMC 'IMC IMMORTAL COMMANDS'

~
0 RCONNECT~
Syntax:  rconnect <mudname>                - start an IMC connection


rconnect will initiate a connection to the given mud. Note that this has to

be a _directly_ connected mud (ie. a mud in the first section of imclist).

Feedback on the state of the connection will be logged to 'wiznet imc', and 

you may want to check imclist to see if it was successful.


See also: IMC 'IMC IMMORTAL' RDISCONNECT

~
0 RDISCONNECT~
Syntax:  rdisconnect <mudname>             - terminate an IMC connection


rdisconnect reverses rconnect, severing all connections to the named mud.


See also: IMC 'IMC IMMORTAL COMMANDS' RCONNECT

~
0 RIGNORE~
Syntax:  rignore                           - list current rignores

         rignore ignore  <pattern>         - ignore player(s) or mud(s)

         rignore notrust <pattern>         - don't trust player(s) or mud(s)

	 rignore delete  <pattern>         - remove a rignore


rignore ignores or restricts the access, at a mud-wide level, everything

coming in over IMC for a specified player or group of players. Currently

two possible actions are possible: ignore and notrust.


Ignore means:


- rtells/rbeeps/rwhos will be ignored, and a rtell sent back to say that the

  mud is ignoring them.

- no messages from them on rchat, rcode, etc will appear on your mud.


Notrust means:


- any rwho/rfinger/etc requests from a mud/player matching the pattern will

  be treated as if they were from a level 1 mortal - ie. wizi imms will never

  be revealed on rwho, and rtells won't see them, etc.

- any incoming channel messages from something matching the pattern are

  stripped of wizi status - they will be visible to everyone in general.


Patterns can be one of:


  player@mud              - matches a specific player at a specific mud

  *suffix                 - matches anything ending with that suffix

                            (commonly used as *@mud)

  prefix*                 - matches anything beginning with that prefix

                            (for example, player@*)

  *substring*             - matches anything containing that substring


Use with care.


See also: IMC 'IMC IMMORTAL COMMANDS'

~
0 MAILQUEUE~
Syntax:  mailqueue                         - show current IMC mailqueue


This command simply shows the current contents of the outgoing IMC mailqueue

for inter-mud notes. Due to the internal implementation of this (static

buffers - ick), only the first 8-9 entries will be shown.


See also: IMC 'IMC IMMORTAL COMMANDS' 'IMC NOTES'

~
0 RCHANSET~
Syntax:  chanset <player>             - see a players current IMC flags

         chanset <player> +<channel>  - set 'allow' flag on a player

         chanset <player> -<channel>  - set 'deny' flag on a player

         chanset <player> =<channel>  - reset allow/deny flags on a player


This command allows you to view or change a players IMC channel priviliges.

In all cases <channel> can be the name of an IMC channel (rchat, rcode, etc)

or 'rtell' or 'rbeep'.


Setting the allow flag for a channel allows that player to see and use that

channel, regardless of their level. This can be used, for example, to give

mortals with coding experience access to rcode.


Setting the deny flag for a channel prevents that player from using or

seeing that channel, even if their level normally allows them to. This can be

used as a penalty for players who abuse the IMC channels or rtell/rbeep.


Resetting the allow/deny flags simply clears them, using only the player's

level to determing whether they can use the channel.


See also: IMC 'IMC IMMORTAL COMMANDS' RCHAT RCODE RIMM RINFO

~
0 'IMC CONFIG'~
The 'imc' command is used to configure your IMC setup:


Syntax:  imc add <mudname>            - add a new IMC connection entry

         imc set <...>                - set the details of an IMC connection

         imc delete <mudname>         - remove an IMC connection

         imc rename <old> <new>       - rename an IMC connection

         imc reload                   - load a new IMC config file from disk

         imc localname <name>         - set the local IMC name

         imc localport <port>         - set the local IMC port


Add, delete, and rename should be self-explanatory. The name of an IMC

connection MUST match the name which the other end is using.


Reload destroys the version of the configuration in memory, and reloads it

from disk. This is useful if you have hand-edited the config file and want

to load your changes without rebooting. 'imc reload' also reloads the

rignores file.


The set command has several forms:


imc set <mudname> all <data...>     - set all values for a mud

                  host <hostname>   - set the hostname to connect to

                  port <portnum>    - set the remote IMC port to connect to

                  clientpw <pw>     - set the case-sensitive client password

                  serverpw <pw>     - set the case-sensitive server password

                  rcvstamp <value>  - set the receivestamp

                  noforward <value> - set the noforward bitmask

                  flags <value>     - set the connection flags


The 'all' form takes a series of values:


imc set <mudname> all <host> <port> <clientpw> <serverpw> <rcvstamp>

                      <noforward> <flags>


For information on the exact details of each field, see the IMC documentation.


The localname and localport commands set the IMC name and port of -your- mud.

Use with care.


See also: IMC 'IMC IMMORTAL COMMANDS'

~
1 testhelp~
this help should be in cieling.are

~
-1 ICE~
ICE - the IMC Channel Extensions protocol


ICE is a response to the cesspool-like attributes that rchat, rimm, and

even rcode have acquired over the last few months. It is IRC-ish in some

ways, but hopefully it will be used more constructively than IRC.


For a quick introduction and setup guide for ICE, see ICE-INTRO


The basic ICE structure is (greatly simplified):


. Some nodes on IMC - normally hubs - run channel daemon code that

  manages channels

. Each of these nodes maintains a list of the channels they manage, and

  the various attributes of them - who owns them, and so on

. The daemons regularly tell all muds on IMC what channels they have, and

  what their attributes are

. Based on this information, the muds on IMC decide which of their local

  users can use which ICE channels. If one mud is modified to ignore these

  restrictions, then the other muds will recognize this (since they, too,

  know the restrictions) and ignore messages from that mud.


Every channel on ICE is of the form nodename:channelname, for example a

channel called hub2:IAdmin is the channel IAdmin maintained by the node hub2.

Each mud picks which channels it is interested in (see ILIST and

ISETUP) and creates a local channel name which can be used to talk on

that channel.


Generally, any admin on a mud can create a channel on any node - although

nodes can be configured to restrict who can create channels. Whoever

creates a channel owns it, and can control who can use that channel (in

whatever way they wish). The trick, of course, is to persuade the admins

of other muds that your channel has value. Creating and modifying a

channel is done via the ICOMMAND command.


Channels can be tuned into and out of on a player-by-player basis by

using the ICHAN command.


There are a variety of ways of controlling who can hear and use a channel

- see ICE-POLICY for more information.


See also: IMC ILIST ISETUP ICOMMAND ICHAN ICE-POLICY ICE-INTRO

~
-1 ICE-INTRO~
A Quick Introduction to ICE


This assumes that the code for IMC and ICE is installed and running, and

that you have an active connection to an IMC network.


1. ILIST. This will give you a list of possible channels to choose from.

   Pick one that you want to add, that has a policy of 'open'. Note its

   name (of the form node:channel).


2. Decide what command you want to use to speak on this channel on your

   mud. This is the channel's localname.


3. Type: ISETUP ADD <node:channel> <localname>


4. You should now be able to use the channel. Others can listen to and

   speak on the channel by using ICHAN <localname>.


5. You may wish to reconfigure the default local channel settings.

   ILIST <localname> will display them; ISETUP will change them.


6. Repeat for whatever other channels you wish to have.


See also: IMC ICE ISETUP ICOMMAND ICHAN ILIST

~
0 ICHAN~
Syntax:  ichan               - display current ICE channel status

         ichan <localname>   - toggle an ICE channel


IChan lets you show and toggle which ICE channels you are listening

to. Without arguments, it will show you the channels you belog to; with

an argument, it will turn on or off that channel.


Any channels you listen to must be locally configured first - see

ISETUP. ILIST can be used to see available channels.


See also: IMC ICE ILIST ISETUP

~
0 ICOMMAND~
Syntax:          icommand <command> <channel> [<data..>]

Common commands:  create <channel>           - create a channel

                  refresh <channel>          - refresh channel data

                  list [<channel>]           - list available commands

                  destroy <channel>          - destroy a channel

                  policy <channel> <policy>  - change channel policy

                  addop <channel> <name>     - add a channel operator

                  removeop <channel> <name>  - remove an operator

                  invite <channel> <name>    - add an invited name

                  uninvite <channel> <name>  - remove an invited name

                  exclude <channel> <name>   - exclude a name

                  unexclude <channel> <name> - remove an exclusion


ICommand is used to send commands to a channel daemon elsewhere on IMC.

It directly affects the channel itself - any changes made here will

affect all muds using the channel.


Since the actual commands are interpreted by the channel daemon, not your

mud, what is available may vary. To get a list of available commands, use

icommand list <nodename> for public commands, or icommand list

<node:channel> to see what commands you have for that channel.


icommand refresh asks the daemon to refresh your mud's information for a

channel, if it ever gets out of synx. Asking for a refresh of nodename:*

will refresh all channels on that daemon.


icommand create creates a new channel, with you as the owner

icommand destroy destroys a channel. You must own the channel.


icommand policy changes the basic policy of the channel (see ICE-POLICY).

You must be the owner.


icommand addop/removeop add and remove operators from a channel. You must

be the owner, and specify the operator's full user@mud name.


icommand invite/uninvite/exclude/unexcluded modify the invite and exclude

lists for a channel. You must be the owner or an operator on the channel.

Either a full user@mud or a simple 'mud' name (no @) can be specified.

See ICE-POLICY for more details.


See also: IMC ICE ICE-POLICY

~
0 ISETUP~
Syntax: isetup add <ice-channel> <localname>   - add a channel

        isetup delete <localname>              - delete a channel

        isetup rename <oldname> <newname>      - rename a channel

        isetup format1 <localname> <format>    - change format1 on a channel

        isetup format2 <localname> <format>    - change format2 on a channel

        isetup level <localname> <level>       - set channel level


ISetup allows you to change the local configuration of an ICE

channel. None of these commands have a lasting effect on the channel's

configuration on other muds.


ISetup add begins the configuration of a channel. It connects the

specified ice-channel (of the form nodename:channelname) to a local name.

For example: isetup add hub2:IAdmin IAdmin. The local name is also the

command used to speak on the channel.


When the channel is added, various default values are filled in for

format1, format2, and level.


ISetup delete removes this link. It does not affect the channel itself;

it just deletes the local configuration link for the channel.


ISetup rename changes the local name of a channel. It does not affect the

channel name itself for other muds - just the command used locally to

access it.


ISetup format1 and format2 change how a channel is displayed locally.

Each format string must have exactly two %s's within it (this is checked

for) - the first will be replaced by the speaker's name, the second by

whatever they say. Format1 is used for normal speech, format2 for emotes.

See ILIST for more information.


ISetup level sets the minimum level necessary on your mud to hear or use

the channel.


See also: IMC ICE ILIST

~
0 ILIST~
Syntax:  ilist               - list all known ICE channels

         ilist <channel>     - list details on one ICE channel


IList displays information on channels active on ICE.

Without arguments, it will produce a display similar to:


Name            Local name      Owner           Policy

hub2:IAdmin     IAdmin          Nemon@AR        open

hub2:ICode      ICode                                    (inactive)

hub2:test       (not local)     Nemon@ARtest    private


This shows the canonical name (eg. hub2:IAdmin), the local name (eg IAdmin

- which can be used as an abbreviation in ISETUP, and which is also

the command to speak on that channel), the owner of the channel (eg.

Nemon@AR), and the channel's policy (see ICE-POLICY).


If a channel is not configured locally, it will have (not local) for its

local name.


If a channel is configured locally, but is not actually active on IMC, it

will have an (inactive) flag on it.


IList with a channel name will provide detailed information on that

channel. For example:


Channel hub2:IAdmin:

  Local name: IAdmin

  Format 1:   (IAdmin) %s: %s

  Format 2:   (IAdmin) %s %s

  Level:      102


  Policy:     open

  Owner:      Nemon@AR

  Operators:  Drylock@AR

  Invited:    NiceGuy@SomeMud

  Excluded:   SomeMud


This displays the channel name, local name, policy, and owner, as above. It

also displays:


- the minimum level needed on your mud to see the channel


- the format for displaying messages from the channel. These can contain

  any color codes etc. that your mud uses.


  Format1 is the string displayed when someone speaks normally on the

  channel - the first %s is replaced by their name, the second %s by what

  they say.


  Format2 is a similar string for emotes. Again the first %s is their name,

  the second %s the text of their emote.


- any operators for the channel. This can only be changed by the owner of

  the channel. Operators can modify the 'invited' and 'excluded' fields

  via the ISETUP command.


- the invited and excluded people on the channel. See ICE-POLICY for

  more details.


See also: IMC ICE ISETUP ICOMMAND ICE-POLICY

~
-1 ICE-POLICY~
ICE Channel Policies


Channels can have one of three policies - open, closed, and private. They

also have one owner, and zero or more operators (assigned by the owner).

They also have an include and exclude list (which can specify both

individual players ['user@mud'] and entire muds ['mud']), which can be

modified by the owner and the operators.


- Open. The channel can be accessed by all muds on the network (it is a

  broadcast channel). People on the exclude list cannot use the channel,

  with the exception of people also on the invite list. This means, for

  example, if an entire mud is excluded and one player is invited, that

  player can use the channel, but the rest of the mud can't.


- Closed. The channel can be accessed by all muds on the network (it is a

  broadcast channel), but by default they will not hear or be able to use

  it. People on the invite list can use the channel, with the exception of

  people also on the exclude list.


- Private. Identical to closed, except that the channel is actually only

  physically sent to those muds that are on the invite list. This is good

  for channels specific to a small group of muds, and not of interest to

  the majority of the network.


See also: IMC ICE ICOMMAND

~
-1 IMC~
IMC (Inter-Mud Communication) provides a way for muds to connect together and

share various services: chat channels, tells, notes, who listings, and so on.


The available mortal-level IMC commands are as follows. See the help topics

for each of these for more information.


- IMCLIST : get a list of active muds that are connected to IMC.

- RCHAT   : send a message on the common chat channel.

- RWHO    : send a who request to a mud.

- RTELL   : send a tell to someone on another mud.

- RREPLY  : reply to a rtell from someone on another mud.

- RQUERY  : ask for information of some type from another mud.

- RBEEP   : "beep" another player. Use sparingly.

- RWHOIS  : find someone on IMC

- RFINGER : get information about a player on another mud

- ISTATS  : get some (interesting?) stats about IMC.

- RCHAN   : show which channels you are listening to, and modify that state.


There is also provision for inter-mud notes/mail; see 'IMC NOTES'.


IMC2 was written by Oliver Jowett <oliver@sa-search.massey.ac.nz>, aka

Spectrum. Mail me if you're interested in connecting to the IMC network.

The source code is available at ftp://sa-search.massey.ac.nz/pub/mud/imc2/

The IMC2 home page is at http://sa-search.massey.ac.nz/-oliver/imc2/

(- = tilde)

~
0 IMCLIST~
Syntax:  imclist                  - get a list of active muds on IMC

         imclist direct           - get a list of directly connected muds

         imclist config           - see the local IMC config


'imclist' lists active muds on IMC. It lists all the muds which this mud knows

about on the IMC network, and when they were last heard from. The 'route'

section is mainly for diagnostics, and indicates the route that your mud will

send packets via to get to another mud.


'imclist direct' shows direct connections from your mud to other muds.


'imclist config' shows the local IMC configuration and state.


See also: IMC RQUERY

~
0 RCHAT RIMM RCODE~
These channels are obselete, use ICE instead.

~
0 RWHO~
Syntax:  rwho <mudname>               - ask for a who listing from another mud


'rwho' asks the given mud for a 'who' listing of its current players. Depending

on the network, it may take several seconds to get a response. You should use

the mud abbreviation listed in 'imclist' when issuing a rwho.


See also: IMC IMCLIST RQUERY RWHOIS

~
0 RWHOIS~
Syntax:  rwhois <playername>          - find a player on IMC


'rwhois' asks all muds on IMC for a player with the given name. You should not

include a @mudname section - just the playername. Replies will be returned

from those muds who have a player by that name connected.


See also: IMC RWHO RFINGER

~
0 RFINGER~
Syntax:  rfinger <player@mudname>     - get information about a player


'rfinger' asks the specified mud for information about the specified player.

The information you will get back (and even its existance) depends on the

remote mud, but will typically give at least their last login time.


See also: IMC RWHO RWHOIS

~
0 RTELL RREPLY~
Syntax:  rtell <player@mudname> <message>    - send a 'tell' to another player

         rreply <message>                    - send a 'tell' to the last player

                                               to send you a rtell


rtell and rreply are the IMC equivalents of tell and reply, and work nearly

identically. To rtell, however, you need to supply both a playername and a

mudname (as shown in 'imclist'). rreply will reply to the last rtell you

received from a player - even if that player was invisible to you.


See also: IMC IMCLIST

~
0 RQUERY~
Syntax:  rquery <mudname> help         - ask for available rquery options

         rquery <mudname> <option>     - ask for information from a mud


RQuery is similar to rwho, except it requests different information from a

mud. Each mud differs in what information it supplies, but 'rquery <mudname>

help' will give you a list of options that you can ask for.


Typically at least the following are supported:


rquery <mud> who        - ask for a who listing, identical to 'rwho'

rquery <mud> info       - get general information on the mud, usually including

                          its address. This is the preferred way of finding

                          out the address of a mud on IMC - don't ask on rchat!

rquery <mud> list       - ask for a list of IMC connections, from that mud's

                          point of view. Identical to 'imclist' on the remote

                          mud.

rquery <mud> istats     - ask for some IMC statistics, identical to 'istats' on

                          the remote mud.


See also: IMC IMCLIST RWHO

~
0 RBEEP~
Syntax:  rbeep <player@mudname>     - "beep" a player over IMC


rbeep sends an audible beep to another player on another mud (the @mudname

part indicates which mud; see 'imclist'). Note that this should only be done

when you _really_ need to get their attention; abusing rbeep will usually

lead to your IMC priviliges being revoked.


See also: IMC IMCLIST

~
0 ISTATS~
Syntax:  istats                     - display use(less?) statistics


istats shows some (maybe :) interesting statistics about how much traffic your

mud is generating due to IMC.


See also: IMC IMCLIST RQUERY

~
0 RCHANNELS RCHAN RINVIS~
Syntax:  rchannels                  - display your current IMC channel state

         rchannels +<channel>       - turn on an IMC channel

         rchannels -<channel>       - turn off an IMC channel


rchannels on its own will show you which IMC channels you have access to, and

whether they are currently on or off.


rchannels with an argument will turn on or off a given IMC channel that you

have access to.


rchannels can also be used to block rtells and rbeeps if necessary.


One additional option is rinvis. rchannels +rinvis will make you totally

invisible to IMC: you cannot be contacted by rtell, rreply, or rbeep, and

you do not appear on rwho. However, you cannot use any IMC channels while

rinvis is active (you can still hear them, though). rchannels -rinvis will

reverse this state.


Immortals may allow you access to IMC channels, or revoke your access to 

them, as necessary.


See also: IMC RCHAT RBEEP RTELL

~
-1 'IMC NOTES'~
Notes (boards, mail, etc) are very mud-dependent, but in general, if they

have been connected to IMC, then you can simply write notes to player@mudname

in addition to normal 'player'.


For example, you may be able to do:


note to abcde@somemud anotherplayer immortal@someothermud


and the note would go to:

  abcde on the mud called 'somemud'

  anotherplayer on your mud

  all immortals on the mud called 'someothermud'


The 'playernames' used are interpreted by the mud that receives them, not

your mud, so be careful when writing notes to group names such as 'immortal'.


If your note cannot be delivered within 12 hours for some reason (if the

mud is down, does not exist, or refused your mail) then you will get a note

from the system telling you so.


See also: IMC

~
-1 'IMC IMMORTAL COMMANDS' RINFO~
IMC Immortal commands:


- RINFO       : A channel which the various hubs put status reports onto. Can

                be spammy at times; you may want to turn off rinfo for this

                reason.

- RSOCKETS    : displays debugging info on the current IMC connection state.

- RCONNECT    : force a connection to a directly connected mud.

- RDISCONNECT : forcibly disconnect a directly connected mud.

- RIGNORE     : ignore a player or an entire mud on IMC.

- MAILQUEUE   : show the current queue of pending inter-mud notes.

- IMC         : edit the IMC configuration for your mud (see 'IMC CONFIG')

- RCHANSET    : manage access to IMC channels/rtell/rbeep for players.

- RPING       : trace IMC connectivity


See also: IMC

~
0 RSOCKETS~
Syntax:  rsockets                   - display IMC socket usage


rsockets displays the current connection state for the direct IMC connections

that your mud has. The various fields are:


Desc  : the system-level descriptor used for this connection


Mud   : which mud this connection is for


State : how far through the connection process this connection is:

        - connecting: waiting for the other end to accept our TCP connection

        - wait1:      waiting for the password from an incoming client

        - wait2:      waiting for the server to respond to our password

        - connected:  the connection is completely 'up'


Inbuf : the size of data waiting in the input and output queues for this

Outbuf: connection.


Spam1 : spam-protection counters

Spam2 :


See also: IMC 'IMC IMMORTAL COMMANDS'

~
0 RCONNECT~
Syntax:  rconnect <mudname>                - start an IMC connection


rconnect will initiate a connection to the given mud. Note that this has to

be a _directly_ connected mud (ie. a mud in the first section of imclist).

Feedback on the state of the connection will be logged to 'wiznet imc', and 

you may want to check imclist to see if it was successful.


See also: IMC 'IMC IMMORTAL' RDISCONNECT

~
0 RDISCONNECT~
Syntax:  rdisconnect <mudname>             - terminate an IMC connection


rdisconnect reverses rconnect, severing all connections to the named mud.


See also: IMC 'IMC IMMORTAL COMMANDS' RCONNECT

~
0 RIGNORE~
Syntax:  rignore                           - list current rignores

         rignore ignore  <pattern>         - ignore player(s) or mud(s)

         rignore notrust <pattern>         - don't trust player(s) or mud(s)

	 rignore delete  <pattern>         - remove a rignore


rignore ignores or restricts the access, at a mud-wide level, everything

coming in over IMC for a specified player or group of players. Currently

two possible actions are possible: ignore and notrust.


Ignore means:


- rtells/rbeeps/rwhos will be ignored, and a rtell sent back to say that the

  mud is ignoring them.

- no messages from them on rchat, rcode, etc will appear on your mud.


Notrust means:


- any rwho/rfinger/etc requests from a mud/player matching the pattern will

  be treated as if they were from a level 1 mortal - ie. wizi imms will never

  be revealed on rwho, and rtells won't see them, etc.

- any incoming channel messages from something matching the pattern are

  stripped of wizi status - they will be visible to everyone in general.


Patterns can be one of:


  player@mud              - matches a specific player at a specific mud

  *suffix                 - matches anything ending with that suffix

                            (commonly used as *@mud)

  prefix*                 - matches anything beginning with that prefix

                            (for example, player@*)

  *substring*             - matches anything containing that substring


Use with care.


See also: IMC 'IMC IMMORTAL COMMANDS'

~
0 MAILQUEUE~
Syntax:  mailqueue                         - show current IMC mailqueue


This command simply shows the current contents of the outgoing IMC mailqueue

for inter-mud notes. Due to the internal implementation of this (static

buffers - ick), only the first 8-9 entries will be shown.


See also: IMC 'IMC IMMORTAL COMMANDS' 'IMC NOTES'

~
0 RCHANSET~
Syntax:  chanset <player>             - see a players current IMC flags

         chanset <player> +<channel>  - set 'allow' flag on a player

         chanset <player> -<channel>  - set 'deny' flag on a player

         chanset <player> =<channel>  - reset allow/deny flags on a player


This command allows you to view or change a players IMC channel priviliges.

In all cases <channel> can be the name of an IMC channel (rchat, rcode, etc)

or 'rtell' or 'rbeep'.


Setting the allow flag for a channel allows that player to see and use that

channel, regardless of their level. This can be used, for example, to give

mortals with coding experience access to rcode.


Setting the deny flag for a channel prevents that player from using or

seeing that channel, even if their level normally allows them to. This can be

used as a penalty for players who abuse the IMC channels or rtell/rbeep.


Resetting the allow/deny flags simply clears them, using only the player's

level to determing whether they can use the channel.


See also: IMC 'IMC IMMORTAL COMMANDS' RCHAT RCODE RIMM RINFO

~
0 'IMC CONFIG'~
The 'imc' command is used to configure your IMC setup:


Syntax:  imc add <mudname>            - add a new IMC connection entry

         imc set <...>                - set the details of an IMC connection

         imc delete <mudname>         - remove an IMC connection

         imc rename <old> <new>       - rename an IMC connection

         imc reload                   - load a new IMC config file from disk

         imc localname <name>         - set the local IMC name

         imc localport <port>         - set the local IMC port


Add, delete, and rename should be self-explanatory. The name of an IMC

connection MUST match the name which the other end is using.


Reload destroys the version of the configuration in memory, and reloads it

from disk. This is useful if you have hand-edited the config file and want

to load your changes without rebooting. 'imc reload' also reloads the

rignores file.


The set command has several forms:


imc set <mudname> all <data...>     - set all values for a mud

                  host <hostname>   - set the hostname to connect to

                  port <portnum>    - set the remote IMC port to connect to

                  clientpw <pw>     - set the case-sensitive client password

                  serverpw <pw>     - set the case-sensitive server password

                  rcvstamp <value>  - set the receivestamp

                  noforward <value> - set the noforward bitmask

                  flags <value>     - set the connection flags


The 'all' form takes a series of values:


imc set <mudname> all <host> <port> <clientpw> <serverpw> <rcvstamp>

                      <noforward> <flags>


For information on the exact details of each field, see the IMC documentation.


The localname and localport commands set the IMC name and port of -your- mud.

Use with care.


See also: IMC 'IMC IMMORTAL COMMANDS'

~
0 human~
~
-1 ICE~
ICE - the IMC Channel Extensions protocol


ICE is a response to the cesspool-like attributes that rchat, rimm, and

even rcode have acquired over the last few months. It is IRC-ish in some

ways, but hopefully it will be used more constructively than IRC.


For a quick introduction and setup guide for ICE, see ICE-INTRO


The basic ICE structure is (greatly simplified):


. Some nodes on IMC - normally hubs - run channel daemon code that

  manages channels

. Each of these nodes maintains a list of the channels they manage, and

  the various attributes of them - who owns them, and so on

. The daemons regularly tell all muds on IMC what channels they have, and

  what their attributes are

. Based on this information, the muds on IMC decide which of their local

  users can use which ICE channels. If one mud is modified to ignore these

  restrictions, then the other muds will recognize this (since they, too,

  know the restrictions) and ignore messages from that mud.


Every channel on ICE is of the form nodename:channelname, for example a

channel called hub2:IAdmin is the channel IAdmin maintained by the node hub2.

Each mud picks which channels it is interested in (see ILIST and

ISETUP) and creates a local channel name which can be used to talk on

that channel.


Generally, any admin on a mud can create a channel on any node - although

nodes can be configured to restrict who can create channels. Whoever

creates a channel owns it, and can control who can use that channel (in

whatever way they wish). The trick, of course, is to persuade the admins

of other muds that your channel has value. Creating and modifying a

channel is done via the ICOMMAND command.


Channels can be tuned into and out of on a player-by-player basis by

using the ICHAN command.


There are a variety of ways of controlling who can hear and use a channel

- see ICE-POLICY for more information.


See also: IMC ILIST ISETUP ICOMMAND ICHAN ICE-POLICY ICE-INTRO

~
-1 ICE-INTRO~
A Quick Introduction to ICE


This assumes that the code for IMC and ICE is installed and running, and

that you have an active connection to an IMC network.


1. ILIST. This will give you a list of possible channels to choose from.

   Pick one that you want to add, that has a policy of 'open'. Note its

   name (of the form node:channel).


2. Decide what command you want to use to speak on this channel on your

   mud. This is the channel's localname.


3. Type: ISETUP ADD <node:channel> <localname>


4. You should now be able to use the channel. Others can listen to and

   speak on the channel by using ICHAN <localname>.


5. You may wish to reconfigure the default local channel settings.

   ILIST <localname> will display them; ISETUP will change them.


6. Repeat for whatever other channels you wish to have.


See also: IMC ICE ISETUP ICOMMAND ICHAN ILIST

~
0 ICHAN~
Syntax:  ichan               - display current ICE channel status

         ichan <localname>   - toggle an ICE channel


IChan lets you show and toggle which ICE channels you are listening

to. Without arguments, it will show you the channels you belog to; with

an argument, it will turn on or off that channel.


Any channels you listen to must be locally configured first - see

ISETUP. ILIST can be used to see available channels.


See also: IMC ICE ILIST ISETUP

~
0 ICOMMAND~
Syntax:          icommand <command> <channel> [<data..>]

Common commands:  create <channel>           - create a channel

                  refresh <channel>          - refresh channel data

                  list [<channel>]           - list available commands

                  destroy <channel>          - destroy a channel

                  policy <channel> <policy>  - change channel policy

                  addop <channel> <name>     - add a channel operator

                  removeop <channel> <name>  - remove an operator

                  invite <channel> <name>    - add an invited name

                  uninvite <channel> <name>  - remove an invited name

                  exclude <channel> <name>   - exclude a name

                  unexclude <channel> <name> - remove an exclusion


ICommand is used to send commands to a channel daemon elsewhere on IMC.

It directly affects the channel itself - any changes made here will

affect all muds using the channel.


Since the actual commands are interpreted by the channel daemon, not your

mud, what is available may vary. To get a list of available commands, use

icommand list <nodename> for public commands, or icommand list

<node:channel> to see what commands you have for that channel.


icommand refresh asks the daemon to refresh your mud's information for a

channel, if it ever gets out of synx. Asking for a refresh of nodename:*

will refresh all channels on that daemon.


icommand create creates a new channel, with you as the owner

icommand destroy destroys a channel. You must own the channel.


icommand policy changes the basic policy of the channel (see ICE-POLICY).

You must be the owner.


icommand addop/removeop add and remove operators from a channel. You must

be the owner, and specify the operator's full user@mud name.


icommand invite/uninvite/exclude/unexcluded modify the invite and exclude

lists for a channel. You must be the owner or an operator on the channel.

Either a full user@mud or a simple 'mud' name (no @) can be specified.

See ICE-POLICY for more details.


See also: IMC ICE ICE-POLICY

~
0 ISETUP~
Syntax: isetup add <ice-channel> <localname>   - add a channel

        isetup delete <localname>              - delete a channel

        isetup rename <oldname> <newname>      - rename a channel

        isetup format1 <localname> <format>    - change format1 on a channel

        isetup format2 <localname> <format>    - change format2 on a channel

        isetup level <localname> <level>       - set channel level


ISetup allows you to change the local configuration of an ICE

channel. None of these commands have a lasting effect on the channel's

configuration on other muds.


ISetup add begins the configuration of a channel. It connects the

specified ice-channel (of the form nodename:channelname) to a local name.

For example: isetup add hub2:IAdmin IAdmin. The local name is also the

command used to speak on the channel.


When the channel is added, various default values are filled in for

format1, format2, and level.


ISetup delete removes this link. It does not affect the channel itself;

it just deletes the local configuration link for the channel.


ISetup rename changes the local name of a channel. It does not affect the

channel name itself for other muds - just the command used locally to

access it.


ISetup format1 and format2 change how a channel is displayed locally.

Each format string must have exactly two %s's within it (this is checked

for) - the first will be replaced by the speaker's name, the second by

whatever they say. Format1 is used for normal speech, format2 for emotes.

See ILIST for more information.


ISetup level sets the minimum level necessary on your mud to hear or use

the channel.


See also: IMC ICE ILIST

~
0 ILIST~
Syntax:  ilist               - list all known ICE channels

         ilist <channel>     - list details on one ICE channel


IList displays information on channels active on ICE.

Without arguments, it will produce a display similar to:


Name            Local name      Owner           Policy

hub2:IAdmin     IAdmin          Nemon@AR        open

hub2:ICode      ICode                                    (inactive)

hub2:test       (not local)     Nemon@ARtest    private


This shows the canonical name (eg. hub2:IAdmin), the local name (eg IAdmin

- which can be used as an abbreviation in ISETUP, and which is also

the command to speak on that channel), the owner of the channel (eg.

Nemon@AR), and the channel's policy (see ICE-POLICY).


If a channel is not configured locally, it will have (not local) for its

local name.


If a channel is configured locally, but is not actually active on IMC, it

will have an (inactive) flag on it.


IList with a channel name will provide detailed information on that

channel. For example:


Channel hub2:IAdmin:

  Local name: IAdmin

  Format 1:   (IAdmin) %s: %s

  Format 2:   (IAdmin) %s %s

  Level:      102


  Policy:     open

  Owner:      Nemon@AR

  Operators:  Drylock@AR

  Invited:    NiceGuy@SomeMud

  Excluded:   SomeMud


This displays the channel name, local name, policy, and owner, as above. It

also displays:


- the minimum level needed on your mud to see the channel


- the format for displaying messages from the channel. These can contain

  any color codes etc. that your mud uses.


  Format1 is the string displayed when someone speaks normally on the

  channel - the first %s is replaced by their name, the second %s by what

  they say.


  Format2 is a similar string for emotes. Again the first %s is their name,

  the second %s the text of their emote.


- any operators for the channel. This can only be changed by the owner of

  the channel. Operators can modify the 'invited' and 'excluded' fields

  via the ISETUP command.


- the invited and excluded people on the channel. See ICE-POLICY for

  more details.


See also: IMC ICE ISETUP ICOMMAND ICE-POLICY

~
-1 ICE-POLICY~
ICE Channel Policies


Channels can have one of three policies - open, closed, and private. They

also have one owner, and zero or more operators (assigned by the owner).

They also have an include and exclude list (which can specify both

individual players ['user@mud'] and entire muds ['mud']), which can be

modified by the owner and the operators.


- Open. The channel can be accessed by all muds on the network (it is a

  broadcast channel). People on the exclude list cannot use the channel,

  with the exception of people also on the invite list. This means, for

  example, if an entire mud is excluded and one player is invited, that

  player can use the channel, but the rest of the mud can't.


- Closed. The channel can be accessed by all muds on the network (it is a

  broadcast channel), but by default they will not hear or be able to use

  it. People on the invite list can use the channel, with the exception of

  people also on the exclude list.


- Private. Identical to closed, except that the channel is actually only

  physically sent to those muds that are on the invite list. This is good

  for channels specific to a small group of muds, and not of interest to

  the majority of the network.


See also: IMC ICE ICOMMAND

~
-1 IMC~
IMC (Inter-Mud Communication) provides a way for muds to connect together and

share various services: chat channels, tells, notes, who listings, and so on.


The available mortal-level IMC commands are as follows. See the help topics

for each of these for more information.


- IMCLIST : get a list of active muds that are connected to IMC.

- RCHAT   : send a message on the common chat channel.

- RWHO    : send a who request to a mud.

- RTELL   : send a tell to someone on another mud.

- RREPLY  : reply to a rtell from someone on another mud.

- RQUERY  : ask for information of some type from another mud.

- RBEEP   : "beep" another player. Use sparingly.

- RWHOIS  : find someone on IMC

- RFINGER : get information about a player on another mud

- ISTATS  : get some (interesting?) stats about IMC.

- RCHAN   : show which channels you are listening to, and modify that state.


There is also provision for inter-mud notes/mail; see 'IMC NOTES'.


IMC2 was written by Oliver Jowett <oliver@sa-search.massey.ac.nz>, aka

Spectrum. Mail me if you're interested in connecting to the IMC network.

The source code is available at ftp://sa-search.massey.ac.nz/pub/mud/imc2/

The IMC2 home page is at http://sa-search.massey.ac.nz/-oliver/imc2/

(- = tilde)

~
0 IMCLIST~
Syntax:  imclist                  - get a list of active muds on IMC

         imclist direct           - get a list of directly connected muds

         imclist config           - see the local IMC config


'imclist' lists active muds on IMC. It lists all the muds which this mud knows

about on the IMC network, and when they were last heard from. The 'route'

section is mainly for diagnostics, and indicates the route that your mud will

send packets via to get to another mud.


'imclist direct' shows direct connections from your mud to other muds.


'imclist config' shows the local IMC configuration and state.


See also: IMC RQUERY

~
0 RCHAT RIMM RCODE~
These channels are obselete, use ICE instead.

~
0 RWHO~
Syntax:  rwho <mudname>               - ask for a who listing from another mud


'rwho' asks the given mud for a 'who' listing of its current players. Depending

on the network, it may take several seconds to get a response. You should use

the mud abbreviation listed in 'imclist' when issuing a rwho.


See also: IMC IMCLIST RQUERY RWHOIS

~
0 RWHOIS~
Syntax:  rwhois <playername>          - find a player on IMC


'rwhois' asks all muds on IMC for a player with the given name. You should not

include a @mudname section - just the playername. Replies will be returned

from those muds who have a player by that name connected.


See also: IMC RWHO RFINGER

~
0 RFINGER~
Syntax:  rfinger <player@mudname>     - get information about a player


'rfinger' asks the specified mud for information about the specified player.

The information you will get back (and even its existance) depends on the

remote mud, but will typically give at least their last login time.


See also: IMC RWHO RWHOIS

~
0 RTELL RREPLY~
Syntax:  rtell <player@mudname> <message>    - send a 'tell' to another player

         rreply <message>                    - send a 'tell' to the last player

                                               to send you a rtell


rtell and rreply are the IMC equivalents of tell and reply, and work nearly

identically. To rtell, however, you need to supply both a playername and a

mudname (as shown in 'imclist'). rreply will reply to the last rtell you

received from a player - even if that player was invisible to you.


See also: IMC IMCLIST

~
0 RQUERY~
Syntax:  rquery <mudname> help         - ask for available rquery options

         rquery <mudname> <option>     - ask for information from a mud


RQuery is similar to rwho, except it requests different information from a

mud. Each mud differs in what information it supplies, but 'rquery <mudname>

help' will give you a list of options that you can ask for.


Typically at least the following are supported:


rquery <mud> who        - ask for a who listing, identical to 'rwho'

rquery <mud> info       - get general information on the mud, usually including

                          its address. This is the preferred way of finding

                          out the address of a mud on IMC - don't ask on rchat!

rquery <mud> list       - ask for a list of IMC connections, from that mud's

                          point of view. Identical to 'imclist' on the remote

                          mud.

rquery <mud> istats     - ask for some IMC statistics, identical to 'istats' on

                          the remote mud.


See also: IMC IMCLIST RWHO

~
0 RBEEP~
Syntax:  rbeep <player@mudname>     - "beep" a player over IMC


rbeep sends an audible beep to another player on another mud (the @mudname

part indicates which mud; see 'imclist'). Note that this should only be done

when you _really_ need to get their attention; abusing rbeep will usually

lead to your IMC priviliges being revoked.


See also: IMC IMCLIST

~
0 ISTATS~
Syntax:  istats                     - display use(less?) statistics


istats shows some (maybe :) interesting statistics about how much traffic your

mud is generating due to IMC.


See also: IMC IMCLIST RQUERY

~
0 RCHANNELS RCHAN RINVIS~
Syntax:  rchannels                  - display your current IMC channel state

         rchannels +<channel>       - turn on an IMC channel

         rchannels -<channel>       - turn off an IMC channel


rchannels on its own will show you which IMC channels you have access to, and

whether they are currently on or off.


rchannels with an argument will turn on or off a given IMC channel that you

have access to.


rchannels can also be used to block rtells and rbeeps if necessary.


One additional option is rinvis. rchannels +rinvis will make you totally

invisible to IMC: you cannot be contacted by rtell, rreply, or rbeep, and

you do not appear on rwho. However, you cannot use any IMC channels while

rinvis is active (you can still hear them, though). rchannels -rinvis will

reverse this state.


Immortals may allow you access to IMC channels, or revoke your access to 

them, as necessary.


See also: IMC RCHAT RBEEP RTELL

~
-1 'IMC NOTES'~
Notes (boards, mail, etc) are very mud-dependent, but in general, if they

have been connected to IMC, then you can simply write notes to player@mudname

in addition to normal 'player'.


For example, you may be able to do:


note to abcde@somemud anotherplayer immortal@someothermud


and the note would go to:

  abcde on the mud called 'somemud'

  anotherplayer on your mud

  all immortals on the mud called 'someothermud'


The 'playernames' used are interpreted by the mud that receives them, not

your mud, so be careful when writing notes to group names such as 'immortal'.


If your note cannot be delivered within 12 hours for some reason (if the

mud is down, does not exist, or refused your mail) then you will get a note

from the system telling you so.


See also: IMC

~
-1 'IMC IMMORTAL COMMANDS' RINFO~
IMC Immortal commands:


- RINFO       : A channel which the various hubs put status reports onto. Can

                be spammy at times; you may want to turn off rinfo for this

                reason.

- RSOCKETS    : displays debugging info on the current IMC connection state.

- RCONNECT    : force a connection to a directly connected mud.

- RDISCONNECT : forcibly disconnect a directly connected mud.

- RIGNORE     : ignore a player or an entire mud on IMC.

- MAILQUEUE   : show the current queue of pending inter-mud notes.

- IMC         : edit the IMC configuration for your mud (see 'IMC CONFIG')

- RCHANSET    : manage access to IMC channels/rtell/rbeep for players.

- RPING       : trace IMC connectivity


See also: IMC

~
0 RSOCKETS~
Syntax:  rsockets                   - display IMC socket usage


rsockets displays the current connection state for the direct IMC connections

that your mud has. The various fields are:


Desc  : the system-level descriptor used for this connection


Mud   : which mud this connection is for


State : how far through the connection process this connection is:

        - connecting: waiting for the other end to accept our TCP connection

        - wait1:      waiting for the password from an incoming client

        - wait2:      waiting for the server to respond to our password

        - connected:  the connection is completely 'up'


Inbuf : the size of data waiting in the input and output queues for this

Outbuf: connection.


Spam1 : spam-protection counters

Spam2 :


See also: IMC 'IMC IMMORTAL COMMANDS'

~
0 RCONNECT~
Syntax:  rconnect <mudname>                - start an IMC connection


rconnect will initiate a connection to the given mud. Note that this has to

be a _directly_ connected mud (ie. a mud in the first section of imclist).

Feedback on the state of the connection will be logged to 'wiznet imc', and 

you may want to check imclist to see if it was successful.


See also: IMC 'IMC IMMORTAL' RDISCONNECT

~
0 RDISCONNECT~
Syntax:  rdisconnect <mudname>             - terminate an IMC connection


rdisconnect reverses rconnect, severing all connections to the named mud.


See also: IMC 'IMC IMMORTAL COMMANDS' RCONNECT

~
0 RIGNORE~
Syntax:  rignore                           - list current rignores

         rignore ignore  <pattern>         - ignore player(s) or mud(s)

         rignore notrust <pattern>         - don't trust player(s) or mud(s)

	 rignore delete  <pattern>         - remove a rignore


rignore ignores or restricts the access, at a mud-wide level, everything

coming in over IMC for a specified player or group of players. Currently

two possible actions are possible: ignore and notrust.


Ignore means:


- rtells/rbeeps/rwhos will be ignored, and a rtell sent back to say that the

  mud is ignoring them.

- no messages from them on rchat, rcode, etc will appear on your mud.


Notrust means:


- any rwho/rfinger/etc requests from a mud/player matching the pattern will

  be treated as if they were from a level 1 mortal - ie. wizi imms will never

  be revealed on rwho, and rtells won't see them, etc.

- any incoming channel messages from something matching the pattern are

  stripped of wizi status - they will be visible to everyone in general.


Patterns can be one of:


  player@mud              - matches a specific player at a specific mud

  *suffix                 - matches anything ending with that suffix

                            (commonly used as *@mud)

  prefix*                 - matches anything beginning with that prefix

                            (for example, player@*)

  *substring*             - matches anything containing that substring


Use with care.


See also: IMC 'IMC IMMORTAL COMMANDS'

~
0 MAILQUEUE~
Syntax:  mailqueue                         - show current IMC mailqueue


This command simply shows the current contents of the outgoing IMC mailqueue

for inter-mud notes. Due to the internal implementation of this (static

buffers - ick), only the first 8-9 entries will be shown.


See also: IMC 'IMC IMMORTAL COMMANDS' 'IMC NOTES'

~
0 RCHANSET~
Syntax:  chanset <player>             - see a players current IMC flags

         chanset <player> +<channel>  - set 'allow' flag on a player

         chanset <player> -<channel>  - set 'deny' flag on a player

         chanset <player> =<channel>  - reset allow/deny flags on a player


This command allows you to view or change a players IMC channel priviliges.

In all cases <channel> can be the name of an IMC channel (rchat, rcode, etc)

or 'rtell' or 'rbeep'.


Setting the allow flag for a channel allows that player to see and use that

channel, regardless of their level. This can be used, for example, to give

mortals with coding experience access to rcode.


Setting the deny flag for a channel prevents that player from using or

seeing that channel, even if their level normally allows them to. This can be

used as a penalty for players who abuse the IMC channels or rtell/rbeep.


Resetting the allow/deny flags simply clears them, using only the player's

level to determing whether they can use the channel.


See also: IMC 'IMC IMMORTAL COMMANDS' RCHAT RCODE RIMM RINFO

~
0 'IMC CONFIG'~
The 'imc' command is used to configure your IMC setup:


Syntax:  imc add <mudname>            - add a new IMC connection entry

         imc set <...>                - set the details of an IMC connection

         imc delete <mudname>         - remove an IMC connection

         imc rename <old> <new>       - rename an IMC connection

         imc reload                   - load a new IMC config file from disk

         imc localname <name>         - set the local IMC name

         imc localport <port>         - set the local IMC port


Add, delete, and rename should be self-explanatory. The name of an IMC

connection MUST match the name which the other end is using.


Reload destroys the version of the configuration in memory, and reloads it

from disk. This is useful if you have hand-edited the config file and want

to load your changes without rebooting. 'imc reload' also reloads the

rignores file.


The set command has several forms:


imc set <mudname> all <data...>     - set all values for a mud

                  host <hostname>   - set the hostname to connect to

                  port <portnum>    - set the remote IMC port to connect to

                  clientpw <pw>     - set the case-sensitive client password

                  serverpw <pw>     - set the case-sensitive server password

                  rcvstamp <value>  - set the receivestamp

                  noforward <value> - set the noforward bitmask

                  flags <value>     - set the connection flags


The 'all' form takes a series of values:


imc set <mudname> all <host> <port> <clientpw> <serverpw> <rcvstamp>

                      <noforward> <flags>


For information on the exact details of each field, see the IMC documentation.


The localname and localport commands set the IMC name and port of -your- mud.

Use with care.


See also: IMC 'IMC IMMORTAL COMMANDS'

~
-1 ICE~
ICE - the IMC Channel Extensions protocol


ICE is a response to the cesspool-like attributes that rchat, rimm, and

even rcode have acquired over the last few months. It is IRC-ish in some

ways, but hopefully it will be used more constructively than IRC.


For a quick introduction and setup guide for ICE, see ICE-INTRO


The basic ICE structure is (greatly simplified):


. Some nodes on IMC - normally hubs - run channel daemon code that

  manages channels

. Each of these nodes maintains a list of the channels they manage, and

  the various attributes of them - who owns them, and so on

. The daemons regularly tell all muds on IMC what channels they have, and

  what their attributes are

. Based on this information, the muds on IMC decide which of their local

  users can use which ICE channels. If one mud is modified to ignore these

  restrictions, then the other muds will recognize this (since they, too,

  know the restrictions) and ignore messages from that mud.


Every channel on ICE is of the form nodename:channelname, for example a

channel called hub2:IAdmin is the channel IAdmin maintained by the node hub2.

Each mud picks which channels it is interested in (see ILIST and

ISETUP) and creates a local channel name which can be used to talk on

that channel.


Generally, any admin on a mud can create a channel on any node - although

nodes can be configured to restrict who can create channels. Whoever

creates a channel owns it, and can control who can use that channel (in

whatever way they wish). The trick, of course, is to persuade the admins

of other muds that your channel has value. Creating and modifying a

channel is done via the ICOMMAND command.


Channels can be tuned into and out of on a player-by-player basis by

using the ICHAN command.


There are a variety of ways of controlling who can hear and use a channel

- see ICE-POLICY for more information.


See also: IMC ILIST ISETUP ICOMMAND ICHAN ICE-POLICY ICE-INTRO

~
-1 ICE-INTRO~
A Quick Introduction to ICE


This assumes that the code for IMC and ICE is installed and running, and

that you have an active connection to an IMC network.


1. ILIST. This will give you a list of possible channels to choose from.

   Pick one that you want to add, that has a policy of 'open'. Note its

   name (of the form node:channel).


2. Decide what command you want to use to speak on this channel on your

   mud. This is the channel's localname.


3. Type: ISETUP ADD <node:channel> <localname>


4. You should now be able to use the channel. Others can listen to and

   speak on the channel by using ICHAN <localname>.


5. You may wish to reconfigure the default local channel settings.

   ILIST <localname> will display them; ISETUP will change them.


6. Repeat for whatever other channels you wish to have.


See also: IMC ICE ISETUP ICOMMAND ICHAN ILIST

~
0 ICHAN~
Syntax:  ichan               - display current ICE channel status

         ichan <localname>   - toggle an ICE channel


IChan lets you show and toggle which ICE channels you are listening

to. Without arguments, it will show you the channels you belog to; with

an argument, it will turn on or off that channel.


Any channels you listen to must be locally configured first - see

ISETUP. ILIST can be used to see available channels.


See also: IMC ICE ILIST ISETUP

~
0 ICOMMAND~
Syntax:          icommand <command> <channel> [<data..>]

Common commands:  create <channel>           - create a channel

                  refresh <channel>          - refresh channel data

                  list [<channel>]           - list available commands

                  destroy <channel>          - destroy a channel

                  policy <channel> <policy>  - change channel policy

                  addop <channel> <name>     - add a channel operator

                  removeop <channel> <name>  - remove an operator

                  invite <channel> <name>    - add an invited name

                  uninvite <channel> <name>  - remove an invited name

                  exclude <channel> <name>   - exclude a name

                  unexclude <channel> <name> - remove an exclusion


ICommand is used to send commands to a channel daemon elsewhere on IMC.

It directly affects the channel itself - any changes made here will

affect all muds using the channel.


Since the actual commands are interpreted by the channel daemon, not your

mud, what is available may vary. To get a list of available commands, use

icommand list <nodename> for public commands, or icommand list

<node:channel> to see what commands you have for that channel.


icommand refresh asks the daemon to refresh your mud's information for a

channel, if it ever gets out of synx. Asking for a refresh of nodename:*

will refresh all channels on that daemon.


icommand create creates a new channel, with you as the owner

icommand destroy destroys a channel. You must own the channel.


icommand policy changes the basic policy of the channel (see ICE-POLICY).

You must be the owner.


icommand addop/removeop add and remove operators from a channel. You must

be the owner, and specify the operator's full user@mud name.


icommand invite/uninvite/exclude/unexcluded modify the invite and exclude

lists for a channel. You must be the owner or an operator on the channel.

Either a full user@mud or a simple 'mud' name (no @) can be specified.

See ICE-POLICY for more details.


See also: IMC ICE ICE-POLICY

~
0 ISETUP~
Syntax: isetup add <ice-channel> <localname>   - add a channel

        isetup delete <localname>              - delete a channel

        isetup rename <oldname> <newname>      - rename a channel

        isetup format1 <localname> <format>    - change format1 on a channel

        isetup format2 <localname> <format>    - change format2 on a channel

        isetup level <localname> <level>       - set channel level


ISetup allows you to change the local configuration of an ICE

channel. None of these commands have a lasting effect on the channel's

configuration on other muds.


ISetup add begins the configuration of a channel. It connects the

specified ice-channel (of the form nodename:channelname) to a local name.

For example: isetup add hub2:IAdmin IAdmin. The local name is also the

command used to speak on the channel.


When the channel is added, various default values are filled in for

format1, format2, and level.


ISetup delete removes this link. It does not affect the channel itself;

it just deletes the local configuration link for the channel.


ISetup rename changes the local name of a channel. It does not affect the

channel name itself for other muds - just the command used locally to

access it.


ISetup format1 and format2 change how a channel is displayed locally.

Each format string must have exactly two %s's within it (this is checked

for) - the first will be replaced by the speaker's name, the second by

whatever they say. Format1 is used for normal speech, format2 for emotes.

See ILIST for more information.


ISetup level sets the minimum level necessary on your mud to hear or use

the channel.


See also: IMC ICE ILIST

~
0 ILIST~
Syntax:  ilist               - list all known ICE channels

         ilist <channel>     - list details on one ICE channel


IList displays information on channels active on ICE.

Without arguments, it will produce a display similar to:


Name            Local name      Owner           Policy

hub2:IAdmin     IAdmin          Nemon@AR        open

hub2:ICode      ICode                                    (inactive)

hub2:test       (not local)     Nemon@ARtest    private


This shows the canonical name (eg. hub2:IAdmin), the local name (eg IAdmin

- which can be used as an abbreviation in ISETUP, and which is also

the command to speak on that channel), the owner of the channel (eg.

Nemon@AR), and the channel's policy (see ICE-POLICY).


If a channel is not configured locally, it will have (not local) for its

local name.


If a channel is configured locally, but is not actually active on IMC, it

will have an (inactive) flag on it.


IList with a channel name will provide detailed information on that

channel. For example:


Channel hub2:IAdmin:

  Local name: IAdmin

  Format 1:   (IAdmin) %s: %s

  Format 2:   (IAdmin) %s %s

  Level:      102


  Policy:     open

  Owner:      Nemon@AR

  Operators:  Drylock@AR

  Invited:    NiceGuy@SomeMud

  Excluded:   SomeMud


This displays the channel name, local name, policy, and owner, as above. It

also displays:


- the minimum level needed on your mud to see the channel


- the format for displaying messages from the channel. These can contain

  any color codes etc. that your mud uses.


  Format1 is the string displayed when someone speaks normally on the

  channel - the first %s is replaced by their name, the second %s by what

  they say.


  Format2 is a similar string for emotes. Again the first %s is their name,

  the second %s the text of their emote.


- any operators for the channel. This can only be changed by the owner of

  the channel. Operators can modify the 'invited' and 'excluded' fields

  via the ISETUP command.


- the invited and excluded people on the channel. See ICE-POLICY for

  more details.


See also: IMC ICE ISETUP ICOMMAND ICE-POLICY

~
-1 ICE-POLICY~
ICE Channel Policies


Channels can have one of three policies - open, closed, and private. They

also have one owner, and zero or more operators (assigned by the owner).

They also have an include and exclude list (which can specify both

individual players ['user@mud'] and entire muds ['mud']), which can be

modified by the owner and the operators.


- Open. The channel can be accessed by all muds on the network (it is a

  broadcast channel). People on the exclude list cannot use the channel,

  with the exception of people also on the invite list. This means, for

  example, if an entire mud is excluded and one player is invited, that

  player can use the channel, but the rest of the mud can't.


- Closed. The channel can be accessed by all muds on the network (it is a

  broadcast channel), but by default they will not hear or be able to use

  it. People on the invite list can use the channel, with the exception of

  people also on the exclude list.


- Private. Identical to closed, except that the channel is actually only

  physically sent to those muds that are on the invite list. This is good

  for channels specific to a small group of muds, and not of interest to

  the majority of the network.


See also: IMC ICE ICOMMAND

~
-1 IMC~
IMC (Inter-Mud Communication) provides a way for muds to connect together and

share various services: chat channels, tells, notes, who listings, and so on.


The available mortal-level IMC commands are as follows. See the help topics

for each of these for more information.


- IMCLIST : get a list of active muds that are connected to IMC.

- RCHAT   : send a message on the common chat channel.

- RWHO    : send a who request to a mud.

- RTELL   : send a tell to someone on another mud.

- RREPLY  : reply to a rtell from someone on another mud.

- RQUERY  : ask for information of some type from another mud.

- RBEEP   : "beep" another player. Use sparingly.

- RWHOIS  : find someone on IMC

- RFINGER : get information about a player on another mud

- ISTATS  : get some (interesting?) stats about IMC.

- RCHAN   : show which channels you are listening to, and modify that state.


There is also provision for inter-mud notes/mail; see 'IMC NOTES'.


IMC2 was written by Oliver Jowett <oliver@sa-search.massey.ac.nz>, aka

Spectrum. Mail me if you're interested in connecting to the IMC network.

The source code is available at ftp://sa-search.massey.ac.nz/pub/mud/imc2/

The IMC2 home page is at http://sa-search.massey.ac.nz/-oliver/imc2/

(- = tilde)

~
0 IMCLIST~
Syntax:  imclist                  - get a list of active muds on IMC

         imclist direct           - get a list of directly connected muds

         imclist config           - see the local IMC config


'imclist' lists active muds on IMC. It lists all the muds which this mud knows

about on the IMC network, and when they were last heard from. The 'route'

section is mainly for diagnostics, and indicates the route that your mud will

send packets via to get to another mud.


'imclist direct' shows direct connections from your mud to other muds.


'imclist config' shows the local IMC configuration and state.


See also: IMC RQUERY

~
0 RCHAT RIMM RCODE~
These channels are obselete, use ICE instead.

~
0 RWHO~
Syntax:  rwho <mudname>               - ask for a who listing from another mud


'rwho' asks the given mud for a 'who' listing of its current players. Depending

on the network, it may take several seconds to get a response. You should use

the mud abbreviation listed in 'imclist' when issuing a rwho.


See also: IMC IMCLIST RQUERY RWHOIS

~
0 RWHOIS~
Syntax:  rwhois <playername>          - find a player on IMC


'rwhois' asks all muds on IMC for a player with the given name. You should not

include a @mudname section - just the playername. Replies will be returned

from those muds who have a player by that name connected.


See also: IMC RWHO RFINGER

~
0 RFINGER~
Syntax:  rfinger <player@mudname>     - get information about a player


'rfinger' asks the specified mud for information about the specified player.

The information you will get back (and even its existance) depends on the

remote mud, but will typically give at least their last login time.


See also: IMC RWHO RWHOIS

~
0 RTELL RREPLY~
Syntax:  rtell <player@mudname> <message>    - send a 'tell' to another player

         rreply <message>                    - send a 'tell' to the last player

                                               to send you a rtell


rtell and rreply are the IMC equivalents of tell and reply, and work nearly

identically. To rtell, however, you need to supply both a playername and a

mudname (as shown in 'imclist'). rreply will reply to the last rtell you

received from a player - even if that player was invisible to you.


See also: IMC IMCLIST

~
0 RQUERY~
Syntax:  rquery <mudname> help         - ask for available rquery options

         rquery <mudname> <option>     - ask for information from a mud


RQuery is similar to rwho, except it requests different information from a

mud. Each mud differs in what information it supplies, but 'rquery <mudname>

help' will give you a list of options that you can ask for.


Typically at least the following are supported:


rquery <mud> who        - ask for a who listing, identical to 'rwho'

rquery <mud> info       - get general information on the mud, usually including

                          its address. This is the preferred way of finding

                          out the address of a mud on IMC - don't ask on rchat!

rquery <mud> list       - ask for a list of IMC connections, from that mud's

                          point of view. Identical to 'imclist' on the remote

                          mud.

rquery <mud> istats     - ask for some IMC statistics, identical to 'istats' on

                          the remote mud.


See also: IMC IMCLIST RWHO

~
0 RBEEP~
Syntax:  rbeep <player@mudname>     - "beep" a player over IMC


rbeep sends an audible beep to another player on another mud (the @mudname

part indicates which mud; see 'imclist'). Note that this should only be done

when you _really_ need to get their attention; abusing rbeep will usually

lead to your IMC priviliges being revoked.


See also: IMC IMCLIST

~
0 ISTATS~
Syntax:  istats                     - display use(less?) statistics


istats shows some (maybe :) interesting statistics about how much traffic your

mud is generating due to IMC.


See also: IMC IMCLIST RQUERY

~
0 RCHANNELS RCHAN RINVIS~
Syntax:  rchannels                  - display your current IMC channel state

         rchannels +<channel>       - turn on an IMC channel

         rchannels -<channel>       - turn off an IMC channel


rchannels on its own will show you which IMC channels you have access to, and

whether they are currently on or off.


rchannels with an argument will turn on or off a given IMC channel that you

have access to.


rchannels can also be used to block rtells and rbeeps if necessary.


One additional option is rinvis. rchannels +rinvis will make you totally

invisible to IMC: you cannot be contacted by rtell, rreply, or rbeep, and

you do not appear on rwho. However, you cannot use any IMC channels while

rinvis is active (you can still hear them, though). rchannels -rinvis will

reverse this state.


Immortals may allow you access to IMC channels, or revoke your access to 

them, as necessary.


See also: IMC RCHAT RBEEP RTELL

~
-1 'IMC NOTES'~
Notes (boards, mail, etc) are very mud-dependent, but in general, if they

have been connected to IMC, then you can simply write notes to player@mudname

in addition to normal 'player'.


For example, you may be able to do:


note to abcde@somemud anotherplayer immortal@someothermud


and the note would go to:

  abcde on the mud called 'somemud'

  anotherplayer on your mud

  all immortals on the mud called 'someothermud'


The 'playernames' used are interpreted by the mud that receives them, not

your mud, so be careful when writing notes to group names such as 'immortal'.


If your note cannot be delivered within 12 hours for some reason (if the

mud is down, does not exist, or refused your mail) then you will get a note

from the system telling you so.


See also: IMC

~
-1 'IMC IMMORTAL COMMANDS' RINFO~
IMC Immortal commands:


- RINFO       : A channel which the various hubs put status reports onto. Can

                be spammy at times; you may want to turn off rinfo for this

                reason.

- RSOCKETS    : displays debugging info on the current IMC connection state.

- RCONNECT    : force a connection to a directly connected mud.

- RDISCONNECT : forcibly disconnect a directly connected mud.

- RIGNORE     : ignore a player or an entire mud on IMC.

- MAILQUEUE   : show the current queue of pending inter-mud notes.

- IMC         : edit the IMC configuration for your mud (see 'IMC CONFIG')

- RCHANSET    : manage access to IMC channels/rtell/rbeep for players.

- RPING       : trace IMC connectivity


See also: IMC

~
0 RSOCKETS~
Syntax:  rsockets                   - display IMC socket usage


rsockets displays the current connection state for the direct IMC connections

that your mud has. The various fields are:


Desc  : the system-level descriptor used for this connection


Mud   : which mud this connection is for


State : how far through the connection process this connection is:

        - connecting: waiting for the other end to accept our TCP connection

        - wait1:      waiting for the password from an incoming client

        - wait2:      waiting for the server to respond to our password

        - connected:  the connection is completely 'up'


Inbuf : the size of data waiting in the input and output queues for this

Outbuf: connection.


Spam1 : spam-protection counters

Spam2 :


See also: IMC 'IMC IMMORTAL COMMANDS'

~
0 RCONNECT~
Syntax:  rconnect <mudname>                - start an IMC connection


rconnect will initiate a connection to the given mud. Note that this has to

be a _directly_ connected mud (ie. a mud in the first section of imclist).

Feedback on the state of the connection will be logged to 'wiznet imc', and 

you may want to check imclist to see if it was successful.


See also: IMC 'IMC IMMORTAL' RDISCONNECT

~
0 RDISCONNECT~
Syntax:  rdisconnect <mudname>             - terminate an IMC connection


rdisconnect reverses rconnect, severing all connections to the named mud.


See also: IMC 'IMC IMMORTAL COMMANDS' RCONNECT

~
0 RIGNORE~
Syntax:  rignore                           - list current rignores

         rignore ignore  <pattern>         - ignore player(s) or mud(s)

         rignore notrust <pattern>         - don't trust player(s) or mud(s)

	 rignore delete  <pattern>         - remove a rignore


rignore ignores or restricts the access, at a mud-wide level, everything

coming in over IMC for a specified player or group of players. Currently

two possible actions are possible: ignore and notrust.


Ignore means:


- rtells/rbeeps/rwhos will be ignored, and a rtell sent back to say that the

  mud is ignoring them.

- no messages from them on rchat, rcode, etc will appear on your mud.


Notrust means:


- any rwho/rfinger/etc requests from a mud/player matching the pattern will

  be treated as if they were from a level 1 mortal - ie. wizi imms will never

  be revealed on rwho, and rtells won't see them, etc.

- any incoming channel messages from something matching the pattern are

  stripped of wizi status - they will be visible to everyone in general.


Patterns can be one of:


  player@mud              - matches a specific player at a specific mud

  *suffix                 - matches anything ending with that suffix

                            (commonly used as *@mud)

  prefix*                 - matches anything beginning with that prefix

                            (for example, player@*)

  *substring*             - matches anything containing that substring


Use with care.


See also: IMC 'IMC IMMORTAL COMMANDS'

~
0 MAILQUEUE~
Syntax:  mailqueue                         - show current IMC mailqueue


This command simply shows the current contents of the outgoing IMC mailqueue

for inter-mud notes. Due to the internal implementation of this (static

buffers - ick), only the first 8-9 entries will be shown.


See also: IMC 'IMC IMMORTAL COMMANDS' 'IMC NOTES'

~
0 RCHANSET~
Syntax:  chanset <player>             - see a players current IMC flags

         chanset <player> +<channel>  - set 'allow' flag on a player

         chanset <player> -<channel>  - set 'deny' flag on a player

         chanset <player> =<channel>  - reset allow/deny flags on a player


This command allows you to view or change a players IMC channel priviliges.

In all cases <channel> can be the name of an IMC channel (rchat, rcode, etc)

or 'rtell' or 'rbeep'.


Setting the allow flag for a channel allows that player to see and use that

channel, regardless of their level. This can be used, for example, to give

mortals with coding experience access to rcode.


Setting the deny flag for a channel prevents that player from using or

seeing that channel, even if their level normally allows them to. This can be

used as a penalty for players who abuse the IMC channels or rtell/rbeep.


Resetting the allow/deny flags simply clears them, using only the player's

level to determing whether they can use the channel.


See also: IMC 'IMC IMMORTAL COMMANDS' RCHAT RCODE RIMM RINFO

~
0 'IMC CONFIG'~
The 'imc' command is used to configure your IMC setup:


Syntax:  imc add <mudname>            - add a new IMC connection entry

         imc set <...>                - set the details of an IMC connection

         imc delete <mudname>         - remove an IMC connection

         imc rename <old> <new>       - rename an IMC connection

         imc reload                   - load a new IMC config file from disk

         imc localname <name>         - set the local IMC name

         imc localport <port>         - set the local IMC port


Add, delete, and rename should be self-explanatory. The name of an IMC

connection MUST match the name which the other end is using.


Reload destroys the version of the configuration in memory, and reloads it

from disk. This is useful if you have hand-edited the config file and want

to load your changes without rebooting. 'imc reload' also reloads the

rignores file.


The set command has several forms:


imc set <mudname> all <data...>     - set all values for a mud

                  host <hostname>   - set the hostname to connect to

                  port <portnum>    - set the remote IMC port to connect to

                  clientpw <pw>     - set the case-sensitive client password

                  serverpw <pw>     - set the case-sensitive server password

                  rcvstamp <value>  - set the receivestamp

                  noforward <value> - set the noforward bitmask

                  flags <value>     - set the connection flags


The 'all' form takes a series of values:


imc set <mudname> all <host> <port> <clientpw> <serverpw> <rcvstamp>

                      <noforward> <flags>


For information on the exact details of each field, see the IMC documentation.


The localname and localport commands set the IMC name and port of -your- mud.

Use with care.


See also: IMC 'IMC IMMORTAL COMMANDS'

~
-1 ICE~
ICE - the IMC Channel Extensions protocol


ICE is a response to the cesspool-like attributes that rchat, rimm, and

even rcode have acquired over the last few months. It is IRC-ish in some

ways, but hopefully it will be used more constructively than IRC.


For a quick introduction and setup guide for ICE, see ICE-INTRO


The basic ICE structure is (greatly simplified):


. Some nodes on IMC - normally hubs - run channel daemon code that

  manages channels

. Each of these nodes maintains a list of the channels they manage, and

  the various attributes of them - who owns them, and so on

. The daemons regularly tell all muds on IMC what channels they have, and

  what their attributes are

. Based on this information, the muds on IMC decide which of their local

  users can use which ICE channels. If one mud is modified to ignore these

  restrictions, then the other muds will recognize this (since they, too,

  know the restrictions) and ignore messages from that mud.


Every channel on ICE is of the form nodename:channelname, for example a

channel called hub2:IAdmin is the channel IAdmin maintained by the node hub2.

Each mud picks which channels it is interested in (see ILIST and

ISETUP) and creates a local channel name which can be used to talk on

that channel.


Generally, any admin on a mud can create a channel on any node - although

nodes can be configured to restrict who can create channels. Whoever

creates a channel owns it, and can control who can use that channel (in

whatever way they wish). The trick, of course, is to persuade the admins

of other muds that your channel has value. Creating and modifying a

channel is done via the ICOMMAND command.


Channels can be tuned into and out of on a player-by-player basis by

using the ICHAN command.


There are a variety of ways of controlling who can hear and use a channel

- see ICE-POLICY for more information.


See also: IMC ILIST ISETUP ICOMMAND ICHAN ICE-POLICY ICE-INTRO

~
-1 ICE-INTRO~
A Quick Introduction to ICE


This assumes that the code for IMC and ICE is installed and running, and

that you have an active connection to an IMC network.


1. ILIST. This will give you a list of possible channels to choose from.

   Pick one that you want to add, that has a policy of 'open'. Note its

   name (of the form node:channel).


2. Decide what command you want to use to speak on this channel on your

   mud. This is the channel's localname.


3. Type: ISETUP ADD <node:channel> <localname>


4. You should now be able to use the channel. Others can listen to and

   speak on the channel by using ICHAN <localname>.


5. You may wish to reconfigure the default local channel settings.

   ILIST <localname> will display them; ISETUP will change them.


6. Repeat for whatever other channels you wish to have.


See also: IMC ICE ISETUP ICOMMAND ICHAN ILIST

~
0 ICHAN~
Syntax:  ichan               - display current ICE channel status

         ichan <localname>   - toggle an ICE channel


IChan lets you show and toggle which ICE channels you are listening

to. Without arguments, it will show you the channels you belog to; with

an argument, it will turn on or off that channel.


Any channels you listen to must be locally configured first - see

ISETUP. ILIST can be used to see available channels.


See also: IMC ICE ILIST ISETUP

~
0 ICOMMAND~
Syntax:          icommand <command> <channel> [<data..>]

Common commands:  create <channel>           - create a channel

                  refresh <channel>          - refresh channel data

                  list [<channel>]           - list available commands

                  destroy <channel>          - destroy a channel

                  policy <channel> <policy>  - change channel policy

                  addop <channel> <name>     - add a channel operator

                  removeop <channel> <name>  - remove an operator

                  invite <channel> <name>    - add an invited name

                  uninvite <channel> <name>  - remove an invited name

                  exclude <channel> <name>   - exclude a name

                  unexclude <channel> <name> - remove an exclusion


ICommand is used to send commands to a channel daemon elsewhere on IMC.

It directly affects the channel itself - any changes made here will

affect all muds using the channel.


Since the actual commands are interpreted by the channel daemon, not your

mud, what is available may vary. To get a list of available commands, use

icommand list <nodename> for public commands, or icommand list

<node:channel> to see what commands you have for that channel.


icommand refresh asks the daemon to refresh your mud's information for a

channel, if it ever gets out of synx. Asking for a refresh of nodename:*

will refresh all channels on that daemon.


icommand create creates a new channel, with you as the owner

icommand destroy destroys a channel. You must own the channel.


icommand policy changes the basic policy of the channel (see ICE-POLICY).

You must be the owner.


icommand addop/removeop add and remove operators from a channel. You must

be the owner, and specify the operator's full user@mud name.


icommand invite/uninvite/exclude/unexcluded modify the invite and exclude

lists for a channel. You must be the owner or an operator on the channel.

Either a full user@mud or a simple 'mud' name (no @) can be specified.

See ICE-POLICY for more details.


See also: IMC ICE ICE-POLICY

~
0 ISETUP~
Syntax: isetup add <ice-channel> <localname>   - add a channel

        isetup delete <localname>              - delete a channel

        isetup rename <oldname> <newname>      - rename a channel

        isetup format1 <localname> <format>    - change format1 on a channel

        isetup format2 <localname> <format>    - change format2 on a channel

        isetup level <localname> <level>       - set channel level


ISetup allows you to change the local configuration of an ICE

channel. None of these commands have a lasting effect on the channel's

configuration on other muds.


ISetup add begins the configuration of a channel. It connects the

specified ice-channel (of the form nodename:channelname) to a local name.

For example: isetup add hub2:IAdmin IAdmin. The local name is also the

command used to speak on the channel.


When the channel is added, various default values are filled in for

format1, format2, and level.


ISetup delete removes this link. It does not affect the channel itself;

it just deletes the local configuration link for the channel.


ISetup rename changes the local name of a channel. It does not affect the

channel name itself for other muds - just the command used locally to

access it.


ISetup format1 and format2 change how a channel is displayed locally.

Each format string must have exactly two %s's within it (this is checked

for) - the first will be replaced by the speaker's name, the second by

whatever they say. Format1 is used for normal speech, format2 for emotes.

See ILIST for more information.


ISetup level sets the minimum level necessary on your mud to hear or use

the channel.


See also: IMC ICE ILIST

~
0 ILIST~
Syntax:  ilist               - list all known ICE channels

         ilist <channel>     - list details on one ICE channel


IList displays information on channels active on ICE.

Without arguments, it will produce a display similar to:


Name            Local name      Owner           Policy

hub2:IAdmin     IAdmin          Nemon@AR        open

hub2:ICode      ICode                                    (inactive)

hub2:test       (not local)     Nemon@ARtest    private


This shows the canonical name (eg. hub2:IAdmin), the local name (eg IAdmin

- which can be used as an abbreviation in ISETUP, and which is also

the command to speak on that channel), the owner of the channel (eg.

Nemon@AR), and the channel's policy (see ICE-POLICY).


If a channel is not configured locally, it will have (not local) for its

local name.


If a channel is configured locally, but is not actually active on IMC, it

will have an (inactive) flag on it.


IList with a channel name will provide detailed information on that

channel. For example:


Channel hub2:IAdmin:

  Local name: IAdmin

  Format 1:   (IAdmin) %s: %s

  Format 2:   (IAdmin) %s %s

  Level:      102


  Policy:     open

  Owner:      Nemon@AR

  Operators:  Drylock@AR

  Invited:    NiceGuy@SomeMud

  Excluded:   SomeMud


This displays the channel name, local name, policy, and owner, as above. It

also displays:


- the minimum level needed on your mud to see the channel


- the format for displaying messages from the channel. These can contain

  any color codes etc. that your mud uses.


  Format1 is the string displayed when someone speaks normally on the

  channel - the first %s is replaced by their name, the second %s by what

  they say.


  Format2 is a similar string for emotes. Again the first %s is their name,

  the second %s the text of their emote.


- any operators for the channel. This can only be changed by the owner of

  the channel. Operators can modify the 'invited' and 'excluded' fields

  via the ISETUP command.


- the invited and excluded people on the channel. See ICE-POLICY for

  more details.


See also: IMC ICE ISETUP ICOMMAND ICE-POLICY

~
-1 ICE-POLICY~
ICE Channel Policies


Channels can have one of three policies - open, closed, and private. They

also have one owner, and zero or more operators (assigned by the owner).

They also have an include and exclude list (which can specify both

individual players ['user@mud'] and entire muds ['mud']), which can be

modified by the owner and the operators.


- Open. The channel can be accessed by all muds on the network (it is a

  broadcast channel). People on the exclude list cannot use the channel,

  with the exception of people also on the invite list. This means, for

  example, if an entire mud is excluded and one player is invited, that

  player can use the channel, but the rest of the mud can't.


- Closed. The channel can be accessed by all muds on the network (it is a

  broadcast channel), but by default they will not hear or be able to use

  it. People on the invite list can use the channel, with the exception of

  people also on the exclude list.


- Private. Identical to closed, except that the channel is actually only

  physically sent to those muds that are on the invite list. This is good

  for channels specific to a small group of muds, and not of interest to

  the majority of the network.


See also: IMC ICE ICOMMAND

~
-1 IMC~
IMC (Inter-Mud Communication) provides a way for muds to connect together and

share various services: chat channels, tells, notes, who listings, and so on.


The available mortal-level IMC commands are as follows. See the help topics

for each of these for more information.


- IMCLIST : get a list of active muds that are connected to IMC.

- RCHAT   : send a message on the common chat channel.

- RWHO    : send a who request to a mud.

- RTELL   : send a tell to someone on another mud.

- RREPLY  : reply to a rtell from someone on another mud.

- RQUERY  : ask for information of some type from another mud.

- RBEEP   : "beep" another player. Use sparingly.

- RWHOIS  : find someone on IMC

- RFINGER : get information about a player on another mud

- ISTATS  : get some (interesting?) stats about IMC.

- RCHAN   : show which channels you are listening to, and modify that state.


There is also provision for inter-mud notes/mail; see 'IMC NOTES'.


IMC2 was written by Oliver Jowett <oliver@sa-search.massey.ac.nz>, aka

Spectrum. Mail me if you're interested in connecting to the IMC network.

The source code is available at ftp://sa-search.massey.ac.nz/pub/mud/imc2/

The IMC2 home page is at http://sa-search.massey.ac.nz/-oliver/imc2/

(- = tilde)

~
0 IMCLIST~
Syntax:  imclist                  - get a list of active muds on IMC

         imclist direct           - get a list of directly connected muds

         imclist config           - see the local IMC config


'imclist' lists active muds on IMC. It lists all the muds which this mud knows

about on the IMC network, and when they were last heard from. The 'route'

section is mainly for diagnostics, and indicates the route that your mud will

send packets via to get to another mud.


'imclist direct' shows direct connections from your mud to other muds.


'imclist config' shows the local IMC configuration and state.


See also: IMC RQUERY

~
0 RCHAT RIMM RCODE~
These channels are obselete, use ICE instead.

~
0 RWHO~
Syntax:  rwho <mudname>               - ask for a who listing from another mud


'rwho' asks the given mud for a 'who' listing of its current players. Depending

on the network, it may take several seconds to get a response. You should use

the mud abbreviation listed in 'imclist' when issuing a rwho.


See also: IMC IMCLIST RQUERY RWHOIS

~
0 RWHOIS~
Syntax:  rwhois <playername>          - find a player on IMC


'rwhois' asks all muds on IMC for a player with the given name. You should not

include a @mudname section - just the playername. Replies will be returned

from those muds who have a player by that name connected.


See also: IMC RWHO RFINGER

~
0 RFINGER~
Syntax:  rfinger <player@mudname>     - get information about a player


'rfinger' asks the specified mud for information about the specified player.

The information you will get back (and even its existance) depends on the

remote mud, but will typically give at least their last login time.


See also: IMC RWHO RWHOIS

~
0 RTELL RREPLY~
Syntax:  rtell <player@mudname> <message>    - send a 'tell' to another player

         rreply <message>                    - send a 'tell' to the last player

                                               to send you a rtell


rtell and rreply are the IMC equivalents of tell and reply, and work nearly

identically. To rtell, however, you need to supply both a playername and a

mudname (as shown in 'imclist'). rreply will reply to the last rtell you

received from a player - even if that player was invisible to you.


See also: IMC IMCLIST

~
0 RQUERY~
Syntax:  rquery <mudname> help         - ask for available rquery options

         rquery <mudname> <option>     - ask for information from a mud


RQuery is similar to rwho, except it requests different information from a

mud. Each mud differs in what information it supplies, but 'rquery <mudname>

help' will give you a list of options that you can ask for.


Typically at least the following are supported:


rquery <mud> who        - ask for a who listing, identical to 'rwho'

rquery <mud> info       - get general information on the mud, usually including

                          its address. This is the preferred way of finding

                          out the address of a mud on IMC - don't ask on rchat!

rquery <mud> list       - ask for a list of IMC connections, from that mud's

                          point of view. Identical to 'imclist' on the remote

                          mud.

rquery <mud> istats     - ask for some IMC statistics, identical to 'istats' on

                          the remote mud.


See also: IMC IMCLIST RWHO

~
0 RBEEP~
Syntax:  rbeep <player@mudname>     - "beep" a player over IMC


rbeep sends an audible beep to another player on another mud (the @mudname

part indicates which mud; see 'imclist'). Note that this should only be done

when you _really_ need to get their attention; abusing rbeep will usually

lead to your IMC priviliges being revoked.


See also: IMC IMCLIST

~
0 ISTATS~
Syntax:  istats                     - display use(less?) statistics


istats shows some (maybe :) interesting statistics about how much traffic your

mud is generating due to IMC.


See also: IMC IMCLIST RQUERY

~
0 RCHANNELS RCHAN RINVIS~
Syntax:  rchannels                  - display your current IMC channel state

         rchannels +<channel>       - turn on an IMC channel

         rchannels -<channel>       - turn off an IMC channel


rchannels on its own will show you which IMC channels you have access to, and

whether they are currently on or off.


rchannels with an argument will turn on or off a given IMC channel that you

have access to.


rchannels can also be used to block rtells and rbeeps if necessary.


One additional option is rinvis. rchannels +rinvis will make you totally

invisible to IMC: you cannot be contacted by rtell, rreply, or rbeep, and

you do not appear on rwho. However, you cannot use any IMC channels while

rinvis is active (you can still hear them, though). rchannels -rinvis will

reverse this state.


Immortals may allow you access to IMC channels, or revoke your access to 

them, as necessary.


See also: IMC RCHAT RBEEP RTELL

~
-1 'IMC NOTES'~
Notes (boards, mail, etc) are very mud-dependent, but in general, if they

have been connected to IMC, then you can simply write notes to player@mudname

in addition to normal 'player'.


For example, you may be able to do:


note to abcde@somemud anotherplayer immortal@someothermud


and the note would go to:

  abcde on the mud called 'somemud'

  anotherplayer on your mud

  all immortals on the mud called 'someothermud'


The 'playernames' used are interpreted by the mud that receives them, not

your mud, so be careful when writing notes to group names such as 'immortal'.


If your note cannot be delivered within 12 hours for some reason (if the

mud is down, does not exist, or refused your mail) then you will get a note

from the system telling you so.


See also: IMC

~
-1 'IMC IMMORTAL COMMANDS' RINFO~
IMC Immortal commands:


- RINFO       : A channel which the various hubs put status reports onto. Can

                be spammy at times; you may want to turn off rinfo for this

                reason.

- RSOCKETS    : displays debugging info on the current IMC connection state.

- RCONNECT    : force a connection to a directly connected mud.

- RDISCONNECT : forcibly disconnect a directly connected mud.

- RIGNORE     : ignore a player or an entire mud on IMC.

- MAILQUEUE   : show the current queue of pending inter-mud notes.

- IMC         : edit the IMC configuration for your mud (see 'IMC CONFIG')

- RCHANSET    : manage access to IMC channels/rtell/rbeep for players.

- RPING       : trace IMC connectivity


See also: IMC

~
0 RSOCKETS~
Syntax:  rsockets                   - display IMC socket usage


rsockets displays the current connection state for the direct IMC connections

that your mud has. The various fields are:


Desc  : the system-level descriptor used for this connection


Mud   : which mud this connection is for


State : how far through the connection process this connection is:

        - connecting: waiting for the other end to accept our TCP connection

        - wait1:      waiting for the password from an incoming client

        - wait2:      waiting for the server to respond to our password

        - connected:  the connection is completely 'up'


Inbuf : the size of data waiting in the input and output queues for this

Outbuf: connection.


Spam1 : spam-protection counters

Spam2 :


See also: IMC 'IMC IMMORTAL COMMANDS'

~
0 RCONNECT~
Syntax:  rconnect <mudname>                - start an IMC connection


rconnect will initiate a connection to the given mud. Note that this has to

be a _directly_ connected mud (ie. a mud in the first section of imclist).

Feedback on the state of the connection will be logged to 'wiznet imc', and 

you may want to check imclist to see if it was successful.


See also: IMC 'IMC IMMORTAL' RDISCONNECT

~
0 RDISCONNECT~
Syntax:  rdisconnect <mudname>             - terminate an IMC connection


rdisconnect reverses rconnect, severing all connections to the named mud.


See also: IMC 'IMC IMMORTAL COMMANDS' RCONNECT

~
0 RIGNORE~
Syntax:  rignore                           - list current rignores

         rignore ignore  <pattern>         - ignore player(s) or mud(s)

         rignore notrust <pattern>         - don't trust player(s) or mud(s)

	 rignore delete  <pattern>         - remove a rignore


rignore ignores or restricts the access, at a mud-wide level, everything

coming in over IMC for a specified player or group of players. Currently

two possible actions are possible: ignore and notrust.


Ignore means:


- rtells/rbeeps/rwhos will be ignored, and a rtell sent back to say that the

  mud is ignoring them.

- no messages from them on rchat, rcode, etc will appear on your mud.


Notrust means:


- any rwho/rfinger/etc requests from a mud/player matching the pattern will

  be treated as if they were from a level 1 mortal - ie. wizi imms will never

  be revealed on rwho, and rtells won't see them, etc.

- any incoming channel messages from something matching the pattern are

  stripped of wizi status - they will be visible to everyone in general.


Patterns can be one of:


  player@mud              - matches a specific player at a specific mud

  *suffix                 - matches anything ending with that suffix

                            (commonly used as *@mud)

  prefix*                 - matches anything beginning with that prefix

                            (for example, player@*)

  *substring*             - matches anything containing that substring


Use with care.


See also: IMC 'IMC IMMORTAL COMMANDS'

~
0 MAILQUEUE~
Syntax:  mailqueue                         - show current IMC mailqueue


This command simply shows the current contents of the outgoing IMC mailqueue

for inter-mud notes. Due to the internal implementation of this (static

buffers - ick), only the first 8-9 entries will be shown.


See also: IMC 'IMC IMMORTAL COMMANDS' 'IMC NOTES'

~
0 RCHANSET~
Syntax:  chanset <player>             - see a players current IMC flags

         chanset <player> +<channel>  - set 'allow' flag on a player

         chanset <player> -<channel>  - set 'deny' flag on a player

         chanset <player> =<channel>  - reset allow/deny flags on a player


This command allows you to view or change a players IMC channel priviliges.

In all cases <channel> can be the name of an IMC channel (rchat, rcode, etc)

or 'rtell' or 'rbeep'.


Setting the allow flag for a channel allows that player to see and use that

channel, regardless of their level. This can be used, for example, to give

mortals with coding experience access to rcode.


Setting the deny flag for a channel prevents that player from using or

seeing that channel, even if their level normally allows them to. This can be

used as a penalty for players who abuse the IMC channels or rtell/rbeep.


Resetting the allow/deny flags simply clears them, using only the player's

level to determing whether they can use the channel.


See also: IMC 'IMC IMMORTAL COMMANDS' RCHAT RCODE RIMM RINFO

~
0 'IMC CONFIG'~
The 'imc' command is used to configure your IMC setup:


Syntax:  imc add <mudname>            - add a new IMC connection entry

         imc set <...>                - set the details of an IMC connection

         imc delete <mudname>         - remove an IMC connection

         imc rename <old> <new>       - rename an IMC connection

         imc reload                   - load a new IMC config file from disk

         imc localname <name>         - set the local IMC name

         imc localport <port>         - set the local IMC port


Add, delete, and rename should be self-explanatory. The name of an IMC

connection MUST match the name which the other end is using.


Reload destroys the version of the configuration in memory, and reloads it

from disk. This is useful if you have hand-edited the config file and want

to load your changes without rebooting. 'imc reload' also reloads the

rignores file.


The set command has several forms:


imc set <mudname> all <data...>     - set all values for a mud

                  host <hostname>   - set the hostname to connect to

                  port <portnum>    - set the remote IMC port to connect to

                  clientpw <pw>     - set the case-sensitive client password

                  serverpw <pw>     - set the case-sensitive server password

                  rcvstamp <value>  - set the receivestamp

                  noforward <value> - set the noforward bitmask

                  flags <value>     - set the connection flags


The 'all' form takes a series of values:


imc set <mudname> all <host> <port> <clientpw> <serverpw> <rcvstamp>

                      <noforward> <flags>


For information on the exact details of each field, see the IMC documentation.


The localname and localport commands set the IMC name and port of -your- mud.

Use with care.


See also: IMC 'IMC IMMORTAL COMMANDS'

~
-1 ICE~
ICE - the IMC Channel Extensions protocol


ICE is a response to the cesspool-like attributes that rchat, rimm, and

even rcode have acquired over the last few months. It is IRC-ish in some

ways, but hopefully it will be used more constructively than IRC.


For a quick introduction and setup guide for ICE, see ICE-INTRO


The basic ICE structure is (greatly simplified):


. Some nodes on IMC - normally hubs - run channel daemon code that

  manages channels

. Each of these nodes maintains a list of the channels they manage, and

  the various attributes of them - who owns them, and so on

. The daemons regularly tell all muds on IMC what channels they have, and

  what their attributes are

. Based on this information, the muds on IMC decide which of their local

  users can use which ICE channels. If one mud is modified to ignore these

  restrictions, then the other muds will recognize this (since they, too,

  know the restrictions) and ignore messages from that mud.


Every channel on ICE is of the form nodename:channelname, for example a

channel called hub2:IAdmin is the channel IAdmin maintained by the node hub2.

Each mud picks which channels it is interested in (see ILIST and

ISETUP) and creates a local channel name which can be used to talk on

that channel.


Generally, any admin on a mud can create a channel on any node - although

nodes can be configured to restrict who can create channels. Whoever

creates a channel owns it, and can control who can use that channel (in

whatever way they wish). The trick, of course, is to persuade the admins

of other muds that your channel has value. Creating and modifying a

channel is done via the ICOMMAND command.


Channels can be tuned into and out of on a player-by-player basis by

using the ICHAN command.


There are a variety of ways of controlling who can hear and use a channel

- see ICE-POLICY for more information.


See also: IMC ILIST ISETUP ICOMMAND ICHAN ICE-POLICY ICE-INTRO

~
-1 ICE-INTRO~
A Quick Introduction to ICE


This assumes that the code for IMC and ICE is installed and running, and

that you have an active connection to an IMC network.


1. ILIST. This will give you a list of possible channels to choose from.

   Pick one that you want to add, that has a policy of 'open'. Note its

   name (of the form node:channel).


2. Decide what command you want to use to speak on this channel on your

   mud. This is the channel's localname.


3. Type: ISETUP ADD <node:channel> <localname>


4. You should now be able to use the channel. Others can listen to and

   speak on the channel by using ICHAN <localname>.


5. You may wish to reconfigure the default local channel settings.

   ILIST <localname> will display them; ISETUP will change them.


6. Repeat for whatever other channels you wish to have.


See also: IMC ICE ISETUP ICOMMAND ICHAN ILIST

~
0 ICHAN~
Syntax:  ichan               - display current ICE channel status

         ichan <localname>   - toggle an ICE channel


IChan lets you show and toggle which ICE channels you are listening

to. Without arguments, it will show you the channels you belog to; with

an argument, it will turn on or off that channel.


Any channels you listen to must be locally configured first - see

ISETUP. ILIST can be used to see available channels.


See also: IMC ICE ILIST ISETUP

~
0 ICOMMAND~
Syntax:          icommand <command> <channel> [<data..>]

Common commands:  create <channel>           - create a channel

                  refresh <channel>          - refresh channel data

                  list [<channel>]           - list available commands

                  destroy <channel>          - destroy a channel

                  policy <channel> <policy>  - change channel policy

                  addop <channel> <name>     - add a channel operator

                  removeop <channel> <name>  - remove an operator

                  invite <channel> <name>    - add an invited name

                  uninvite <channel> <name>  - remove an invited name

                  exclude <channel> <name>   - exclude a name

                  unexclude <channel> <name> - remove an exclusion


ICommand is used to send commands to a channel daemon elsewhere on IMC.

It directly affects the channel itself - any changes made here will

affect all muds using the channel.


Since the actual commands are interpreted by the channel daemon, not your

mud, what is available may vary. To get a list of available commands, use

icommand list <nodename> for public commands, or icommand list

<node:channel> to see what commands you have for that channel.


icommand refresh asks the daemon to refresh your mud's information for a

channel, if it ever gets out of synx. Asking for a refresh of nodename:*

will refresh all channels on that daemon.


icommand create creates a new channel, with you as the owner

icommand destroy destroys a channel. You must own the channel.


icommand policy changes the basic policy of the channel (see ICE-POLICY).

You must be the owner.


icommand addop/removeop add and remove operators from a channel. You must

be the owner, and specify the operator's full user@mud name.


icommand invite/uninvite/exclude/unexcluded modify the invite and exclude

lists for a channel. You must be the owner or an operator on the channel.

Either a full user@mud or a simple 'mud' name (no @) can be specified.

See ICE-POLICY for more details.


See also: IMC ICE ICE-POLICY

~
0 ISETUP~
Syntax: isetup add <ice-channel> <localname>   - add a channel

        isetup delete <localname>              - delete a channel

        isetup rename <oldname> <newname>      - rename a channel

        isetup format1 <localname> <format>    - change format1 on a channel

        isetup format2 <localname> <format>    - change format2 on a channel

        isetup level <localname> <level>       - set channel level


ISetup allows you to change the local configuration of an ICE

channel. None of these commands have a lasting effect on the channel's

configuration on other muds.


ISetup add begins the configuration of a channel. It connects the

specified ice-channel (of the form nodename:channelname) to a local name.

For example: isetup add hub2:IAdmin IAdmin. The local name is also the

command used to speak on the channel.


When the channel is added, various default values are filled in for

format1, format2, and level.


ISetup delete removes this link. It does not affect the channel itself;

it just deletes the local configuration link for the channel.


ISetup rename changes the local name of a channel. It does not affect the

channel name itself for other muds - just the command used locally to

access it.


ISetup format1 and format2 change how a channel is displayed locally.

Each format string must have exactly two %s's within it (this is checked

for) - the first will be replaced by the speaker's name, the second by

whatever they say. Format1 is used for normal speech, format2 for emotes.

See ILIST for more information.


ISetup level sets the minimum level necessary on your mud to hear or use

the channel.


See also: IMC ICE ILIST

~
0 ILIST~
Syntax:  ilist               - list all known ICE channels

         ilist <channel>     - list details on one ICE channel


IList displays information on channels active on ICE.

Without arguments, it will produce a display similar to:


Name            Local name      Owner           Policy

hub2:IAdmin     IAdmin          Nemon@AR        open

hub2:ICode      ICode                                    (inactive)

hub2:test       (not local)     Nemon@ARtest    private


This shows the canonical name (eg. hub2:IAdmin), the local name (eg IAdmin

- which can be used as an abbreviation in ISETUP, and which is also

the command to speak on that channel), the owner of the channel (eg.

Nemon@AR), and the channel's policy (see ICE-POLICY).


If a channel is not configured locally, it will have (not local) for its

local name.


If a channel is configured locally, but is not actually active on IMC, it

will have an (inactive) flag on it.


IList with a channel name will provide detailed information on that

channel. For example:


Channel hub2:IAdmin:

  Local name: IAdmin

  Format 1:   (IAdmin) %s: %s

  Format 2:   (IAdmin) %s %s

  Level:      102


  Policy:     open

  Owner:      Nemon@AR

  Operators:  Drylock@AR

  Invited:    NiceGuy@SomeMud

  Excluded:   SomeMud


This displays the channel name, local name, policy, and owner, as above. It

also displays:


- the minimum level needed on your mud to see the channel


- the format for displaying messages from the channel. These can contain

  any color codes etc. that your mud uses.


  Format1 is the string displayed when someone speaks normally on the

  channel - the first %s is replaced by their name, the second %s by what

  they say.


  Format2 is a similar string for emotes. Again the first %s is their name,

  the second %s the text of their emote.


- any operators for the channel. This can only be changed by the owner of

  the channel. Operators can modify the 'invited' and 'excluded' fields

  via the ISETUP command.


- the invited and excluded people on the channel. See ICE-POLICY for

  more details.


See also: IMC ICE ISETUP ICOMMAND ICE-POLICY

~
-1 ICE-POLICY~
ICE Channel Policies


Channels can have one of three policies - open, closed, and private. They

also have one owner, and zero or more operators (assigned by the owner).

They also have an include and exclude list (which can specify both

individual players ['user@mud'] and entire muds ['mud']), which can be

modified by the owner and the operators.


- Open. The channel can be accessed by all muds on the network (it is a

  broadcast channel). People on the exclude list cannot use the channel,

  with the exception of people also on the invite list. This means, for

  example, if an entire mud is excluded and one player is invited, that

  player can use the channel, but the rest of the mud can't.


- Closed. The channel can be accessed by all muds on the network (it is a

  broadcast channel), but by default they will not hear or be able to use

  it. People on the invite list can use the channel, with the exception of

  people also on the exclude list.


- Private. Identical to closed, except that the channel is actually only

  physically sent to those muds that are on the invite list. This is good

  for channels specific to a small group of muds, and not of interest to

  the majority of the network.


See also: IMC ICE ICOMMAND

~
-1 IMC~
IMC (Inter-Mud Communication) provides a way for muds to connect together and

share various services: chat channels, tells, notes, who listings, and so on.


The available mortal-level IMC commands are as follows. See the help topics

for each of these for more information.


- IMCLIST : get a list of active muds that are connected to IMC.

- RCHAT   : send a message on the common chat channel.

- RWHO    : send a who request to a mud.

- RTELL   : send a tell to someone on another mud.

- RREPLY  : reply to a rtell from someone on another mud.

- RQUERY  : ask for information of some type from another mud.

- RBEEP   : "beep" another player. Use sparingly.

- RWHOIS  : find someone on IMC

- RFINGER : get information about a player on another mud

- ISTATS  : get some (interesting?) stats about IMC.

- RCHAN   : show which channels you are listening to, and modify that state.


There is also provision for inter-mud notes/mail; see 'IMC NOTES'.


IMC2 was written by Oliver Jowett <oliver@sa-search.massey.ac.nz>, aka

Spectrum. Mail me if you're interested in connecting to the IMC network.

The source code is available at ftp://sa-search.massey.ac.nz/pub/mud/imc2/

The IMC2 home page is at http://sa-search.massey.ac.nz/-oliver/imc2/

(- = tilde)

~
0 IMCLIST~
Syntax:  imclist                  - get a list of active muds on IMC

         imclist direct           - get a list of directly connected muds

         imclist config           - see the local IMC config


'imclist' lists active muds on IMC. It lists all the muds which this mud knows

about on the IMC network, and when they were last heard from. The 'route'

section is mainly for diagnostics, and indicates the route that your mud will

send packets via to get to another mud.


'imclist direct' shows direct connections from your mud to other muds.


'imclist config' shows the local IMC configuration and state.


See also: IMC RQUERY

~
0 RCHAT RIMM RCODE~
These channels are obselete, use ICE instead.

~
0 RWHO~
Syntax:  rwho <mudname>               - ask for a who listing from another mud


'rwho' asks the given mud for a 'who' listing of its current players. Depending

on the network, it may take several seconds to get a response. You should use

the mud abbreviation listed in 'imclist' when issuing a rwho.


See also: IMC IMCLIST RQUERY RWHOIS

~
0 RWHOIS~
Syntax:  rwhois <playername>          - find a player on IMC


'rwhois' asks all muds on IMC for a player with the given name. You should not

include a @mudname section - just the playername. Replies will be returned

from those muds who have a player by that name connected.


See also: IMC RWHO RFINGER

~
0 RFINGER~
Syntax:  rfinger <player@mudname>     - get information about a player


'rfinger' asks the specified mud for information about the specified player.

The information you will get back (and even its existance) depends on the

remote mud, but will typically give at least their last login time.


See also: IMC RWHO RWHOIS

~
0 RTELL RREPLY~
Syntax:  rtell <player@mudname> <message>    - send a 'tell' to another player

         rreply <message>                    - send a 'tell' to the last player

                                               to send you a rtell


rtell and rreply are the IMC equivalents of tell and reply, and work nearly

identically. To rtell, however, you need to supply both a playername and a

mudname (as shown in 'imclist'). rreply will reply to the last rtell you

received from a player - even if that player was invisible to you.


See also: IMC IMCLIST

~
0 RQUERY~
Syntax:  rquery <mudname> help         - ask for available rquery options

         rquery <mudname> <option>     - ask for information from a mud


RQuery is similar to rwho, except it requests different information from a

mud. Each mud differs in what information it supplies, but 'rquery <mudname>

help' will give you a list of options that you can ask for.


Typically at least the following are supported:


rquery <mud> who        - ask for a who listing, identical to 'rwho'

rquery <mud> info       - get general information on the mud, usually including

                          its address. This is the preferred way of finding

                          out the address of a mud on IMC - don't ask on rchat!

rquery <mud> list       - ask for a list of IMC connections, from that mud's

                          point of view. Identical to 'imclist' on the remote

                          mud.

rquery <mud> istats     - ask for some IMC statistics, identical to 'istats' on

                          the remote mud.


See also: IMC IMCLIST RWHO

~
0 RBEEP~
Syntax:  rbeep <player@mudname>     - "beep" a player over IMC


rbeep sends an audible beep to another player on another mud (the @mudname

part indicates which mud; see 'imclist'). Note that this should only be done

when you _really_ need to get their attention; abusing rbeep will usually

lead to your IMC priviliges being revoked.


See also: IMC IMCLIST

~
0 ISTATS~
Syntax:  istats                     - display use(less?) statistics


istats shows some (maybe :) interesting statistics about how much traffic your

mud is generating due to IMC.


See also: IMC IMCLIST RQUERY

~
0 RCHANNELS RCHAN RINVIS~
Syntax:  rchannels                  - display your current IMC channel state

         rchannels +<channel>       - turn on an IMC channel

         rchannels -<channel>       - turn off an IMC channel


rchannels on its own will show you which IMC channels you have access to, and

whether they are currently on or off.


rchannels with an argument will turn on or off a given IMC channel that you

have access to.


rchannels can also be used to block rtells and rbeeps if necessary.


One additional option is rinvis. rchannels +rinvis will make you totally

invisible to IMC: you cannot be contacted by rtell, rreply, or rbeep, and

you do not appear on rwho. However, you cannot use any IMC channels while

rinvis is active (you can still hear them, though). rchannels -rinvis will

reverse this state.


Immortals may allow you access to IMC channels, or revoke your access to 

them, as necessary.


See also: IMC RCHAT RBEEP RTELL

~
-1 'IMC NOTES'~
Notes (boards, mail, etc) are very mud-dependent, but in general, if they

have been connected to IMC, then you can simply write notes to player@mudname

in addition to normal 'player'.


For example, you may be able to do:


note to abcde@somemud anotherplayer immortal@someothermud


and the note would go to:

  abcde on the mud called 'somemud'

  anotherplayer on your mud

  all immortals on the mud called 'someothermud'


The 'playernames' used are interpreted by the mud that receives them, not

your mud, so be careful when writing notes to group names such as 'immortal'.


If your note cannot be delivered within 12 hours for some reason (if the

mud is down, does not exist, or refused your mail) then you will get a note

from the system telling you so.


See also: IMC

~
-1 'IMC IMMORTAL COMMANDS' RINFO~
IMC Immortal commands:


- RINFO       : A channel which the various hubs put status reports onto. Can

                be spammy at times; you may want to turn off rinfo for this

                reason.

- RSOCKETS    : displays debugging info on the current IMC connection state.

- RCONNECT    : force a connection to a directly connected mud.

- RDISCONNECT : forcibly disconnect a directly connected mud.

- RIGNORE     : ignore a player or an entire mud on IMC.

- MAILQUEUE   : show the current queue of pending inter-mud notes.

- IMC         : edit the IMC configuration for your mud (see 'IMC CONFIG')

- RCHANSET    : manage access to IMC channels/rtell/rbeep for players.

- RPING       : trace IMC connectivity


See also: IMC

~
0 RSOCKETS~
Syntax:  rsockets                   - display IMC socket usage


rsockets displays the current connection state for the direct IMC connections

that your mud has. The various fields are:


Desc  : the system-level descriptor used for this connection


Mud   : which mud this connection is for


State : how far through the connection process this connection is:

        - connecting: waiting for the other end to accept our TCP connection

        - wait1:      waiting for the password from an incoming client

        - wait2:      waiting for the server to respond to our password

        - connected:  the connection is completely 'up'


Inbuf : the size of data waiting in the input and output queues for this

Outbuf: connection.


Spam1 : spam-protection counters

Spam2 :


See also: IMC 'IMC IMMORTAL COMMANDS'

~
0 RCONNECT~
Syntax:  rconnect <mudname>                - start an IMC connection


rconnect will initiate a connection to the given mud. Note that this has to

be a _directly_ connected mud (ie. a mud in the first section of imclist).

Feedback on the state of the connection will be logged to 'wiznet imc', and 

you may want to check imclist to see if it was successful.


See also: IMC 'IMC IMMORTAL' RDISCONNECT

~
0 RDISCONNECT~
Syntax:  rdisconnect <mudname>             - terminate an IMC connection


rdisconnect reverses rconnect, severing all connections to the named mud.


See also: IMC 'IMC IMMORTAL COMMANDS' RCONNECT

~
0 RIGNORE~
Syntax:  rignore                           - list current rignores

         rignore ignore  <pattern>         - ignore player(s) or mud(s)

         rignore notrust <pattern>         - don't trust player(s) or mud(s)

	 rignore delete  <pattern>         - remove a rignore


rignore ignores or restricts the access, at a mud-wide level, everything

coming in over IMC for a specified player or group of players. Currently

two possible actions are possible: ignore and notrust.


Ignore means:


- rtells/rbeeps/rwhos will be ignored, and a rtell sent back to say that the

  mud is ignoring them.

- no messages from them on rchat, rcode, etc will appear on your mud.


Notrust means:


- any rwho/rfinger/etc requests from a mud/player matching the pattern will

  be treated as if they were from a level 1 mortal - ie. wizi imms will never

  be revealed on rwho, and rtells won't see them, etc.

- any incoming channel messages from something matching the pattern are

  stripped of wizi status - they will be visible to everyone in general.


Patterns can be one of:


  player@mud              - matches a specific player at a specific mud

  *suffix                 - matches anything ending with that suffix

                            (commonly used as *@mud)

  prefix*                 - matches anything beginning with that prefix

                            (for example, player@*)

  *substring*             - matches anything containing that substring


Use with care.


See also: IMC 'IMC IMMORTAL COMMANDS'

~
0 MAILQUEUE~
Syntax:  mailqueue                         - show current IMC mailqueue


This command simply shows the current contents of the outgoing IMC mailqueue

for inter-mud notes. Due to the internal implementation of this (static

buffers - ick), only the first 8-9 entries will be shown.


See also: IMC 'IMC IMMORTAL COMMANDS' 'IMC NOTES'

~
0 RCHANSET~
Syntax:  chanset <player>             - see a players current IMC flags

         chanset <player> +<channel>  - set 'allow' flag on a player

         chanset <player> -<channel>  - set 'deny' flag on a player

         chanset <player> =<channel>  - reset allow/deny flags on a player


This command allows you to view or change a players IMC channel priviliges.

In all cases <channel> can be the name of an IMC channel (rchat, rcode, etc)

or 'rtell' or 'rbeep'.


Setting the allow flag for a channel allows that player to see and use that

channel, regardless of their level. This can be used, for example, to give

mortals with coding experience access to rcode.


Setting the deny flag for a channel prevents that player from using or

seeing that channel, even if their level normally allows them to. This can be

used as a penalty for players who abuse the IMC channels or rtell/rbeep.


Resetting the allow/deny flags simply clears them, using only the player's

level to determing whether they can use the channel.


See also: IMC 'IMC IMMORTAL COMMANDS' RCHAT RCODE RIMM RINFO

~
0 'IMC CONFIG'~
The 'imc' command is used to configure your IMC setup:


Syntax:  imc add <mudname>            - add a new IMC connection entry

         imc set <...>                - set the details of an IMC connection

         imc delete <mudname>         - remove an IMC connection

         imc rename <old> <new>       - rename an IMC connection

         imc reload                   - load a new IMC config file from disk

         imc localname <name>         - set the local IMC name

         imc localport <port>         - set the local IMC port


Add, delete, and rename should be self-explanatory. The name of an IMC

connection MUST match the name which the other end is using.


Reload destroys the version of the configuration in memory, and reloads it

from disk. This is useful if you have hand-edited the config file and want

to load your changes without rebooting. 'imc reload' also reloads the

rignores file.


The set command has several forms:


imc set <mudname> all <data...>     - set all values for a mud

                  host <hostname>   - set the hostname to connect to

                  port <portnum>    - set the remote IMC port to connect to

                  clientpw <pw>     - set the case-sensitive client password

                  serverpw <pw>     - set the case-sensitive server password

                  rcvstamp <value>  - set the receivestamp

                  noforward <value> - set the noforward bitmask

                  flags <value>     - set the connection flags


The 'all' form takes a series of values:


imc set <mudname> all <host> <port> <clientpw> <serverpw> <rcvstamp>

                      <noforward> <flags>


For information on the exact details of each field, see the IMC documentation.


The localname and localport commands set the IMC name and port of -your- mud.

Use with care.


See also: IMC 'IMC IMMORTAL COMMANDS'

~
-1 money coin coins currency~
@@bcopper@@N Bit : base unit

@@Wsilver@@N Moon:  5 bits

@@ygold@@N Crown : 20 bits

@@lelectrum@@N Crescent : 50 bits

@@amithril@@N Pentacle : 100 bits

@@mmalachite@@N Karant : 200 bits

@@debony@@N Mark : 500 bits

@@pRoyal Sunburst@@N : 1000 bits  

~
-1 diku~
.                    Original game idea, concept, and design:

          Katja Nyboe               [Superwoman] (katz@freja.diku.dk)

          Tom Madsen              [Stormbringer] (noop@freja.diku.dk)

          Hans Henrik Staerfeldt           [God] (bombman@freja.diku.dk)

          Michael Seifert                 [Papi] (seifert@freja.diku.dk)

          Sebastian Hammer               [Quinn] (quinn@freja.diku.dk)

                     Additional contributions from:

Michael Curran  - the player title collection and additional locations.

Ragnar Loenn    - the bulletin board.

Bill Wisner     - for being the first to successfully port the game,

                  uncovering several old bugs, uh, inconsistencies,

                  in the process.

And: Mads Haar and Stephan Dahl for additional locations.

Developed at: DIKU -- The Department of Computer Science

                      at the University of Copenhagen.

~
-1 ack ackmud~
@@N-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-

@@k)

)@@N

         Ack!Mud 2.0 is Copyright (C)1995/6 Stimpy & Thalen

         Ack!Mud 4.3 is Copyright (C)1998 by Stephen Zepp

@@k)@@N

            Ack!Mud 4.3 by Zenithar, with mucho help from:

             Ramias, Altrag, Spectrum, Flar, and Universe

@@k)@@N

 Ack! Mud is a deriative of Merc Muds, which are deriatives of Diku Muds.

 In order to run this code, you must observe the conditions of use

 of Merc and Diku.

@@k)@@N

 Conditions of use for Ack!Mud are as follows:

 - Must retain copyright messages in all code.

 - Stimpy, Thalen and Zenithar must be credited on greeting screen.

@@k)@@N

 Thanks to:

 ...Maharet, Requiem and Rupert from the original Ack! for all their help.

 ...SoE for provding the official site for Ack!Mud

 ...The guys&gals at Diku and Merc for writing the original code  (:

        To contact Zenithar, E-Mail zenithar@ackmud.nuc.net

@@k)@@N

                   Visit the Ack!Mud Home page at:

                      http://ackmud.nuc.net

@@k)@@N

-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- 

~
-1 ack~
NEW HELP.  DELETE THIS LINE FIRST!~
0 $~
#ROOMS
#32766
New room~
This is a desc\brthis is only a desc

this shouldnt be wrapped

\brthis should

\br

hmm

~
4 11
S
#0
#OBJECTS
#32700
tester~
~
~
1 0 12582912 1
0 0 0 0 0 0 0 0 0 0
1
L
1
#0
#$