OS/2 Shareware BBS: 2 BBS

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.