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.
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 hereRom 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
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.
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"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: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.
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.
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.
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.
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.
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.
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.