home
***
CD-ROM
|
disk
|
FTP
|
other
***
search
/
OS/2 Shareware BBS: 2 BBS
/
02-BBS.zip
/
OX2V112.ZIP
/
OS2SYSOP.DOC
< prev
next >
Wrap
Text File
|
1994-08-11
|
48KB
|
951 lines
IRON OX Version 1.12 for OS/2
(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 for OS/2 is self-maintaining (no nightly maintenance event), and
is a multithreaded, 32-bit OS/2 text mode executable, with the following
"sysop-friendly" features:
* Built-in multinode support (so several people can play at one time).
* A sophisticated internode messaging/chat system (currently only
available in Iron Ox for OS/2, not Iron Ox for DOS).
* The ability to use a comm handle or a port name.
* The ability to run from DOS bulletin board systems running in the OS/2
DOS box (as well as from native OS/2 BBS software).
* Complete data file compatibility with Iron Ox for DOS.
* Support for a wide variety of door drop files (including DOOR.SYS,
DORINFO?.DEF, EXITINFO.BBS, CHAIN.TXT, CALLINFO.BBS, and SFDOORS.DAT).
* Comprehensive high-score and record listing with optional ANSI, ASCII,
and WC-code bulletins.
* "Nice" and "Nasty" modes to ensure good behavior on all-native systems
and decent performance on systems that run DOS comm software and
non-timeslicing doors.
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 copying the file called
SAMPLE.CFG to the name IRONOX.CFG and typing IRONOX -LOCAL from the
directory where you have unpacked the archive.
REQUIREMENTS
Iron Ox for OS/2 requires a minimum of 750K free disk space; depending
on the number of active games, it may take up as much as 1,500K of hard
disk space. In case you haven't guessed, it requires OS/2. <g> It has
been tested extensively with version 2.10 and 2.11 (both OS/2 original
edition and OS/2 Special Edition for Windows). Compatibility with
previous versions is not guaranteed.
Ox/2 requires that serial device support be installed on the host
computer. If you wish to run Ox/2 from a DOS BBS in the OS/2 DOS box,
you must be using SIO/VSIO or another driver that allows serial ports to
be shared between OS/2 and DOS sessions (COM.SYS and VCOM.SYS do not).
(See RUNNING FROM A DOS BBS, below, for more information.)
Even if you are running all native OS/2 software, a high-performance
serial driver (like SIO) is recommended for optimal performance.
Drivers for Digiboards or other specialized hardware should work fine so
long as they're API-compatible with COM.SYS.
Ox/2 does not need or use FOSSIL drivers, MAXCOMM.DLL, or other serial
service packages.
INSTALLING IRON OX
Instructions for installing Iron Ox are divided into two parts -- general
directions (which apply to all systems), and specific installation notes
for three different categories of bulletin board system: native OS/2
boards that write comm handles to dropfiles, native OS/2 boards that
write port names, and DOS boards running under OS/2. If you're
confused, read on and the way should become clear.
GENERAL DIRECTIONS
1. Decompress the Ox/2 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. Create a configuration file. If you're running a single-node board,
the game is unregistered, and you don't care about creating
ASCII/ANSI bulletins, just rename the file SAMPLE.CFG to the name
IRONOX.CFG. Otherwise, run the program called OXCONFIG.EXE to create
a configuration file. IMPORTANT: If you're running multinode and
you want to make multinode messages and chat available to your users,
you should run OXConfig and visit the "Multinode Options Menu."
3. Create a batch file or command script by which your BBS can start
Iron Ox. Most of the time, this script 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 are running multinode with BBS software that doesn't include
the node number in the door information file,
(b) you use a number of different door drop files, and you want to
tell Iron Ox which one to use, or
(c) you wish to tune the performance of Ox on your system using the
/NICE or /NASTY parameters.
In general, the considerations listed under (a) and (b) don't come up
for systems using DOOR.SYS, SFDOORS.DAT, CHAIN.TXT, or CALLINFO.BBS.
They are most likely to be issues for people running DORINFO systems.
NOTES FOR MAXIMUS-STYLE NATIVE OS/2 SYSTEMS
One important distinction among OS/2 BBS'es is between systems (like
Max/2) that trade in comm handles and systems (like Lora) that trade in
port names. By default, Iron Ox/2 assumes that it is running on a
Maximus-style system.
Here is a sample menu entry for running Ox on a single-node Maximus
system:
From Menus.Ctl
Display_File C:\Max\Misc\Dorinfo Normal "Run Iron Ox/2"
NoDsp Xtern_Dos C:\Door\IronOx\IronOx.exe Normal "R"
No batch/script file is required. The Dorinfo script included with
Max/2 works fine.
Here are sample command files for running Ox/2 on a multinode Maximus
system, courtesy of Nancy Porter, sysop of Land of the Gypsy's BBS:
DORINFO.MEC
(This script is the same as the sample script that comes with Max,
except that it writes unique dropfiles based on the node number. It
requires that you create a node work directory for each of your node
numbers, e.g. "C:\Max\Misc\1", "C:\Max\Misc\2", and so forth.)
[delete]C:\Max\Misc\%k\Dorinfo%k.Def
[open]C:\Max\Misc\%k\Dorinfo%k.Def
[write]%N[ comment Write the BBS name ]
[write]%S[ comment Write the SysOp's first name ]
[write]%s[ comment Write the SysOp's last name ]
[islocal write]COM0[ comment Write the COM port ]
[isremote write]COM%P[comment (local is always COM0) ]
[write]%b BAUD,N,8,1[comment Write the baud rate ]
[write] 0[ comment Say that we're not networked ]
[write]%A[ comment Write the user's first name ]
[write]%B[ comment Write the user's last name ]
[write]%c[ comment Write the user's city ]
[write]%g[ comment Write the user's graphics ]
[sequal write]100[ comment Write the user's security level]
[sxclude write]50[ comment Ditto ]
[write]%t[ comment Write the user's time remaining]
[write]-1[ comment Say that we're using a FOSSIL ]
[quit comment And we're done! ]
From Menus.Ctl:
Display_File Misc\Dorinfo Normal "Iron Ox"
NoDsp xtern_dos \Games\Ironox\ox.cmd_%k_%A_%B Normal "I"
IRONOX.CMD:
C:\MAX\IPC-2 %1 "%2 %3" "Playing IronOx for OS/2"
C:\GAMES\IRONOX\IRONOX.EXE C:\MAX\MISC\%1\
Note: Depending on the configuration of your system, you may wish to
try using the /NICE parameter. See the section on command-line
arguments, below. You should only need to consider using the /NASTY
parameter if your users spend a lot of time in ill-behaved DOS doors.
NOTES FOR OS/2 BOARDS THAT USE PORT NAMES
I don't know much about the OS/2 BBS package Lora, but my understanding
from one of my beta sites is that it (like DOS BBS systems) writes the
name of the correct port to a dropfile rather than the number
corresponding to a comm handle. If this is true of your BBS software,
you will need to use the command-line argument /PORT to indicate to Iron
Ox that it will need to open a serial port. Thus:
C:\DOOR\IRONOX\IRONOX.EXE /PORT
If you are sure your BBS software writes a port name to its dropfiles,
you use the /PORT command-line option, *and* Iron Ox has trouble opening
the comm port anyway, be sure that you have your serial driver
configured to allow sharing of comm ports between sessions (with SIO,
you would need to use the "-" parameter, described in the section
below). I have trouble believing that a BBS package would write a port
name without closing the port before spawning doors, but it's a strange
world. <g>
The Maximus examples above should provide general information on batch
files and menu configuration. If you have more specific advice and/or
an example configuration and you'd like to contribute it, I would be
happy to "beef up" this section for future versions.
Note: Depending on the configuration of your system, you may wish to
try using the /NICE parameter. See the section on command-line
arguments, below. You should only need to consider using the /NASTY
parameter if your users spend a lot of time in ill-behaved DOS doors.
NOTES FOR RUNNING AN OS/2 DOOR FROM A DOS BBS (!)
If you are running a DOS BBS under OS/2, you should be able to take
advantage of the enhanced features and performance of Iron Ox for OS/2.
My BBS regularly bounces back between OS/2 and DOS, so the highest
possible degree of compatibility was a big priority for me in designing
the OS/2 version of this game.
The following approach is not guaranteed to work on your system, much
less to generate responsive performance on heavily loaded multinode
systems. On one hand, if you run a single-node DOS BBS system under
OS/2, and you're concerned about CPU load -- say, because you run other
tasks on the same machine, and the BBS makes things sluggish -- you may
find yourself rooting for people to go into Ox/2 so you can get some
work done. <g>
On the other hand, if you run a multinode system with tons of
non-timeslicing DOS doors, you may find that you have to run Ox in
/NASTY mode and that you don't get the same benefits you would if Ox had
better-behaved "neighbors" and you could run it in /NICE mode.
To run Ox/2 from a DOS BBS, you must be using Ray Gwinn's SIO or
compatible drivers (COMM.SYS/VCOMM.SYS will not work). Recent versions
of SIO, working with OS/2 2.1x, will allow OS/2 and DOS sessions to
share a comm port. SIO must be loaded with the "-" parameter, which
allows port-sharing, and you must have the "Share comm port with OS/2
Sessions" option turned on in the DOS Sessions Settings for the session
in which you run your BBS.
To spawn OS/2 sessions from your DOS BBS, you will need OS2EXEC or a
similar utility. OS2EXEC creates OS/2 sessions that wait on commands
from DOS sessions; you run the door by telling OS2EXEC to execute
IRONOX.EXE.
Both OS2EXEC and SIO are available for FREQ and download from any of the
sites listed in "IRON OX DISTRIBUTION SITES," below.
So, with requirements and caveats stated, let's get to batch files and
configuration information. First of all, I have a startup .CMD file as
follows:
REM Start "Daemon" sessions for each of my three BBS nodes
START /FS OS2EXECD
START /FS OS2EXECD
START /FS OS2EXECD
REM End of startup .CMD
My Wildcat! batch file is very straightforward:
OS2EXEC C:\DOOR\IRONOX\IRONOX.EXE /PORT
If you are running a DORINFO system, you may need to use the /N
parameter. If Ox has trouble finding your dropfile, you may need to
specify it on the command line. See the general installation
instructions, above, and the information on command-line arguments,
below.
If you run a multinode system with high-speed lines and/or
non-timeslicing comm software (in other words, if there are other tasks
that eat up lots of CPU time when players will be in Iron Ox) you may
need to try the /NASTY parameter. See the section on command-line
parameters, below.
MULTINODE SETUP
Ox/2 has a rich set of multinode options, including internode messages
and chat. The internode communication system takes advantage of named
pipes, a powerful OS/2 inter-process communication mechanism.
To configure the game for optimum performance on your system, you may
need to run OXConfig and access the multinode options menu. If you are
running more than ten nodes, you will need to tell Ox your highest node
number so that it knows how many pipes to look for. If you are running
an OS/2 LAN, you will need to tell Ox the name of your server so that it
can create the named pipes over the network. See the online
documentation for (H)ighest Node Number and (P)ipe Name, or the
appropriate sections under "CONFIGURING IRON OX," below.
Iron Ox was written and tested from the ground up to run multinode.
Except as explained above, 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. Thanks to the robust
device driver model under OS/2, the operating system takes care of
issues like non-standard IRQ's.
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>)
To set up the game for multinode play, create batch files or command
scripts for each node along the lines in the single-node instructions.
The only time different nodes will need *different* batch files is when
the game is run across a LAN on which the drive letter for the game
directory is different for different nodes.
(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," below.)
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.
COMMAND-LINE ARGUMENTS
Iron Ox/2 supports the following command-line arguments:
/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.
/LOCAL This argument indicates that Iron Ox should run in local
mode and prompt for user name instead of looking for a
dropfile. In general, the /LOCAL parameter is just for
"test-driving" the game when it is not installed on a BBS.
When you are running from your BBS (even from a local
node), you will want to use a dropfile rather than the
/LOCAL parameter. If you do choose to use the /LOCAL flag
on a local node of your BBS, be aware that a copy of the
game loaded with /LOCAL defaults to node 1. Unless your
local node happens to be node 1 on your BBS, you will need
to use the /N parameter to specify the correct node.
/NASTY I learned during beta testing that systems running OS/2
BBS'es can be gentle and friendly places where all software
cooperates and shares the CPU; others can be war zones
where CPU-hungry DOS doors starve the rest of the system.
The /NASTY parameter warns Iron Ox that it's running in one
of those "war zones," and that it needs to set its thread
priorities very high to compete with the "bullies."
You should probably not use this parameter unless you get
complaints about Ox running very slowly and/or you know you
run lots of non-timeslicing DOS doors.
/NICE The /NICE parameter is the natural counterpart of the
/NASTY parameter, documented above. Using the /NICE
parameter indicates to Ox that it's running in a friendly
environment and that it can rely on CPU idle time to do
things like refresh the screen and dump output to the comm
driver.
On all-native systems or single-node systems with a light
CPU load, using /NICE should make for better performance
with substantially less CPU load. This option is almost
guaranteed, however, to provide miserable performance on
multinode systems running DOS BBS software and/or
non-timeslicing DOS doors.
Note: By default, Iron Ox is neither /NICE nor /NASTY: it
uses moderate thread priorities. Many sysops will need
neither the /NICE nor the /NASTY parameter; the parameters
are included to give sysops more control over game
performance.
/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.
[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.
/PORT By default, Ox/2 expects to find a Max/2-style comm handle
in its door information file. If you're running a BBS
program that places the comm port name in the dropfile
(like any DOS BBS and some OS/2 BBS systems), you will need
to include this parameter.
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. If you're not, you'll need to specify
the dropfile directory on the command line.
2. The game works fine locally, but doesn't work over a modem!
If you're using the /PORT parameter, try removing it. If you're not
using it, give it a try. Next, try the advice in (1), above -- the
real problem may be that the program is finding the wrong dropfile
and trying to open the wrong port. If none of the above helps,
contact me and we'll see what we can figure out.
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.
MaxNodes 10 By default, the Iron Ox messaging system will
look for up to ten active nodes (including the
node on which the game is running) when it is
searching for other players in the game. This
option allows you to specify more or fewer
nodes, or to disable messaging altogether.
If you are running substantially fewer than ten
nodes, specifying the correct number can save a
few clock cycles and a very small amount of
memory when Ox initializes. If you are running
more than ten nodes, you will need to specify
the correct number for Ox to send messages
correctly. If you wish to disable internode
messaging (e.g., because it's not behaving
properly, or because you never have more than
one node in the game at a time), set this value
to zero.
PipeName By default, each Iron Ox node will create a
named pipe for each node using the format
"\PIPES\OXPIPE" and the node number (thus, Node
One would create "\PIPES\OXPIPE.1"). If you are
running your system across an OS/2 LAN, you will
need to adjust this path to include the name of
your server. For example, if your server is
named BBSSERV, you should enter:
\BBSSERV\PIPES\OXPIPE
as the format for creating pipes. If you are
not running a LAN, you should only adjust this
value on the very unlikely possibility that some
other program is trying to create pipes with the
same names.
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 for DOS is the product of over a thousand hours of work.
Porting Ox to OS/2 has consumed hundreds more, and I have the
feeling that this will be a "never-ending" project. <g> 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 entitles you to
use both Iron Ox for DOS and Iron Ox for OS/2, and 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 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 and DoorNet address 75:7619/7.
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,
and the San Diego NET202_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 6/27/94, the IRONOX echo has just been approved for addition to
the FidoNet backbone. By the time you read this, if you are a Fido
sysop, you should be able to 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.
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 latest version of Iron Ox for DOS.
OX2 The latest version of Iron Ox for OS/2.
OS2EXEC A recent version of OS2EXEC (Needed for Ox/2 w/ DOS BBS).
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.
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 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
Porting a doorgame consisting of more than 50,000 lines of code is quite
probably not the easiest way to learn OS/2 programming. <g> This first
development cycle has been an adventure and (sometimes) an ordeal, for
me and for my beta sites. I have to single out Nancy Porter, whose BBS
has taken the brunt of several of my ugliest mistakes, but warm thanks
go to all of my beta testers, including Mike Burgett, Micheal Cody, Wes
Landaker, Pete Link, Jerry McBride, and Scott Wilkos.
Special thanks go to Craig Swanson, a widely-recognized OS/2 guru whose
patient, persuasive arguments got me interested in OS/2 in the first
place and whose advice has really helped this project along. Thanks
also to Peter Fitzsimmons, who provided some excellent suggestions on
video optimization in the FidoNet OS2PROG echo.
For version 1.12, I owe special thanks to Brad Jackson, Paul Sidorsky,
Scott Kuntzelman, Greg Rumple, and Pete Norloff for bug reports and
feedback.
I always owe appreciation to Evvie Vincow for support and an arbitrarily
large number of glasses of iced tea. On The Dreaming City, Andrew
Crispen, Greg Allen, Sandy Jones, and Buck Jones have provided excellent
feedback on my work.
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.
Iron Ox for DOS uses the OpenDoors C development system by Brian Pirie.
Iron Ox for OS/2 uses a multithreaded port of this code.