Category : BBS Programs+Doors
Archive   : WA-132.ZIP
Filename : CONFIG.TXT

WIZARD'S ARENA -- RELEASE 1.32
(C) Copyright 1991,1992 by Douglas Summers

CONFIGURATION


ÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ
THE CONFIGURATION FILE
ÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ
Beginning in version 1.22, WIZARD'S ARENA will get its parameters
from a text file rather than from the command line. This file is
named "CONFIG.WA".

Running the upgrade program will generate an initial CONFIG.WA, which
you may then edit using any simple-ASCII text editor. If none was
made, then you should begin with a nice, blank one.

CONFIG.WA is a simple text file, made up of individual lines. Each
line is of the format "aaaa=bbbb" where "aaaa" is the name of some
parameter and "bbbb" is the value to be assigned to it. For example,
the line

BBSNAME = The Truly Massive BBS

is used to set the name of the BBS to be "The Truly Massive BBS". The
equals-sign may be preceded or followed by any number of spaces. The
line, as well, can have spaces before the parameter-name and after
the last character of the value. Such spaces will be ignored. The
values are case-insensitive: BUT THE EXCEPTION IS THE BBS NAME,
which IS case-sensitive.

You'll note that a lot of the configuration options are related to
error-correction. This doesn't mean that the game is particularly
flimsy; they're mostly stuff I found useful in developing/debugging
and saw some real-world use for.


ÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ
GENERALLY-AVAILABLE OPTIONS
ÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ

BBSNAME
ÄÄÄÄÄÄÄ
This sets the name of the BBS. You MUST have this one, and,
unlike all the others, is case-sensitive. Please, please note
that the name, once you've registered, must remain fixed.
Changing it will invalidate your registration, and you'll have
to contact me give you a new registration sequence.


DEBUG
ÄÄÄÄÄ
This forces extensive debugging information to be collected.
DON'T USE THIS UNLESS YOU REALLY NEED IT. There is no built-in
method to clean up the huge ERRORS.OUT file that will be
generated. Turn this on with "DEBUG = Y" -- anything else means
debugging is off.


REMOTECOLOR
ÄÄÄÄÄÄÄÄÄÄÄ
This is used to set the color the user's screen is set to
when the program terminates. There are 16 possible settings:
BLACK, BLUE, GREEN, CYAN, RED, MAGENTA, BROWN, DINGY
(lo-intensity white), GRAY (hi-intensity black), HIBLUE,
HIGREEN, HICYAN, HIRED, HIMAGENTA, YELLOW and WHITE.


LOCALCOLOR
ÄÄÄÄÄÄÄÄÄÄ
Like REMOTECOLOR, but applies to the local terminal.


PARANOID
ÄÄÄÄÄÄÄÄ
Used to disable the "backdoor" functions. These functions are
debugging aids that the author thought might be handy to leave
in, because they can be used to perform a certain amount of in-
situ diagnosis.
They are available as unlisted commands. To see them, type "&"
for your action; nothing will happen; then enter one of the
following:

"M" shows memory available
"E" dumps out the error log
"S" prints out certain game statistics
"K" echoes back key-codes

There aren't any others. Unless you're REALLY, REALLY afraid
that this information seriously compromises your BBS, you might
want to leave them available in the event a problem DOES occur.
Turn this on with "PARANOID = Y" -- anything else means that
paranoia is off (the functions are available).


PORT
ÄÄÄÄ
If you have nonstandard comm port or are using a fossil driver,
you can tell the game about it with the PORT parameter. The
format for this parameter is: "PORT = aaa:i", where "aaaa" is
the base address and "i" is the interrupt. For example,
"PORT = 02F8:3" sets the system to use a com-port whose base
address is 02F8 and which uses IRQ 3.
For fossil drivers, use "PORT = F:n" where "n" is the number
of the com-port to use the fossil driver on.


DOORFILE
ÄÄÄÄÄÄÄÄ
Gives the full path-and-filename of the BBS's door-information
file. This parameter can be overridden by the command-line, but
if no parameter is given there, then this is the file used.


SEMAPHORE
ÄÄÄÄÄÄÄÄÄ
WIZARD and WA-UTIL make a special semaphoring file to prevent
either program from running while the other is active. If the
various nodes of a LAN BBS have their real-time clocks seriously
out-of-sync, the technique employed becomes useless. If that
is the case, set semaphoring off via a "SEMAPHORE = NO" line,
and handle such protection in your batch file.


ÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ
OPTIONS AVAILABLE ONLY TO REGISTERED SYSOPS
ÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ
After you've played the game and been vastly impressed by the
sheer genius of it, you can send me money. I'd like that.
(The SYSOP.TXT file gives details on how much and where; for now,
I'll take it as read that you've done that.)

What you'll get back for your hard-earned cash is an eight-digit
registration code. You should put it in your CONFIG.WA file,
where the game can find it and reward you for your generosity.

You will, at that point, have access to a number of other parameters
which will allow you a fair amount of customization.


APDIV, APMULT
ÄÄÄÄÄÄÄÄÄÄÄÄÄ
Every creature in the game -- monsters and players alike --
receive a certain number of Action Points (APs) every day.
These determine how much a creature can do; every action
(with only 1 or 2 exceptions) costs APs, and when a creature
uses up its APs, it has to stop for the day.
These two parameters help determine how many APs everyone gets.
The process is:

If a creature has an Agility of less than (or equal to)
15, it gets a number of APs equal to its Agility rating.

If its Agility is 16 or more, it gets 15 AP, plus a certain
number determined by this formula:

((Agility - 15) * APMULT) / APDIV

For example, let's say you've set up "APMULT = 2" and "APDIV = 3".
A creature with an agility of 5 gets 5 AP (and is pretty much a
sitting duck). Another creature, with an Agility of 47, will get

((47 - 15) * 2) / 3 = 21 AP.

Why would you want to do this? If we simply let the number of AP
equal the Agility rating, a player could quickly get to a rating
of 50 or more -- which would allow him a great many attacks, if
he didn't have to move far to get to his target. If his target
is a monster, that's not so bad -- but if its a player, it isn't
really fair. The other player could be taken completely unawares
and be destroyed by someone he didn't even know was there. In a
sense, these values set the "dangerousness" of the game: the degree
to which a player must take precautions against unexpected attacks.


MONSTERSPEED
ÄÄÄÄÄÄÄÄÄÄÄÄ
If you want the players to be mobile, but not the monsters, then
simply setting APMULT high won't really accomplish what you want.
The monsters will also be fast -- and if one happens to "pop in"
adjacent to a player, he could get in a great many whacks before
the player has a chance to do anything about it.
The MONSTERSPEED parameter determines the rate at which the
monsters expend AP to do things. For example, if the MONSTERSPEED
is 0, it costs them 5 times as many AP to do anything as it does
the players -- which means that they're slow and don't attack
often. Setting it to 9 makes them about twice as mobile as the
players -- and very dangerous. (It can be set all the way to 20).
If you want the players to focus on each other, set MONSTERSPEED
low; if you want them to become monster-obsessed, set it high.


ABSENCES
ÄÄÄÄÄÄÄÄ
The game only allows 64 players. If players try the game once,
and never come back, then their player-records would sit around
forever. The game, to get around this, counts the number of
"absences" a player has (the number of days since he last played).
If that number exceeds the ABSENCES value, his character suffers
a heart attack and leaves a corpse on the map, and his player-
record is made available for the use of other people. Setting
this value low is probably unfair; setting it too high might cause
the clogging earlier mentioned. The default value of 14 seems
reasonable, but your circumstances might dictate something else.


TRAINCOST, TRAINSLOPE
ÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ
Players gain experience by killing monsters (or other players).
They trade experience points (via the "Train" command) for
higher characteristic values, or for spell proficiency. This
has the net effect of making them more powerful.
By default, it always costs 100 XP to train. These two parameters
allow you to change that.
TRAINCOST determines the number of XP necessary to train the first
time. Each successive training costs the same amount, multiplied
by 1% of the TRAINSLOPE value. an example will make that clearer.
Lets say you've set "TRAINCOST = 50" and a "TRAINSLOPE = 250".
A player will need

50 XP to train the 1st time,
50 * 2.50 = 125 XP to train the 2nd time,
125 * 2.50 = 312 XP to train the 3rd time,
312 * 2.50 = 780 XP to train the 4th time,

and so on. The net effect is to make it harder and harder to
train, so that players do not too quickly become massively
powerful. This particular TRAINSLOPE value, though is much too
steep. It was chosen as an example only. I more reasonable
value might be "TRAINCOST = 50" and" TRAINSLOPE = 110":

