home
***
CD-ROM
|
disk
|
FTP
|
other
***
search
/
Monster Media 1994 - The BEST of 1994
/
monster1.zip
/
monster1
/
BBS_GAM2
/
OXV111.ZIP
/
SYSOP.DOC
< prev
next >
Wrap
Text File
|
1994-06-17
|
42KB
|
809 lines
IRON OX Version 1.11
(C)opyright 1994, Joel Downer
SUMMARY
Iron Ox is an interactive, multiuser strategy game for 3-8 players. The
game concept is the development of an outer space colony world: Players
claim land, produce goods, buy, sell, and steal from one another, and
prospect for luxite, the precious mineral that allows interstellar travel.
The door supports up to 255 simultaneous games involving up to 255 active
players.
Iron Ox is self-maintaining (no nightly maintenance event), and includes
"sysop-friendly" features such as:
* detection and timeslicing for DESQview,
* built-in multinode support and semaphoring (so several people can use
the door at one time),
* support for a wide variety of door drop files (including DOOR.SYS,
DORINFO?.DEF, EXITINFO.BBS, CHAIN.TXT, CALLINFO.BBS, and SFDOORS.DAT),
* support for direct serial communications or FOSSIL, and
* comprehensive high-score and record listing with optional ANSI, ASCII,
and WC-code bulletins.
The game includes lighthearted humor -- for example, the colony sponsors
"cultural contests" in which players can write bad poetry or disgusting
recipes -- but it also supports complex strategy and intense
competition. The door requires that players have ANSI terminals, but
does not require a color monitor.
EVALUATION VERSION
Iron Ox is distributed in an evaluation version, intended for you to try
out for thirty days. The evaluation version of Iron Ox is a complete
and (I hope) enjoyable game. If you like Iron Ox and wish to continue
using it after thirty days, please see "LICENSING/REGISTRATION
INFORMATION," below, for details on how to register. A registration key
for Iron Ox will enable additional features that will make the game even
more exciting for your users!
GETTING STARTED
Iron Ox is a game that requires multiple players, so you won't be able
to take a very thorough "test drive" without putting it up for play on
your BBS. If you want to take a look at the door before installing it,
though, you can run the program just by typing IRONOX -LOCAL from the
directory where you have unpacked the archive.
REQUIREMENTS
Iron Ox requires approximately 420K of free RAM to run properly. It
requires a minimum of 750K free disk space. Depending on the number of
active games you have going on at a time, it can take up as much as
1,500K of disk space. A hard drive is strongly recommended; on the
other hand, if you're running a BBS without one, the performance of Iron
Ox is probably the least of your worries. <g>
Beginning with version 1.10, Iron Ox includes internal comm routines,
with support for non-standard IRQ's and for rates of up to 115Kbps, as
well as support for a FOSSIL driver. However, support for some
specialized requirements (DigiBoards, shared IRQ's) is provided only
through the FOSSIL standard. Recent versions of several popular FOSSIL
drivers are available through the systems listed in "Support," below.
INSTALLING IRON OX
I've learned to be very suspicious when door documentation says "This
door is very easy to set up," so I won't say that. I'll let you judge
for yourself.
Iron Ox is an extremely flexible and configurable program, so this
section may be longer than you're used to. If all you want to do is get
the game running with a basic setup, though, you'll only need to read
the first few paragraphs and spend about five minutes. If you have any
trouble, see "COMMON INSTALLATION PROBLEMS," below.
Installing Iron Ox involves three steps:
1. Decompressing the Iron Ox archive into a door directory. The
examples in this file and the sample batch file assume that you have
used the directory C:\DOOR\IRONOX\, but any directory will do.
2. Renaming the file called SAMPLE.CFG to the name IRONOX.CFG.
Alternatively, you can run the program OXConfig to create a custom
configuration file (e.g., if you want to have high score bulletins).
3. Creating a batch file by which your BBS can start Iron Ox. Most of
the time, this batch file will include only one line:
C:\DOOR\IRONOX\IRONOX.EXE
(Note: Substitute the path where you have installed the game for
C:\DOOR\IRONOX\ in the above example.)
The game supports several command-line arguments, but you are likely
only to need those arguments if:
(a) you don't run a FOSSIL driver and you want to specify things like
non-standard IRQ's.
(b) you are running multinode with BBS software that doesn't include
the node number in the door information file, or
(c) you use a number of different door drop files, and you want to
tell Iron Ox which one to use.
In general, the considerations listed under (b) and (c) don't come up
for systems using DOOR.SYS, SFDOORS.DAT, CHAIN.TXT, or CALLINFO.BBS.
They are more likely to be issues for people running DORINFO systems.
You're ready to add the game to your BBS door menu and get rolling. Enjoy!
COMMAND-LINE ARGUMENTS
Iron Ox supports a number of command-line parameters. If the
documentation for any of these makes your eyes glaze over, your best bet
is to skip over to the next one. Chances are that if you don't
understand it, you also don't need it.
/ACCEPT This option tells Iron Ox not to mess with the
communications parameters currently set for your comm port
-- to open the port (or the FOSSIL driver, if appropriate)
as it stands. It is intended to help people whose systems
do not respond correctly when a door program attempts to
reset communications parameters. Advice: Assume you
*DON'T* need this option unless the game doesn't work
without it.
/EDIT This option activates the Game Editor subsystem, so that
games may be (E)dited as well as (S)tarted, (J)oined, and
(P)layed. See "THE EDITOR," below. WARNING: This option
is *NOT* keyed to security level! Do not use this option
for your normal door batch files unless your goal is to set
up a "Fantasy Game" or "Workshop" rather than a real game.
/LOCK This option allows you to lock the bps rate Iron Ox uses to
communicate with your modem to a speed other than the one
specified in your door information file. Example:
IRONOX /LOCK:19200
This option is only effective if you are using the internal
comm system (port-locking for FOSSIL drivers should be
controlled through FOSSIL driver setup).
/N: This option allows you to indicate the current node number
when the game is run on a multinode system. Example:
IRONOX /N:3
Note: On most systems, the node number is included in the
door drop file and *THIS OPTION IS NOT NEEDED*. The most
common systems where you *will* want to use this option are
DORINFO1.DEF BBS packages like RemoteAccess.
/NOFIFO Some Western Digital 16550 cards have a bug that causes
them to lock up when their FIFO buffers are used. This
flag tells Ox to disable its use of FIFO buffers. Note:
If you've never heard of this FIFO bug before, assume that
it *DOESN'T* apply to you and do not use this option! If
the problem applied to you, you'd know by now. <g>
/NOFOSSIL If you *have* a FOSSIL driver, but do *not* wish to use it,
this flag will tell the game to ignore the driver and use
internal comm instead. This option may be useful if you
are having problems with Iron Ox's FOSSIL support. Note:
If you do not have a FOSSIL, you do not need this option --
Iron Ox will automatically default to internal comm if it
does not find a FOSSIL.
/P, /I These options allow you to set the hexadecimal base address
and the IRQ number for a non-standard serial port. Example:
IRONOX /P:3F8 /I:4
indicates that the game should use base address 3F8h, and
IRQ4 for serial I/O. These arguments are *ONLY* needed if
you are using internal serial support; they are ignored if
you have a FOSSIL installed and have not used the /NOFOSSIL
argument. Note: The AT IRQ lines (9-15) are *NOT*
supported using these arguments. Support for the AT IRQ's
is only available through a FOSSIL driver.
[pathname] By default, Iron Ox looks for a door drop file in the
current directory -- it expects to be run from the node
work directory, as described above. Also by default, it
will autodetect which dropfile to use by checking the
directory for the most current dropfile it supports (i.e.,
it does freshness-testing to avoid using stray dropfiles).
You can specify the path where Iron Ox should look for its
dropfile and (if necessary) the name of the dropfile to
use. Thus:
C:\DOOR\IRONOX\IRONOX.EXE C:\WC30\WCWORK\NODE1\
or, alternatively
C:\DOOR\IRONOX\IRONOX.EXE C:\QBBS\DORINFO3.DEF
Note: This command-line option is usually not necessary.
MULTINODE SETUP
Iron Ox was written and tested from the ground up to run multinode. In
general, multinode setup is *identical* to single-node setup: All nodes
can use the same configuration file, and (for the most part) they can
use the same batch file, too. Because the program supports FOSSIL
drivers, it can handle issues like non-standard IRQ's *completely
automatically* -- no need to treat individual nodes specially on FOSSIL
systems.
Multiple players can use this door at the same time; Iron Ox handles all
file locking internally. (Note: The file-locking system supports node
numbers up to about 1,000 -- if you need higher ones, contact me and I'm
sure we can work *something* out. <g>) The only requirement for running
the game multinode is that you must be running DOS SHARE or some
equivalent (like the built-in file-sharing in the OS/2 DOS box or the
file-sharing facilities on LANs). If you're running multinode *without*
such a utility, of course, now would be a good time to start.
To set up the game for multinode play, create batch files for each node
along the lines in the single-node instructions, above. The only times
different nodes will need *different* batch files are
(a) when the game is run across a LAN on which the drive letter for the
game directory is different for different nodes, and
(b) when you are running nodes with non-standard IRQ's and you are *NOT*
using a FOSSIL driver.
(If you are running a multiline system where the node number is not
included in the door information file, like RemoteAccess with
DORINFO1.DEF, you will either need to use multiple batch files or use an
environment variable to specify the node number with the /N option. See
"COMMAND-LINE ARGUMENTS," above.)
One more thing: Because of a bug with either Borland's run-time
libraries or with Quarterdeck's products (who's to blame for the bug
depends on whether you ask Borland or Quarterdeck <g>), you may find
that you need to flag your IRONOX.EXE executable file read-only to avoid
sharing violations when running multinode under DESQview or QEMM. To
do this, just use the command ATTRIB IRONOX.EXE +R after unpacking the
game into your door directory. If you ever need to uninstall Iron Ox,
you can use the command ATTRIB IRONOX.EXE -R to "unflag" the file.
That's all it takes! Iron Ox uses lock files to control simultaneous
use of files, so resources may remain locked if the system crashes while
someone is in the door. However, each node will clear all of its locks
every time it enters or exits the door normally, so "lingering locks"
will be cleared automatically shortly after they arise. If you have a
system that crashes frequently, adding a line like "DEL C:\DOOR\IRONOX\*.L*"
to your AUTOEXEC.BAT file will clear all locks immediately when the
computer reboots.
COMMON INSTALLATION PROBLEMS
The most common mistake sysops make installing this program is trying
to get too fancy. Don't copy your door information file to the game
directory. Don't specify the dropfile path on the command line for
the game unless the game doesn't work without it. Don't add a line to
your batch file that changes to the game directory before execution.
Don't add the game to your path. Just create a batch file that looks
like the one in "INSTALLING IRON OX," above. Keep it simple.
Here are some installation problems that might come up:
1. The game says it can't find my door dropfile!
This game assumes that you are running it from the directory where
your BBS dropfile is located. Every BBS package I know of normally
launches door execution from the directory where the dropfile is
located, but if yours doesn't, you will need to specify the dropfile
location and/or name on the command line.
2. The game works fine locally, but doesn't work over a modem!
If you are having trouble getting the internal serial support to
work, one good solution is to try a FOSSIL driver. FOSSIL drivers
are an excellent choice for high-performance communications, and can
(if you wish) be loaded and unloaded from the batch file that
executes Iron Ox. If you do not have a FOSSIL driver, they are
available from the systems listed under "Support," below, among many
other places.
If you don't wish to use a FOSSIL, or if you're already *using* a
FOSSIL and are still having problems, the /ACCEPT, /LOCK, /P and /I
options explained in the section on command-line arguments may help
with the problem. If not, feel free to contact me for further
assistance.
3. I have a high-speed modem. When low-speed callers go into the game,
all they see is garbage on the screen!
If you are using a FOSSIL, try locking the baud rate at which your
computer talks to your modem (the docs for your FOSSIL driver will
explain how to do this). High-speed modems generally perform better
when used with a locked port, and the combination of high-speed
modem, low-speed connect, and unlocked FOSSIL driver can cause
problems with this and some other doors.
4. The game runs fine single-node, but if two people try to go in at
once, I get a sharing violation!
As I say in the section on multinode setup, either my compiler or
Quarterdeck's products have a bug that causes sharing violations when
you try to run an overlaid program multinode. The work-around for
this problem is to flag your IRONOX.EXE file read-only using the
command ATTRIB IRONOX.EXE +R. Even if you aren't using a Quarterdeck
product like DESQview or QEMM, give this solution a try: Odds are
good it'll correct the problem completely.
5. The game is getting confused about what node it's running on!
Iron Ox is designed to figure out the node ID on which it's running
from the BBS drop file. On some systems, however, determining the
node ID from the drop file is not possible. See the documentation
for the "/N" command-line parameter, above.
USING THE EDITOR
Iron Ox comes with a complete, built-in editor for general game
statistics, players, the map, the general store, and contest entries.
To simplify your remote maintenance tasks, this editor is coded to work
through a modem as well as in local mode. In the unregistered version
of the game, the editor is "read-only"; in the registered version, you
will be able to modify any of the information listed above.
To activate the editor, all you need to do is load the game with the
/EDIT command-line flag. The option to (E)dit a game will show up
alongside the options to join, start, and play games.
IMPORTANT NOTE: The option to edit games is *NOT* keyed to security
level! Therefore, you would not normally want to configure your batch
files to load Iron Ox with the /EDIT parameter. The only time you would
want to make the editor available to players is if you were running some
sort of a practice door or fantasy game.
The recommended use for the editor is to set it up as a separate menu
option, and to key this menu option to an access level that will make it
unavailable to anyone but you. The editor uses the same file locking
conventions as the game, so using the editor while someone else is
online will not cause problems.
For the most part, the options in the editor are self-explanatory. Here
are a few notes about features that may not be:
Global Settings
Game Month The game will not allow you to use this option to
force a game to begin (i.e., when it is waiting for
players) unless the game already has at least three
players.
Map Editor
Volume of Luxite This value determines the highest amount of luxite
that can normally be produced by the plot in a given
month (in other words, if the value is 5, the range
will be 0 - 5). Setting the value over 18 or so will
probably make for silly production values. Setting
it over 25 will seriously imbalance the game in favor
of the owner of the plot (if not a Rubblemuncher <g>).
"For sale" This option is for corrective maintenance -- i.e., if
the game won't let a player sell land because it
thinks the land is already for sale. I can think of
no good reason to use this option at other times.
Player Editor
Is Character Dead This option provides a quick-'n-handy way to kill or
resurrect characters. Be forewarned, however, that
when when a character dies, all of his/her property
is seized; resurrecting the character doesn't restore
the property. Please use this feature judiciously.
Last Turn Played This value, combined with the game month, determines
whether a player will be allowed into the game. If
you need to reset a player's session, the normal way
to do so would be to adjust this value and set the
"Claimed Land" variable to FALSE.
CONFIGURING IRON OX
The easiest way to fine-tune the configuration for your Iron Ox game is
to run the utility called OXCONFIG.EXE, included in your IRONOX
distribution archive. OXCONFIG will let you adjust all options,
explaining the function, default, and recommended value for each option.
OXCONFIG produces a file called IRONOX.CFG, which resides in the same
directory as IRONOX.EXE. In case you prefer using an ASCII text editor
to fiddling with configuration programs, the following section documents
the variables that appear in IRONOX.CFG and outlines how to modify them
to change your configuration manually.
Keyword Default Function
SysopName No One This keyword determines the name that will be
used when the game describes who it belongs to.
If you decide to register this game, you will
need to enter your name here exactly as it
appears in your registration letter. This
keyword is ignored in unregistered games.
BBSName Unregistered This keyword determines the system name that
will be used when the game describes the BBS to
which it is registered. See "SysopName," above.
RegCode (blank) This is where you would insert the key code,
available from the author, that will activate the
"registered-only" features of the game. See
"LICENSING/REGISTRATION INFORMATION," below.
Timeout 360 This keyword determines the amount of time, in
seconds, that the game will wait between keystrokes
before it decides that a user is "sleeping at the
keyboard" and boots him/her out. This game can
require thought, so substantially reducing this
number is not recommended. Note: Timeout is
automatically disabled when the game is run in
local mode.
MaxGames 3 This keyword determines the maximum number of
games a player can participate in at one time.
Allowing players to participate in multiple
games will increase interest, but setting this
value too high would give high-speed callers a
big advantage in the monthly standings. Note:
This keyword is ignored (hardcoded to 3) in the
evaluation version of the game.
MinGameLength 14 In the registered version of Iron Ox, players
MaxGameLength 14 may select games shorter or longer than 14
turns. These variables set bounds on game
length.
Because all-time records are less meaningful
when the door is configured to allow very long
games, and the game can less entertaining if it
continues long after all land is claimed, 14
turns is recommended both for Minimum Length and
Maximum Length. Allowing games shorter than ten
or longer than eighteen turns is discouraged.
ResetType The allowed values for this variable are
RESET_MONTHLY, RESET_DAYS, and RESET_DATE. By
default, the cumulative high scores for Iron Ox
reset on the first of each month (i.e.,
RESET_MONTHLY). Choosing RESET_DAYS will cause
the scores to reset every specified number of
days. Choosing RESET_DATE will cause the scores
to reset on a fixed date. These alternative
options are most useful for organizing
tournaments. See the variables "ResetDays" and
"ResetDate," below. Note: This option only
affects cumulative scores. The actual ongoing
games never need to be reset or interrupted.
ResetDays If you chose to reset every fixed number of days
(see ResetType, above), this variable controls
the number of days between score resets. The
value entered should be a positive whole number,
e.g., 30 or 90.
ResetDate If you chose to reset on a fixed date, this
field controls the day for score reset. Enter
full month name, followed by day and year, thus:
January 1, 1995
This option is excellent for managing
tournaments, because the reset date is displayed
prominently in the high score screen.
StartGames TRUE This keyword determines whether players are
allowed to begin new games. The only time you
would be likely to set this value to FALSE would
be if you were winding down a tournament with a
fixed duration.
Secure FALSE If you (the sysop) are playing in games, you
might not want to watch as other people play
their turns in the games in which you're
involved -- you could see something that would
give you an unfair advantage. Setting Secure to
TRUE will cause the game to blank the local screen
when a remote player is playing in a game in
which zero-baud (local) players are involved.
NoLog FALSE This option allows you to disable the game's
automatic logging feature, which records basic
game events and errors in one or more files
called OX????.LOG (where the question marks are
replaced by the node number). Turning off
logging can save some disk space, but it can
also make problem-solving more difficult.
Recommended setting is FALSE (does not disable
the log).
ANSI_Score (blank) This keyword determines the name and path of the
ANSI Score bulletin the game will create. Leaving
the space after the keyword blank, as it is in the
sample configuration file, indicates that you
want the game to create *NO* ANSI score bulletin.
ASCII_Score (blank) Name and path of the ASCII high score bulletin.
WC_Score (blank) Name and path of score bulletin using Wildcat!-
style @ codes.
ANSI_Records (blank) Name and path of the ANSI all-time-records bulletin.
ASCII_Records (blank) Name and path of the ASCII records bulletin.
WC_Records (blank) Name and path of the WC-style records bulletin.
DailyPrize 0 You may configure the game to award a daily, weekly,
and/or monthly time prize to the current leader in
the standings. A value of 0 disables time prizes.
Time prizes are disabled in the unregistered version
of Iron Ox.
Here are some guidelines on prizes: the prizes
should go from very small (daily) to fairly
generous (monthly). Values of five minutes for
daily, ten for weekly, and thirty for monthly
might be reasonable.
Note: Time prizes only work on systems that reread
their door dropfiles on return from a door to
determine remaining time, like Wildcat! 3.x,
RemoteAccess, and so forth.
WeeklyPrize 0 See DailyPrize, above.
MonthlyPrize 0 See DailyPrize, above.
Note: if you leave the name of any particular bulletin blank, or do not
include the keyword for it in the configuration file, that bulletin will
not be created.
ERRORLEVELS
In case your BBS software reads and uses errorlevels on door exit, here
are the errorlevels Iron Ox returns:
0 - Critical Error has occurred!
1 - The user has dropped carrier.
2 - The sysop has terminated the call; user off-line.
3 - User time has expired; still on-line.
4 - Keyboard inactivity timeout; user off-line.
10 - Normal exit; user on-line.
255 - Program integrity problem; please check log and contact me!
LICENSE/REGISTRATION INFORMATION
This program is copyrighted shareware. You are licensed to try this
program for up to thirty days. After 30 days, if you elect to continue
using Iron Ox, you must register. The game costs only $20 (see
REGISTER.FRM for information on shipping and delivery options).
Note: If your registration for Iron Ox is postmarked *BEFORE SEPTEMBER 1,
1994*, you will receive a five-dollar discount on your registration!
The registered version of Iron Ox includes the following enhanced features:
1. OX FACTORY: Your colonies will no longer have to rely on the supply
of oxen provided at the beginning of the game. The game will use
ore from the store to make more.
2. EXTRA RACES: In registered versions of the game, three extra,
specialized races are available to players: the Photovore, a
sunlight-eating alien who specializes in plants and energy-making,
the Rubblemuncher, an amazing ore-miner who's allergic to luxite, and
the Metamorph, a creature who can actually *change shape* and assume
the abilities of different races during the course of the game.
3. MORE GAMES PER PLAYER: In the evaluation version, players are
allowed to play in three games at a time. In the registered version,
you may set this value as low or as high as you like.
4. TIME PRIZES: If you own the registered version and use BBS software
that "reads back messages" from doors, you can set (totally optional)
daily, weekly, and/or monthly time prizes for the leaders in the
standings! This feature works on Wildcat!, RemoteAccess, Apex,
QuickBBS, and many other systems.
5. FULLY ACTIVE EDITOR: In the unregistered version, the editor is
"read-only." Registration allows you to adjust values as well as
view them.
6. CONFIGURABLE GAME LENGTH: In the registered version, your players
can choose games shorter or longer than 14 turns (you set the bounds
for the shortest and longest games allowed). Great for boards where
users want to "play to the death." <g>
7. TROJAN OXEN: Trojan Oxen are a valuable defense against sabotage:
They look like ordinary oxen, but *fight back* if attacked. Very
helpful in cutthroat games.
Please see REGISTER.FRM to find out how to register your copy of Iron Ox.
Iron Ox is the product of over a thousand hours of work. I am committed
to supporting and improving Iron Ox (see "Future Plans" for some
indication of what I have in mind), but I need your help to continue
developing enhancements and new features.
ADDITIONAL LICENSE INFO
You are allowed (and encouraged) to distribute unmodified copies of
Iron Ox so long as you distribute the complete archive with all files
intact. You may include unmodified, complete archive versions of the
shareware edition of Iron Ox in software collections (e.g., CD-ROMs)
so long as the documentation for the collection clearly indicates that
it contains shareware products and that the purchase of the collection
does not constitute a license for the use of said products.
Registration of this product entitles you to a unique registration code
keyed to your name and the name of your BBS. This key will allow you
and your system's users to access the registered-only features of the
program, and will deactivate all messages to the effect that the program
is an "Unregistered Evaluation Copy." Your registration is good for all
future releases of Iron Ox: If I should ever need to change the key
system, you as a registered user will be entitled to receive a working
new key via U.S. Mail or electronic mail. Registrations are
non-transferable without my direct permission.
SUPPORT
I am anxious for your feedback and ideas. If you have problems getting
Iron Ox to run, please feel free to contact me.
I can be reached via crashmail or routed netmail at Fidonet address
1:202/704, DoorNet address 75:7619/7, and NeverNet address 42:100/107.
The support BBS for Iron Ox, and for all games by Joel Downer and
Meerkat Software Concepts, is The Dreaming City. The Dreaming City
has two lines:
Node 1: USR Dual HST 14.4/ v.32 9600 (619) 462-8406
Node 2: ZyXEL 16.8 v.32bis (619) 462-7146
I monitor the Fidonet DOORWARE, DOORGAMES and ON_LINE_GAMES conferences,
the San Diego NET202_IRONOX echo, and the NeverNet NN_IRONOX echo. I
will attempt to reply promptly to echo messages, netmail messages, and
messages in the IRONOX support conference on my BBS.
As of 5/25/94, I am working to get an IRONOX echo on the Fidonet
backbone. Request IRONOX from your Fidonet echomail hub for what I hope
will be an excellent source of support and a great place for players to
exchange information about the game. If IRONOX is not yet available
when you read this documentation, please ask your NEC to request that
your REC approve it for backbone status!
I can be reached via the Internet as joel@dreamcty.jd.com. For those
with Internet access, this approach may provide the fastest and most
reliable method of reporting problems or providing feedback except
Fidonet crashmail.
IRON OX DISTRIBUTION SITES
The following bulletin board systems are official distribution sites
for Iron Ox and any necessary companion programs. Note: this
information was compiled in May, 1994; some of these telephone numbers
will change over time. If you find that the numbers listed for systems
in your area are no longer accurate, you may be able to find up-to-date
information in a current FidoNet nodelist.
BBS System Fido Addr Telephone Modem Where
The Dreaming City 1:202/704 619-462-8406 USR Dual La Mesa, CA
TDC 2 1:202/705 619-462-7146 16.8 V.32bis La Mesa, CA
Alien Biker Kat 1:202/1010 619-277-4140 V.32bis San Diego, CA
Common Sense 1:161/705 510-713-7336 V.32bis Newark, CA
Comp. Connection 1:157/574 216-671-2574 21.6 Dual Cleveland, OH
The Harry Beast 1:343/102 206-859-6157 16.8 V.32bis Kent, WA
Hole in the Wall 1:104/651 303-841-5515 16.8K Dual Parker, CO
Holston River Vlly 1:3615/42 615-932-1490 16.8 Dual Knoxville, TN
Holston 2 1:3615/43 615-932-1492 16.8 Dual Knoxville, TN
Land of Gypsy's 1:105/18 503-297-0626 V.32bis Portland, OR
Mayberry BBS 1:3663/302 910-789-8183 28.8 Hayes Mt. Airy, NC
Programming Link 1:301/3 505-822-8944 V.32bis Albuquerque, NM
SHC Editor's 1:202/1819 619-563-1598 16.8 Dual San Diego, CA
The Sperm Bank 1:2604/203 201-847-0797 28.8 Zoom Wyckoff, NJ
Test Pattern BBS 1:259/524 905-890-2531 USR Dual Ontario, Canada
Unknown Gateway 1:318/7 505-784-3275 V.32bis Clovis, NM
Ruby's Joint 1:135/373 305-856-4897 28.8 Hayes Miami, Florida
The following files will be available for download, and for FREQ using
the magic names listed, from all of the distribution sites. The sites
will carry the latest version of Iron Ox and any support programs by
Joel Downer. Versions of support programs by other authors will be
recent but are not guaranteed to be the latest.
Magic Name Description
IRONOX The Iron Ox doorgame. (Surprised? <g>)
X00 A recent version of the X00 FOSSIL driver.
BNU A recent version of the BNU FOSSIL driver.
SIO A recent version of Ray Gwinn's FOSSIL for OS/2.
OXECHO Information on picking up the Iron Ox support echo.
FUTURE PLANS
I am committed to supporting this program. When and if I receive
reports of bugs, I will do my best to fix them and release updates
in a timely fashion.
I am currently testing a native OS/2 version of this program. Iron Ox/2
will include all of the features of Iron Ox for DOS, and will be a true
32-bit, multithreaded executable. Ox/2 should provide substantially
improved performance both for native OS/2 BBS systems and for DOS
systems running under OS/2's DOS compatibility. Registered owners of
Iron Ox for DOS will be able to request a registration key for Iron Ox
for OS/2 at no cost.
I also am planning to add new features and enhancements to the game --
which and how many depending on the feedback and level of enthusiasm
I encounter in the BBS community. Here are some examples of additions
that I am *considering* for future versions:
1. The option to steal from the Bank or the General Store.
2. Sysop-editable, variable messages for common game events (Received
from the Colony Physician: "If you need to spew, spew into this!").
3. A "depletion" feature by which players can exhaust the ore and/or
luxite in mining squares.
4. Full RIP graphics support, including a graphics-mode map with icons
and mousable game menus.
5. Support for multi-BBS "tournament mode."
6. Computer-controlled players with configurable levels of skill.
Your feedback will help to determine which and how many of these
features (and which features that *aren't* listed here) appear in future
versions of Iron Ox. Needless to say, your support will also make it
possible for me to continue work on this program.
DISCLAIMER
I make no warranty of any kind regarding the usefulness, reliability,
merchantability, or fitness of this software and documentation for any
purpose whatsoever. While I have tested this program thoroughly, I
cannot and will not make any promises that the program will run well or
safely on your hardware or with your particular software configuration.
This software is guaranteed only to take up disk space, and I make no
absolute guarantee that it will even do a reliable job of that. <g>
Your use of Iron Ox and/or any companion material constitutes your
acceptance of these terms.
ACKNOWLEDGEMENTS
As Iron Ox has been my first doorgame programming effort, I owe thanks to
many people for helping me through the process. Special thanks go to
Dan Roseen and Albin Gersich, two key beta sysops who also have
provided OpenDoors code patches and other programming suggestions that
have made this work much easier. Thanks to all of the version 1.00 beta
team, who, in addition to Dan and Albin, included: Marty Bogle, Jim
Chapman, Randy Culler, Brenda Donovan, Dave Foy, Paul Fusco, Dan Harvey,
Bud Jamison, and Christian Jones. Thanks, too, to my superb 1.10 beta
team: Marty Bogle, Jim Chapman, Randy Culler, Pax Dickinson, Mike
Fergione, Albin Gersich, Dan Harvey, Jay Jackson, Bud Jamison, Tom
Morgan, John Shepard, and Dan Smith. Many of the things that *do* work
right in the game are to the credit of these testers and their excellent
feedback. Naturally, any blame for anything that *doesn't* work is
mine. <g>
I've especially appreciated the feedback and encouragement of my key
testers on The Dreaming City, including Greg Allen, Andrew Crispen,
Lynn Kastleman, Bob Nelson, Sue Redding, Jeff Hobbs, and Bud Jamison.
(Yeah, Bud, you get to show up twice.) The enthusiasm I met on the
"home front" really made a difference. I appreciate the help of
everyone who was involved in the beta process and beta echo; several
participants in the IRONOX_BETA echo from other beta sites, including
Rich Paul, Chuck Eaves, and Mark Riel, deserve special mention. If
you were involved and I haven't mentioned you, please forgive me:
It's because I'm an addle-brained programmer, not because I didn't
appreciate your contribution. <g>
For ideas and assistance subsequent to the release of 1.00, special
thanks go to Andrew Crispen, who went above and beyond the call of duty
helping me distribute the game and who has made a number of valuable
suggestions for improving it. Thanks also to Jesse Quijano, who has
made a project of uploading the game to places that would be toll calls
for me. Most of the people thanked in the paragraphs above deserve to
be thanked again, but that would be pretty repetitive. <g>
Thanks to Gerard Droege for many stimulating conversations about
doorgames and game design, and to Evvie Vincow for putting up with me
and making countless glasses of iced tea.
This door uses the OpenDoors C development system by Brian Pirie. That
system has saved me countless worries about the details of talking to
the modem, reading dropfiles, etc., and I'd highly recommend it to
any C programmer writing a door. Starting with version 1.10, this door
also uses the superb MCOMM serial I/O library by Mike Dumdei. Thanks
also to the original authors of the Commodore 64 game, M.U.L.E. -- part
of the basic design of Iron Ox was inspired by that excellent game.
Finally, thanks to Gary Martin, Mehul Patel, and Joel Bergen. If I
weren't such a junkie for their games, I never would have started this
project.