MCM - MultiUser Communications Manager Version 1.2 ------------------------------------------------------------------------ Copyright (C) 1991,2 Michael Sawyer (msawyer@soest.hawaii.edu) The program may be redistributed in its unmodified form, provided there is no charge for the program beyond normal distribution costs. If you wish to distribute modified versions of this code, please send patches to me to be included in the standard release. I would like to avoid having many different versions available besides the distribution version. At this point, I am planning on uploading all updates to tybalt.caltech.edu, pending their approval. Personality modules for this software are the property of their respective authors, who control all rights to redistribution. Included modules may be distributed with no limitations. ------------------------------------------------------------------------ The author assumes no liability for any damages caused by this software. Although all efforts have been made to assure that there are no security holes, use this program at your own risk. Please report any bugs to msawyer@soest.hawaii.edu as soon as found for corrections, and watch rec.games.frp.announce for update announcements. ------------------------------------------------------------------------ 1. Purpose MCM is intended as a conference server for small groups needing to participate in online real-time meetings. Unlike IRC, MCM is NOT intended to be placed online, and left running for people to wander in and out finding different rooms available. MCM has only one room, but allows the operator (room leader) much greater control over activities within that room. Also, a number of special features have been set up for various groups interested in this service. For example, a flexible dice-rolling system is provided for people interested in online gaming. MCM does not require any special programs on the client side for normal operation, although it has been tested with a few common IRC/MUD clients. Using the normal Telnet program, users are able to get a functional split-screen mode (with seperate input and output windows) on any termcap-supported terminal (using the termcap on the server machine). Once you have built the executable code for MCM, you will need to setup directories for the various "rooms" (ports) which may be used. If you are going to, for example, run MCM on port 7000, type setup_mcm 7000 This will create a subdirectory under your home directory named mcm, place a directory in that directory named 7000, and place a number of control files in this directory. These files are described below, and may be edited to your taste. The operation of the MCM server can be completly changed through the use of "personality modules," allowing the operator to build additional code customizing MCM for the particular use. Two sample modules, and one third-party macro-processing modules are included with this distribution. 2. Compilation Simply type "make". It should be generic enough to compile on anything. If you have trouble, feel free to send me mail asking for help. (msawyer@soest.hawaii.edu) This program has only been tested under SunOS (Solaris) and Ultrix at this time. You may modify the mcm.h file to make slight changes to suit your tastes. There are many docs in that file for the customization options, but no changes should be necessary. However, if you have trouble compiling or running the program, you may need to make changes to some of the configuration options. In particular, many compilers don't like bitfields, which may be disabled by way of the BADBITS flag in mcm.h 3. Operation To start the server, you will first need to select a InterNet port number to use for the communications. Typically, using ports in the 7000 to 9000 range are safest, as others can be used by various other programs. You will not be able to bind to a port already used by another program, so error messages such as "port already in use" simply mean that you need to select a different port. (Note that 6000 is often used by X servers, so you should not use this port.) The Unix command "netstat -a" will show all ports in use on your system. Once you have selected a port, simply type mcm (portnumber) & to start the server. You will, however, have to have a number of files in the current directory for the server to function correctly. Most importantly, you will need the "mcm-accts" file to define the valid users on the server. A sample mcm-accts file is provide, and its format is as follows: user:password:email address:extra information Note that you MUST provide a value for all four fields in this file, and there should be no blank lines in the file. Comment lines may be used by placing a # sign in the first column. If you wish to leave some fields unused, simply place a star (*) in the first column of the file. In the user field, this will evaluate as any users not yet matched; in the password field, this will evaluate as no password needed, so the line *:*:*:* will allow any users (with names which do not match earlier names in the file) to log in without a password, e-mail address, or other information. If the username starts with a slash character (/), this user is authorised to use the room-leader commands. Note that the users should NOT type the slash when logging in. The file mcm-welcome is displayed before the Name: prompt when users connect to the MCM server. It can be used to identify the server, or provide any other important information. The file mcm-hello is used as a welcoming banner to users once logged into the system. The files mcm-help* are used for the various online halp facilities, and should be used as provided (but may be changed by the operator). The files mcm-log and master-log are genetared by the mcm program, and include a public-message-only log (the former) and a room-leader's log (the latter). The files mcm.* may be typed by the room-leader during online sessions, and should be no longer than 30 lines in length. To connect to the server (with the telnet program), simnply type telnet (hostname) (portnumber) from a Unix system, or telnet (hostname) /PORT=(portnumber) from VMS machines. (Although the server won't compile under VMS, users can connect to it from VMS sites, although VMS does NOT follow all telnet negotiation protocols.) Users then log in with their username (and if needed, password) at the appropriate prompts. The command "/?" will show the users a list of available commands on the system. Room leaders should use the "*+" command to "become" the active room leader. Once enabled as the active leader, "*?" will list available room-leader commands. The available options for the normal users are: /E Exit the system. This is fairly self-explanatory. /H Get help with the various commands. This will print the file "mcm-help" to the user. /H x Similar to above, this will print the file "mcm-help-x" to the user, allowing you to provide detailed help on various topics. /L Re-login with a different name. This is just like exiting and then logging back in. /R Roll dice. For example, /R1D6+1 will roll 1 six sided dice with a +1 modifier (ie: from 2 to 7). /R alone will roll 1D6, /R3 will roll 3D6, /RD4 will roll 1D4. /P Just like /R, but the results will only be seen by the room leader and the person who rolled the dice. /S Send a private message. For example, typing "/S2 Hello" will send a private message to whoever is logged into job 2 (as identified with the /W command) containing the text Hello. /T Set terminal type. This is used by the split-screen mode to determine what type of terminal control codes to use. The selected terminal should be in the termcap (or terminfo) file on your system. Common terminals, such as VT100, are found on nearly all Unix systems. /V Get the version number of the server. /W List who is online. This will also give you their E-Mail address (if found in the account file) and whatever extra information is provided. Commands available to the room leader are: *D This command will put a short message on the "door" of the room. For example, "*D Welcome" will put the text "Welcome" on the door for all new users to see. *E! This command will shut down the server, and should only be used when done with a session. *+ Use this command to start being the active room leader, allowing you to use the other * commands. It can olny be used by authorized users. *- Use this command to quit being the room leader. If you are not the active room leader when you issue this command, you will "kick out" whoever is the room leader. Only authorized users can use this command. *K This command will force a user to log out. It can be used to get rid of disruptive users, or users whose terminal has gone haywire. *T This command will type a file for all users to see. The file should be pre-loaded into the mcm directory, with the name "mcm.file", so if you issue the command "*T sample", you would display the file "mcm.sample" to all users. Note that to prevent accidental output of long files faster than users can read them, only the first 30 lines are printed. *G+ "Gag" a user, so any messages from that user are only seen by the room leader. "*G+3" would gag job 3, and "*G+*" will gag all users. *G- This is the opposite of the gag command, and releases the gag on users. *L This command puts the room in listen-only mode, where only the room leader can "speak". Only the room leader will see messages entered by other users. You may optionally put a job number after the command to give that user the floor, so the command "*L5" will allow only job 5 and the room leader to speak. *O This will open the floor to general discussion, allowing all users to speak. It is used to "undo" the *L command. *C This command is followed by a list of jobs to be taken into private confernce with the room leader. Depending on the mode settings, these users may or may not be able to "hear" messages from outside of conference and/or speak to users out of conference. If enabled, users in conference can preceed text with a tilde "~" character to speak out of conference. *C alone will clear the conference room and continue as normal. *A This command will allow you to select an assistant room leader, with most of the abilities of the room leader. This can be used if a part is split into two groups, with the room leader running the game in *C, and the assistant outside (as an option). *M This command is used to set various system modes. *M alone will list the current modes. Valid modes are: *MD Setting this on (*MD+) will enable the "default gag" mode, where new users entering are by automatically gagged. *MT Setting this mode on will allow users in conference to talk to users out of conference either thorough private sends or the ~ command mentioned above. *MH Setting this mode on allows users in conference to hear the conversation outside, and to recieve private sends from users not in conference. *MS Enabling this mode allows the room leader (as well as the master-log file) to recieve (snoop) all private messages between other users. 4. Personality Modules With release 1.2, the concept of personality modules was introduced to MCM. With these modules, you can literally change the entire operation of the server, as all major functions have hooks into the personality modules. For detailed information on how to program personality modules, look at any of the included modules, which include comments detailing how to write the module. Note that you will have to know how to program in C to write these modules. The following modules are included with this release (1.2): dd *D&D module (as a sample module) sr ShadowRun dice re-rolling example hop Hopcraft's Macro-based module (in a seperate tar file) To build the distribution with one of the optional modules, all you need to do is type make So, to build MCM with the "hop" module, you should type make hop Note that you can include only module in any compilation. Any modules you write are your code, and may be distributed as you see fit. However, if you will mail me a copy (msawyer@soest.hawaii.edu), I will try to include your file in the next release of the MCM software. I am interested in hearing your experiences with the personality modules, in particular if you work on anything unusual. Also, if you have any problems with the system as it is, please let me know. ---- THANKS! I would like to thank Steve Kramarsky's Shadowrun group for testing the server, and especially Richard Pieri for helping me find lots of bugs in the code! "Just James" (at Duke University) provided a few new options (/c, /j, and /n) which weren't in my versions, as well as a few suggestions for new things in the code. Geoffery Hopcraft helped find some of the problems in the personality system, as well as write the first real personality module for the system.