Since most people run ROM on a unix/linux system, most of these answers are written with this platform in mind. Users of ROM on other OS's may need to do things slightly differently.. refer to question 2.3.

## 2.1 OK..I've got this big .tar.gz file.. now what?

Simply put you need to uncompress and un-tar the file, which when done will use about 4 mb's of disk space. Note that compilation will eat another few mb with object files, so make sure you have plenty of disk space to accommodate your expanding mud. You are of course doing all this on a machine you are allowed to run muds on right? More than one person has gotten into trouble for running a mud when they really shouldn't have been, so be careful.

Now, assuming you have the file on a suitable account, all that remains is to expand the thing. The following commands should do the trick:
gzip -d rom24b4a.tar.gz
tar -xvf rom24b4a.tar
On systems with GNU tar, you can combine these two commands into the single command:
tar -xzvf rom24b4a.tar.gz

Note that your filename may be slightly different. Doing these commands will create a Rom24 directory, within which is the ROM distribution. You can now if you wish delete the rom24b4a.tar file to save some space.. but if you do remember where you got it.. having a copy of the unmodified source code is often very useful indeed.

## 2.2 What is the purpose of each directory?

When you enter the Rom24 directory, you will see a number of files and subdirectories. The files you should really read sometime soon, they contain version and licence information which is important to know. The created subdirectories are as follows:

src : contains the C source code.. expect to spend a lot of time here
area - contains the area files and startup script(s)
player - initially empty, this will contain the saved player files
gods - initially empty, this will contain a short file indicating the level and trust of every imm character.. can be very useful to keep track of just how your imms are, and suddenly seeing new entries here can be an indication of hackers.
log - initially empty, this will contain your log files, which contain information about the running of the game. The first file will be called 1000.log, the second 1001.log and so forth. Looking into your log directory some day to see hundreds or thousands of such files is a sure sign that your mud is continuously failing to boot.
docs - this directory contains a lot of documentation that you really should spend the time to read. Some of them are somewhat out of date, being from the original MERC release, but they still do contain important information, and others have been updated to include ROM specific information.

## 2.3 How do I compile the code?

Rom should compile on just about any unix system, and lately running it on a Windows machine has also become popular. There are some problems that arise when compiling on certain systems, and this section will try to address these.

There are several very common types of errors that arise, a few are listed here to try and help you understand more where the problem lies.

Error messages about 'conflicting types' for a function declaration arise when a system function that has been given a prototype in the Rom code has a prototype in the system headers with mismatched argument lists. This happens as the Merc coders added a collection of function prototypes as many systems lacked these in those days. This tends to be much less the case now, and if you get a clash between a function Rom defines and a system-defined function, it is totally safe to comment out the declaration found in the Rom source.

Errors relating to 'undefined symbol' problems are usually indicitive of the mud requiring some libraries that aren't being linked into the executable. To fix this, add the appropriate libraries to the linker line of your Makefile. For example, on my RedHat system 5.0 system which requires the crypt library added explicitly, my linker line looks like : $(CC) $(L_FLAGS) -o rom $(O_FILES) -lcrypt

### 2.3.1 Linux considerations (including RedHat 5.X)

ROM should compile 'out of the box' on a linux system without error.. simply change to the src directory and type 'make'.

RedHat 5.X causes a few problems, due to it's adoption of glibc. You will need to do the following if your Rom is prior to 2.4 B6. If you have 2.4 B6 or later, the following code changes are unnecessary. Additionally, B6 has an additional Makefile called Makefile.linux with the crypt library explicitly added to the linker line.. Simply do:
cp -f Makefile.linux Makefile
This will overwrite the default Makefile with the one you need.
If Your code is prior to B6, then :
1. In comm.c, comment out the declaration of the functions getpeername, getsockname and listen, around line 176 or so.
2. In db.c, comment out the declaration of the function 'random', around line 52 or so.
3. Because glibc has it's crypt functions in a separate library, you need to add '-lcrypt' to the linker line of the Makefile, making it look something like:
$(CC) $(L_FLAGS) -o rom $(O_FILES) -lcrypt

These changes should let you compile under RedHat 5.0, plus any other linux using glibc.

### 2.3.2 Solaris considerations

