|
What Hardware and Software Do I Need to Run a MOO? |
At this time, the only commonly used Server is the LambdaMOO Server. This software was originally developed by Stephen White, then developed for many years by Pavel Curtis, who has recently passed on the development of the Server to Erik Ostrom. In addition, many other people have contributed code to the primary developers, some of which has been subsequently incorporated into the Server. The Server has thus been developed as a community effort, led at any one time by a single person who ends up writing most of the improved Server code, and also decides which features and code donations will be incorporated in subsequent Server versions.
In addition to the MOO Server, you will need an existing Database, containing at least the core systems and object templates needed to start building. When starting a MOO, one almost always uses a MOO "core" Database, which is one that has not yet been customized by the creation of rooms, characters, or other objects, but only has their templates (i.e. the "generic" versions of such objects). A MOO core is essentially an empty place, typically with a single starting room, within which you will build your VR world. A MOO core is created by extracting out the essential parts (or destroying all the non-essential parts) of an existing MOO. For this reason, nearly all MOO cores are actually derived from an operating MOO world, and you can often visit the MOO world that the core was derived from to gain some idea of the type of place it is. Several MOO cores are available (these are described elsewhere), each reflecting the philosophies and needs of the MOOs from which they were derived.
In addition to the software needed to run the MOO itself, you will greatly benefit from using a dedicated MUD/MOO client for connecting to the MOO. Many are available for every common operating system, and people each have their own preferences. Summaries and descriptions of some popular MUD/MOO clients are described in another text.
Note that many MOO administrators using UNIX systems apply one or more patches to the source code before compiling, to modify the capabilities of the Server. Several commonly used patches are publically available, and can provide very useful features such as access from the MOO to the computer's file system, or access to the UNIX timezone functions. Since the Win95/NT and MacOS versions of the LambdaMOO Server come precompiled, you generally don't have the option of including patches if you use one of these two versions. However, the MacOS version accepts "plug-ins" and if a patch is available in the form of a plug-in, you may be able to use the patch through that mechanism. In addition, versions of the Win95/NT Server may become available with popular patches compiled in. You should check the Web pages for the Win95/NT and the MacOS versions of the LambdaMOO Server for more information.
The following table presents the systems on which the current version of the UNIX LambdaMOO Server has been tested by the developer, and is taken from the README file that comes with the LambdaMOO 1.8.0 Server. Note that it is not a complete list of the UNIX varients for which the LambdaMOO Server can be compiled, but only those that were specifically tested by the developer. The MOO will compile fairly easily on most common UNIX systems, although adjustments to the compilation parameters are sometimes needed.
Machines On Which Version 1.8.0 of the LambdaMOO Server Was Tested
| Hardware | Operating System(s) | Compiler |
| Sun 4/SPARC | SunOS 4.1.3, 5.5 | GCC |
| SGI Iris | IRIX 5.3 | Vendor's |
| DEC Alpha | DEC OSF/1 V3.2 | Vendor's |
| Intel x86 | Linux 1.3.30 | GCC |
The primary determinant of a system's ability to support a MOO is the amount of RAM it has available for the MOO, after the amount needed for the operating system and other concurrently running processes is taken. Systems without sufficient memory to hold a significant portion of the MOO Database in RAM will experience a great deal of hard disk activity, as the operating system swaps portions of the Database between hard disk and RAM. Although CPU speed can be a cause of lag on very slow systems, or when there are many concurrent users, for most systems it is the lack of sufficient memory and consequent need for a great deal of disk swapping that causes lag. The best solution to this problem is to have sufficient free RAM on the computer to hold at least one third, and preferably one half of the running Database. In a system that doesn't have enough RAM to prevent significant disk swapping, using a fast hard disk access system (e.g. fast, wide SCSI) may help somewhat. Systems on which less than a third of the Database can be (or is normally) held in RAM will commonly show at least some lag when a dozen or more people use the MOO concurrently. It is important to note that the size of the MOO running in memory is typically about 175% of the size of the Database on the hard disk (or 220% for 64-bit systems such as the DEC Alpha or SGI n64) In addition, when the MOO writes a periodic backup copy of the Database to the disk (i.e. performs a "checkpoint"), it may nearly double in size. For this reason, systems that are barely sufficient to run the MOO effectively will commonly lag during checkpoints.
You can estimate the amount of RAM you'll need to operate the MOO at peak efficiency by multiplying the size of the Database on the hard disk by 1.75 (or 2.2 for 32-bit systems), and adding the amount of RAM taken up by the operating system and any other processes running on the same computer. MOO core Databases range in size from about 1.5 to 4.5 MB, and therefore require about 3 to 8 MB available to run effectively. Note that the MOO system will take twice as much memory during checkpoints.
It is very rare that a MOO Database will close to the size of the original core, unless you use drastic restrictions on the amount of building that MOO users may do. MOO Databases commonly grow to 10-20 MB within one to two years, which can require significantly more memory to support effectively. The largest MOO Databases are over 100 MB in size. In general, you should expect to need at least 32 MB of RAM on your system to effectively support an active MOO, with an upgrade to 64 or 128 MB installed one year from starting operation if the MOO is very successful and you encourage people to build.
Note that non-UNIX operating systems are typically not designed to handle numerous simultaneous network connections. For this reason, non-UNIX systems may be unable to handle more than 50-100 concurrent users without experiencing lag. Some WinNT systems may be able to handle as many concurrent connections as UNIX systems.
In general, any processor with performance at least as good as a Pentium/75 MHz can run a MOO, although faster clocks may improve the ability to handle more concurrent connections. In nearly all cases, however, available RAM is the primary determinant of how effectively the MOO runs, with hard disk access speed a distant second. The equivalent to an Intel 486/66 may be sufficient for a MOO with no more than one or two dozen user connections and minimal use of a Web-MOO interface, if it is supplied with a generous amount of RAM.
If the MOO supports a Web-MOO interface, and most of the users will be operating that interface when they are in the MOO, this will put an additional burden on the computer as a certain amount of extra processing overhead is incurred by the Web-MOO interface. However, very little research has been done to determine the actual impact of this additional overhead. It is likely that even a moderately fast processor (i.e. equivalent to a Pentium/120) provided with adequate RAM can handle any reasonable amount of Web-MOO interface activity.
In general, a single MOO is limited to 100-300 concurrent users. It is likely that only UNIX systems are able to handle MOOs that have both large Databases and more than 100 concurrent users, although little exploration of this issue has been done thus far. In addition, at the time of this writing there is an effort being made to improve the efficiency of the LambdaMOO Server, which has been having a significant impact on performance. For this reason, it's not entirely clear what the real capacity of MOOs will be in the near future. Also, MOOs have been linked together into groups, providing a sense of unity for users across the system while supporting significantly larger number of concurrent connections. Very little research has been done into how many concurrent users can be supported using such a mechanism.
In general, nearly any network connection can support a MOO. Even a 28K modem link is sufficient for a MOO without too many concurrent users, if that link is also not used for a Web server providing graphics. MOOs providing a Web-MOO interface for more than a dozen concurrent users should probably have at least a 128K link, since the MOO will generate HTML text files in bursts that may hog a 28K line if several are being sent at once.
Note that MOOs providing a Web-MOO interface do not actually serve the graphics themselves, but only generate HTML text files that include Internet pointers (i.e. URLs), to the graphics or other multimedia material. The actual graphics may be anywhere on the Internet. If your MOO will incorporate graphics through a Web-MOO interface, there is no need to have the Web server that stores and provides those graphics on the same computer, or even the same network, as the one carrying the MOO.
Note that a special situation arises if you wish to use a MOO Database that has already been in use with one type of operating system, and will run it on another. In such a case, there will be MOO characters that have been created and assigned passwords. Because the password encryption system differs among different operating systems, the old passwords will usually not function under the new operating system. The usual solution is to load the MOO database in "emergency wizard mode" and set the archwizard password to zero, then to connect to that character and issue new passwords to every character in the MOO. Specific instructions for how to do this are given in the appendix. However, some MOO cores might use a platform-independent, in-DB encryption system, in which case the passwords will work no matter what operating system the MOO Database is transferred to. Unless the documentation for the MOO core you have used specifies that it uses a platform-independent, in-DB password encryption system, it probably does not.
BE SURE TO SET ASIDE A COPY OF THE DATABASE AS A BACKUP BEFORE FOLLOWING THIS PROCEDURE!!!!
The passwords may be reinitialized, and mail sent to all users informing them of their new password as follows:
1. Modify the script or command that launches the MOO to start it in "emergency wizard mode." This generally means adding the switch "-e" after the "moo" command itself, in the script, batch file, or command line used to launch the MOO. After the MOO loads, it should inform you that it is entering emergency wizard mode, rather than present the regular welcome screen. Note that if you are using a Win95/NT or MacOS system, this appears in the "console" display. You do not need to connect to the MOO via Telnet to use emergency wizard mode, and in fact you can't.
2. Set the archiwizard's password to zero, to allow you to connect to it without a password. In nearly all MOOs, the archwizard is object #2, so set the password with:
;#2.password = 0
3. Determine the name of the archwizard character with:
;#2.name
4. Type "continue" to exit emergency wizard mode and allow the MOO to start listening for connections.
5. Connect to the MOO's regular text interface, using your favorite MUD/MOO client program. From there, connect to the archwizard character with:
connect <name> ""
where <name> is the name (not in quotes) that you obtained in step 3, and the `""' is a pair of double quotes with nothing between them.
6. At this point, you should be connected to the archwizard character. Now add the command that will set new passwords for everyone, using:
@verb me:@initpasswords none none none rd
7. Now program the command by entering the following lines, including the last line, which is just a period on a line by itself:
@program me:@initpasswords
if (caller!=this)
return player:notify("Nope.");
elseif (!this.wizard)
return player:notify("Sorry, only a wizard character can do this, and
you are not one.");
endif
for who in (setremove(setremove(players(),#2),$hacker))
if (who.password && !index(who.password," "))
"skip guests and characters with passwords that are impossible to type";
$wiz_utils:set_password(who, password=$wiz_utils:random_password(6),
#2);
if ($network.active && who.email_address)
"send the new password by email";
$network:raw_sendmail(who.email_address, "Date: " + $time_utils:ctime_for_email(),
tostr("From: ",$network.MOO_name," <",$network.reply_address,">"), tostr("To:
",who.name," <",who.email_address,">"), "Subject: new password", "",
tostr("The password for your MOO character ",who.name," at ",$network.MOO_name,"
has been changed to: ",password),"Please use this new password the next
time you connect to your MOO character.");
endif
endif
$command_utils:suspend_if_needed(10);
"use a long suspend, since the sendmail tasks tend to pile up badly";
endfor
player:notify("Done!");
.
8. Type "@initpassword" to run the command. The MOO will generate new passwords for every registered character in the MOO who has ever connected, and send out email notifying them of their new password.
9. Finally, you should set the password for the archwizard character. If the archwizard is not actually used as an active character (recommended), then use:
@set me.password to "impossible password to type"
otherwise use:
@newpassword me is <password>
to set a new password for yourself. On some MOOs, you may have to use "@password" instead of the "@newpassword" command.
10. Before using "@quit" to end your session, try connecting to your regular, non-wizard character on the MOO to make sure the new passwords have been set properly.
11. After you have successfully re-initialized the passwords for the MOO, you should remove the @initpasswords command with:
@rmverb #2:@initpasswords
Last modified: 08Dec97
Copyright © 1997 Diversity University All rights reserved.