50 XP to train the 1st time,
50 * 1.10 = 55 XP to train the 2nd time,
55 * 1.10 = 60 XP to train the 3rd time,
60 * 1.10 = 66 XP to train the 4th time, and so on.

It will never cost more than 20000 XP to train. Players begin
with an XP allotment of eight times the TRAINCOST value.


MONSTERPROB, OBJECTPROB
ÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ
The daily maintenance routines put out monsters and random objects
like swords and shields. Each space on the map is examined,
and may have a monster or object put into it if it is already
empty (and if the type of the terrain permits). The probability
each space has of generating a monster is given by MONSTERPROB;
the probability of generating an item is given by OBJECTPROB.
Both are expressed in "chances per 10000" form.
For example, lets say you have set "MONSTERPROB = 80" and
"OBJECTPROB = 100". This means that each empty space has a 0.8%
chance of getting a monster each day; a space that doesn't get a
monster has a 1.0% chance of getting an object.
These probabilities might not sound like much, but over the whole
map, they add up. The map is (at present) 100 x 50 -- the settings
indicated would generate about 40 monsters PER DAY -- and about
50 objects.
There is an added complication, however: not all of the map is
necessarily given a chance to generate. Only the areas around the
players can generate. This keeps huge numbers of monsters and
objects from being generated in unvisited rooms and hallways,
thereby clogging the system.


MAGICPROB
ÄÄÄÄÄÄÄÄÄ
This gives the probability (in chances per 10000) that a given
object dropped during daily maintenance will be enchanted. It
defaults to zero, so non-registered sysops never get this.


EXTERMINATION
ÄÄÄÄÄÄÄÄÄÄÄÄÄ
Monsters that are far away from any player are pretty much useless.
They wander around, taking up precious time during the daily
maintenance and no-one would ever miss them if they disappeared.
So the system may decide to simply erase them. It will do so a
certain percentage of the time, as given by the EXTERMINATION
parameter.
It is expressed in 10ths-of-a-percent form, so an "EXTERMINATION =
250" gives each such "lonely" monster a 25% chance of being snuffed
out each day. Monsters Controlled by players, and those under
spells, and those carrying "interesting" items, are exempt from
this form of extermination.


CACHE
ÄÄÄÄÄ
The game internally caches certain database operations for reasons
of efficiency. If the game is running a little slow on your BBS,
try setting the this option to higher values. (It isn't a simple
number-of-kilobytes measure). Experimentation will probably pay off,
and can't hurt you. Try "CACHE = 300" for best results. If the
system can't allocate that much (it would take about 64k), then
it will automatically downscale the cache and try again.
I've found that this doesn't make as much difference as one might
hope; there's roughly a 30% speedup with "CACHE = 300" (which is the
maximum). A REAL disk cache would make a LOT more difference.


TIMEALLOWED
ÄÄÄÄÄÄÄÄÄÄÄ
Allows you to set the maximum time (per day) that a player can stay
in the game. For the unregistered sysops, that number is equal to
the players' total remaining time on the BBS. For registered sysops,
it is the lower of that value and the value provided with this
option. (Multiple entrances to the door will NOT allow the player
more time -- it adds up). I don't think this one will matter much
to most people, since it seems that a typical "session" of WIZARD'S
ARENA is not very long. Still, if you want to limit your players
to only 5 minutes, use "TIMEALLOWED = 5".


HELLOMSG
ÄÄÄÄÄÄÄÄ
If you want to send a short message to all the players as they
log onto the game, you can assign one with the HELLOMSG parameter.
Simply make a line like the following:

HELLOMSG = Your sysop sends you greetings, mortal.

and the user, after seeing his mail will see that on in the
text-area of the screen, just before the "You are in Wizard's
Arena" line. You could, for example, use this to remind non-
registered users that they might like to register.


AUTOSAVE
ÄÄÄÄÄÄÄÄ
Setting this parameter on (i.e., "AUTOSAVE = Y") will cause the
game to back up the databases before the game, and, if an error
occurs, to restore from this backup when the next player logs
in. This won't obviate all errors -- some types of error might
cause the game to terminate OK but leave the databases in a bad
state, for example. It by no means replaces regular backups.


REGISTRATION
ÄÄÄÄÄÄÄÄÄÄÄÄ
Sets the key sequence -- see SYSOP.TXT for details on registration.


