Black Box 4/BlackBox.cdr/bbs_door/wa-134.arj/CONFIG.TXT

Text File | 1992-05-15 | 19KB | 472 lines

                   WIZARD'S ARENA -- RELEASE 1.34
             (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.