Note : The recently released 2.4B5 version of Rom contains a Makefile for Solaris, called Makefile.solaris in the src/ directory. The following information is included on the belief that extra information can never hurt.

From: "Rich 'Wolflord' Bradshaw"
Makefile:
below the L_FLAGS definition add
LIBS = -lsocket -lnsl
and for the target, tack $(LIBS) onto the end of the compile line.
rom: $(O_FILES)
rm -f rom
$(CC) $(L_FLAGS) -o rom $(O_FILES) $(LIBS)
---
comm.c
In the Solaris Sys V definitions, around line 286, change
#if defined(SYSV)
to read
#if defined(SYSV) || defined(sparc)
in function: int init_socket( int port ), change
#if defined(SO_DONTLINGER) && !defined(SYSV)
to read
#if defined(SO_DONTLINGER) && !defined(SYSV) && !defined(sparc)
--- merc.h
find the line reading:
#if defined(sun)
and just below the fprintf definition, change the line
#if defined(SYSV)
to read
#if defined(SYSV) || defined(sparc)
--------------
Hopefully that should be everything, well if sparc is defined anyway.
Type:
gcc -dM -E - which should list the defined macros. Pick a suitable one from there for your system.
From kecnom@interaccess.com Mon May 4 00:38:53 1998 kecnom@interaccess.com also said :
Heres what I did to get Rom 2.4 to work on my 2 systems. in comm.c:
comment out the following
the definitions for gettimeofday and getsockopt
and I needed to comment out
If defined(SO_DONTLINGER && !defined(SYSV)
.....all code in here
endif
also had to link with these options as well:
-lsocket -lnsl

### 2.3.3 Windows 95/NT considerations

How to compile and run a Rom under Windows has recently become the most frequently raised topic on the Rom list. Unfortunately, many people don't use windows as their mud platform, so the knowledge base is small. I personally see enough of Windows development tools at work and am glad not to use them at home, so don't have first-hand experience of this myself. However, the following will hopefully be of use until I can get more definite answers to this question.

The 'easiest' way of getting Rom compiled under Windows is to use the Cygnus system, which is a port of most of the unix-based programming utilities that a mud programmer would want. You can download the package and get information at the Cygnus website:
http://www.cygnus.com
With this system, you can compile the 'out of the box' Rom code by simply adding "-DUnix -DNOCRYPT" to the Makefile. You will get numerous warnings, mostly about type comparisons, but these can be ignored.
Lordrom has a port of Rom modified to work under Win32 and Cygnus, though these days most people seem to simply add the appropriate flags to their Makefile and compile under Cygnus that way.
ftp://ftp.game.org/pub/mud/diku/merc/rom/windows/r24ba32s.zip

The other option for Windows development is to use a native Windows development tool such as Microsoft Visual C++. My own observations from the Rom list seem to be that this route is more troublesome, but some people like the environment and tools provided by the MS product.

On his homepage at
http://home.att.net/~mkw/mudframe.html
Michael Weis has links to his MSVC port of Rom2.4b4a plus instructions on getting the mud compiled and running.

Sherlock Holmes also has a page for a MSVC port of Rom, found at
http://www.netrover.com/~nafiel/rom/howto5.html
This page has both code and instructions.

### 2.3.4 Digital Unix considerations

Using gcc, and note I don't run my mud on this platform 24/7, but these are the steps I found necessary to compile a stock Rom 2.4b4a on Digital Unix 4.0
1. Add -DNOCRYPT to the 'nocrypt' section of your Makefile
2. Include unistd.h in comm.c
3. In db.c, comment out the definitions of random and srandom (lines 53-54 or so)
4. You will get warnings seeming to indicate Digital Unix stores time_t as an int, not unreasonable on a 64-bit machine, but the upshoot is that when writing time values in fprintf it complains that you are writing an int as a long token. Either change the appropriate function calls or ignore these warnings as they shouldn't break anything.

### 2.3.5 FreeBSD considerations

From: "Peck, Matthew x96724c1"
I ran into a problem while compiling a fresh version of Rom2.4b6 under FreeBSD 2.2.7. It seems that some of the functions for comm.c and other places (specifically that constantly plaguing problem of crypt) were not defined, as well as a few other minor problems. Here's what I did to fix.
-- in act_info.c (after all the #includes, before the wear table)
+ char *crypt args( ( const char *buf, const char *salt ) );
-- in comm.c (somewhere in the OS-specific stuff, don't matter too much where )
+ int close args( ( int fd ) );
+ int read args( ( int fd, char *buf, int nbyte ) );
+ int select args( ( int width, fd_set *readfds, fd_set *writefds, fd_set *exceptfds, struct timeval *timeout ) );
+ int write args( ( int fd, char *buf, int nbyte ) );
+ char *crypt args( ( const char *buf, const char *salt ) );
-- in db.c
comment out line 56
-- in save.c
- #include
+ #include
-- Use Makefile.linux as the default Makefile.

## 2.4 How do I start the mud?

To start the mud under unix, switch to the area directory and type
startup &
which should start the mud and away you go. There are a few alternatives here -
On systems where the current directory is not in the search path, type
./startup &
For systems with funny shells, type
csh -f ./startup &
On a Win32 port of ROM, run the xxx file, which performs the same functionality as the unix startup.

## 2.5 Why use the startup script? What does it do?

You need not use the startup script, simply typing
../src/rom 4000 &
from within the area directory will start the mud, but there are a few disadvantages to this way.
Firstly, all messages usually written to a log file will be sent to your screen on the window that executed this command. Secondly, and more importantly, when this window is closed or you logout from this session, the mud will be terminated as part of the standard logout procedure.

The startup script checks to see the name of the last log file, and starts the new one with the next filename in succession. It also sets the port for which the mud will run, the default being 9000. You can change this by simply editing the startup script. Note that choice of port number is not necessarily arbitrary.. if you do not own/run the machine on which you're running the mud you need to talk to the owner/administrator to see which port number you should use. Choosing a port number that is reserved for someone else's use is usually not condusive to a long stay on that account.

That caveat aside, and assuming the mud is started properly, you can connect to it by simply telnet'ing to the mud port on your machine. This obviously can be from the machine itself or a remote machine. If it's from the machine on the mud is running, and especially if the machine is not connected to a network, remember that telnet'ing to 'localhost' will always go to the home machine.

## 2.6 How do I make an Immortal char?

When you first connect to the mud, you will be a lowly level 1 with no imms to advance you in level. What you need to do is save your char, then quit from the game. Go into the player directory and you will see there a file with your character's name. Edit this with your favourite text editor and look for the line:
Levl 1
and change this to
Levl 60

It can't hurt while you're here to look at the player file structure.. each line starts with a keyword, then the values for that attribute.

Now reconnect to the mud with this same character name and you are now an immortal with access to all the imm commands.. type 'wizhelp' for a list of most of them. Particularly useful is the 'shutdown' command, which will as the name suggests stop the mud running, and 'reboot', which will terminate the mud and restart it. This command you will use an awful lot as you add and test new code. Note though that the mud will only reboot if started via a startup script/program.

## 2.7 Now what?

That's up to you, depending on what you want from the mud. If you just want to mess around, look at the areas and such then do that. If however you plan to run the mud as a public concern, then you will need to look at expanding the mud, in terms of both code and areas.

## 2.8 The importance of backups

One of the most tedious things to do is frequently make backups. However, it's significantly worse to recreate work that you lost and had no backup for. Worse still is listening to dozens of players scream at you for having no backups of their player files. Having imms scream at you for having no backups of their area files isn't a great hoot either.

In other words, backups are *definitely* worth it in the long run. They are a drag for the 99.9% of times you never need them, but a godsend when that 0.1% comes calling.

Paranoia is a good frame of mind to make backups in.. you are worried of accidental deletion of files..so you make a backup on your account. Then you think that if the hard drive goes belly up you are sunk, so you make another backup on a different machine. Then you wonder what you'll do if the building both machines are in catches fire, and make an off-site backup. I keep backups on 4 machines, on 3 sites, on 2 continents. Even if your system admins do backups, keeping one of your own off site really can't hurt. I've seen muds die because they lost *everything* due to a major computer failure, and it's not funny.

Main Rom Page Index 1 2 3 4 5 6 7 8