STARTBONUS
ÄÄÄÄÄÄÄÄÄÄ
A player is given a certain number of extra AP on the first day
he's in the game. The default is 10; this option lets you change
that value. Setting it higher lets new players move around more,
explore farther and play longer on their first move, which lets
them have a greater chance of survival.


AUTOVALIDATE
ÄÄÄÄÄÄÄÄÄÄÄÄ
When a player enters the game after another player has bombed
out, the system will try to fix the databas. The map, for example,
can be corrected from a copy kept of the original map. If a
persistent problem comes up, you can set this option on (via
"AUTOVALIDATE = Y") to force validation even if the system hasn't
bombed out.


FRATERNITY
ÄÄÄÄÄÄÄÄÄÄ
You can disallow fraternity membership to your players by setting
"FRATERNITY = N". The idea here is that if you maintain seperate
configurations for your registered and unregistered users, it
becomes possible to only allow registered users to join frats.
By default, "FRATERNITY = Y", meaning that players by default
are able to join frats.


MIDNIGHT
ÄÄÄÄÄÄÄÄ
The game uses the computer's real-time clock to determine if
daily maintenance should be run. This is perfectly reasonable,
unless you do the maintenance off-line at some hour other than
midnight. If this is the case, a user who logs in AFTER midnight
but BEFORE your off-line processing will trigger the daily
maintenance.
You can change this by telling the game never to perform daily
maintenance before a certain time of day. If, for example,
your off-line stuff happens at 4:30, you might set "MIDNIGHT=4:45"
(to allow some leeway). The WA-UTIL program will IGNORE this
parameter -- it is assumed that the time you call WA-UTIL is
when you want the maintenance to occur.


FREEMOVE
ÄÄÄÄÄÄÄÄ
For sysops who like a more wide-open game, movement can be made
free (for players). By setting "FREEMOVE = Y", all players
(but not monsters) will be allowed to move as far as they like
each day.



ÄÄÄÄÄÄÄÄÄÄÄÄÄÄ
A FURTHER NOTE
ÄÄÄÄÄÄÄÄÄÄÄÄÄÄ
Monsters move entirely during daily maintenance. So setting
MONSTERSPEED high when you have a lot of monsters running around will
make the daily maintenance go slowly -- perhaps several minutes. The
same caveat applies to the APMULT and APDIV parameters: if monsters
have a lot of AP to spend, they'll take a little longer to spend it.
So experiment around with good trade-offs between the speed of your
system and the effects you want to produce.


ÄÄÄÄÄÄÄÄÄÄÄÄ
THE DEFAULTS
ÄÄÄÄÄÄÄÄÄÄÄÄ
Your CONFIG.WA file MUST specify a BBSNAME. The REGISTRATION
parameter is only meaningful if you've bought a registration sequence
from the author. By default, DOORFILE isn't defined, which means
that the door-information file must be specified on the
command-line. Also, the PORT parameter is not defined, which means
that comm-port info is derived from the door-information file.

The other parameters default as follows:


DEBUG = N
REMOTECOLOR = WHITE
LOCALCOLOR = WHITE
PARANOID = N
APDIV = 2
APMULT = 1
ABSENCES = 14
TRAINCOST = 100
TRAINSLOPE = 100
MONSTERPROB = 50
OBJECTPROB = 60
MAGICPROB = 0
MONSTERSPEED = 2
TIMEALLOWED = 60
EXTERMINATION = 250
AUTOSAVE = Y
STARTBONUS = 20
AUTOVALIDATE = N
SEMAPHORE = Y
FRATERNITY = Y

A sysop who wishes to favor his registered users over the unregistered
ones might set up two files, one named REG.CFG and the other named
UNREG.CFG.

For example, REG.CFG might contain:

TRAINCOST = 100
TRAINSLOPE = 100
TIMEALLOWED = 60
BBSNAME = The Example BBS
REGISTRATION = 55555555

and UNREG.CFG might have:

TRAINCOST = 100
TRAINSLOPE = 110
TIMEALLOWED = 10
BBSNAME = The Example BBS
REGISTRATION = 55555555
HELLOMSG = You should send your sysop some money, scumbag.


He could then arrange his batch files so that, for registered users,
REG.CFG is copied over to CONFIG.WA before WIZARD is executed.
Obviously UNREG.CFG would be copied to CONFIG.WA for unregistered
users. The net effect is that registered users have an easier time
acquiring power, and have longer to play each day. He also would
not be abused every time he came into the game.