OS/2 Shareware BBS: 2 BBS

home *** CD-ROM | disk | FTP | other *** search

/ OS/2 Shareware BBS: 2 BBS / 02-BBS.zip / ox2v201.zip / OS2SYSOP.DOC < prev next >

Wrap

Text File | 1995-01-12 | 56KB | 1,111 lines

IRON OX Version 2.01 for OS/2 (C)opyright 1994, Joel Downer SUMMARY Iron Ox is an interactive, multiuser strategy door revolving around the development of an outer space colony world. Players claim land, produce four different commodities, trade with the store and with other players, form alliances with or play a variety of dirty tricks on one another, and struggle for survival and prosperity on a harsh, new planet. Players can choose from nine different races and a variety of strategies ranging from friendly and cooperative to brutal and cutthroat. Iron Ox games support from one human player (playing against the computer) to a maximum of eight. Individual games may last anywhere from a week up to several months, depending on the preferences of the players. The door supports up to 255 active games involving up to 255 active players. As of version 2.00, Iron Ox now includes computer- controlled players, so that lively games can take place even on very small BBS'es. The game also includes player-selectable difficulty levels, so that everyone from the complete novice to the seasoned veteran can find a fair challenge. 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: * Five-minute setup with a one-line batch file on most systems, * Built-in multinode support (so several people can play at one time). * A sophisticated internode messaging/chat system. * 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, do ASCII art, or create disgusting recipes -- but it also involves complex strategy and intense competition. The door requires that players have ANSI terminals, but does not require a color monitor on the sysop or player end. 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 at its best with multiple players. However, if you like to get acquainted with a game before installing it, you can easily do so by playing a game against the computer. Just decompress the game into its own directory, create a default configuration file by typing C:\IRONOX>COPY SAMPLE.CFG IRONOX.CFG and then run the game by typing C:\IRONOX>IRONOX -LOCAL To try out a game, use the (S)tart command to create a new game and the (P)lay command to play turns. REQUIREMENTS Iron Ox for OS/2 requires a minimum of 1,000K free disk space; depending on the number of active games, it may take up as much as 2,000K of hard disk space. In case you haven't guessed, it requires OS/2. <g> It has been tested extensively with version 2.10, 2.11, and OS/2 Warp 3.00. 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. It does require the Doors/2 door library, DRS2V5B2.DLL, which is included in the Ox/2 distribution archive. 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. 4. Copy the Doors/2 library, DRS2V5B2.DLL, to a directory on your LIBPATH. (Your LIBPATH is defined in CONFIG.SYS; I typically use the \OS2\DLL\ directory on my boot drive.) This will allow Ox/2, and any other program using the Doors/2 interface, to find the library file. 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 (see the information on multinode setup for an important exception). 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:\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're sure your BBS software writes a port name to its dropfiles, you are using the /PORT command-line option, and Iron Ox has trouble opening the comm port anyway, double-check 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 and above, 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.) IMPORTANT NOTE: If you are running a Max/2 system with node numbers higher than nine, I recommend that you either (a) use a dropfile other than DORINFOx.DEF, or (b) modify your DORINFO.MEC script so that it names the dropfile DORINFO1.DEF for all nodes rather than DORINFO%k.DEF. Max/2 uses a naming convention for DORINFO files above node 9 (e.g., DORINFO11.DEF) that is contrary to the DORINFO standard and is currently unsupported by Ox. 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 ever need to clear the lockfiles manually, you can do so by typing "DEL C:\DOOR\IRONOX\*.L*" (though this will delete your Iron Ox logfiles, too...). 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. IMPORTANT: One feature in the editor will work in both the registered and unregistered game. If a particular game is misbehaving and you are unable to correct the problem, you can delete it from the door using the (N)uke Game option. Please use this option to delete games rather than physically deleting the game file from disk! 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 meets the minimum requirements to begin. 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. Most of the configuration options in the game are editable from OXConfig. For information on further customizing your game (modifying AI player names, contest names, and who is eligible for time prizes), see the section on CUSTOMIZATION, below. 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. Door/Interface Configuration Keyword Default Function MaxNodes 10 Iron Ox has a messaging system that allows internode messages and multiplayer chat. This system works for nodes on a single machine and for nodes distributed across a LAN. By default, Ox tests for ten active nodes. If you have more than ten nodes, you should set this value to your highest node number. If you have fewer, lowering this value will improve performance and save memory. To disable messaging, set this value to zero. 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). 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. 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. 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. Game/Playability Options AWOLDays 5 If a player doesn't play Ox regularly, he/she will get hopelessly behind and slow down the game. Players who miss the number of consecutive turns you specify here will be removed from the game. Depending on the configuration selected by the game's creator, the player's character will be killed or taken over by the computer. The recommended default is five days. Entering "0" disables AWOL-checking. 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. MaxTurns MaxGames x 2 When playing entirely against AI's, people can play entire games in a single day. When such games are uncontrolled, whoever spends the most time in the door will usually have the highest score. This setting limits the total turns (across all Ox games) a player can play per day. The recommended default setting is two times max games per player. (The game will autocalculate this value unless you enter a specific number for MaxTurns.) Allowing unlimited turns is appropriate for a learning/practice door. To allow unlimited turns when editing your configuration file manually, enter -1 for MaxTurns. MinGameLength 7 In the registered version of Iron Ox, players MaxGameLength 99 may select games shorter or longer than 14 turns. These variables set bounds on game length. In version 1.x of Ox, map size was fixed at 5x12 plots, so games over 18 turns weren't much fun. With the current version's support for maps up to 55x12 plots, the new defaults of 7 turns minimum and 99 turns maximum work beautifully. MinHumanPlayers 1 You may wish to limit the impact of computer players by requiring multiple human players in each game. Requiring only one human player allows games completely against the computer. Solo games are good for new players because they allow rapid feedback. However, the best Iron Ox games always involve multiple human players. A setting of one is recommended for an initial installation. Settings of two and three are more appropriate for an established game. PenaltyPct 10 Because new players can get in a hole quickly, Iron Ox allows players to resign from individual games. The players can then join new games where they have a better chance, but their monthly score is docked by a fixed percentage for each game they quit. The default setting of 10 (a 10% penalty) is recommended for this option. Entering "0" disables penalties. 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. Bulletin Options 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. Keyword Default Function ANSI_Records (blank) Name and path of the ANSI all-time-records bulletin. 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_Records (blank) Name and path of the ASCII records bulletin. ASCII_Score (blank) Name and path of the ASCII high score bulletin. WC_Records (blank) Name and path of the WC-style records bulletin. WC_Score (blank) Name and path of score bulletin using Wildcat!- style @ codes. Registration Options Keyword Default Function 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," below. 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. 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. Time Prize/Score Reset Options Keyword Default Function 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. 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. CUSTOMIZING The following information is for "power users" only. <g> None of the customization described in this section is strictly necessary. Iron Ox reads and uses three ASCII text files in your IRONOX directory other than IRONOX.CFG: 1. CONTESTS.TXT -- This file is a straightforward list of the titles used for the Colony Cultural Competition. By default, it includes the following entries: Bad Poetry (Clean) Limerick ASCII Art Annoying Pun Political Tirade Interesting Trivia So long as you leave at least one choice on the list, you may add or delete entries as you like (Ox chooses randomly from the entries on the list whenever it creates the game). The maximum length for contest names is 30 characters. 2. AUTONAME.TXT -- This file contains the player names Ox chooses from when creating AI players. As with CONTESTS.TXT, you can add, change, and delete entries freely, though you need to have at least eight names in the file. Aliases have a maximum length of 30 characters. 3. EXCLUDES.TXT -- This file is not included in your Iron Ox archive -- if you want it, you need to create it. In the registered version of Ox, the game can award time prizes to the player with the highest daily, weekly, and monthly score. Obviously, users with extremely large daily time limits (the sysop and any co-sysops) have no need for time prizes. By excluding such people from contention for time prizes, you can stimulate more interest in the prizes. EXCLUDES.TXT can include up to ten names (one per line, ASCII text) of people to be excluded from winning time prizes. 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 30 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). The registered version of Iron Ox includes the following enhanced features: 1. 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). That means more action, more interaction, and more excitement! 2. 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. 3. 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. 4. 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. 5. 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! (3.x USERINFO.DAT and 4.x SYSINFO.DAT), RemoteAccess, Apex, and QuickBBS (EXITINFO.BBS), and many other systems. 6. FULLY ACTIVE EDITOR: In the unregistered version, the editor is "read-only." Registration allows you to adjust values as well as view them. 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 and Iron Ox for OS/2: 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. I am also reachable via the Internet as joel@dreamcty.jd.com. I poll my Internet feed, so crashmail is faster. The support BBS for Iron Ox, and for all software by Joel Downer, 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 am moderator of the Fidonet IRONOX echo, which is distributed via the Zone 1 echomail backbone. This echo is an excellent source of support as well as a good place for your callers to get tips and strategy hints about the game. I also monitor the Fidonet DOORWARE, DOORGAMES and ON_LINE_GAMES conferences for *personal* mail (please address it to "JOEL DOWNER" if you want a reply from me!). I will attempt to reply promptly to echo messages, netmail/e-mail messages, and messages in the IRONOX LOCAL SUPPORT conference on my BBS. A NOTE (SHAMELESS PLUG) ON DEVELOPMENT LIBRARIES Iron Ox for OS/2 was developed using Doors/2, a multithreaded, 32-bit port of Brian Pirie's OpenDoors library for DOS. Doors/2 allows a developer to port a DOS door to OS/2 with little more than a recompile. The file DRS2V5B2.DLL, in the Ox distribution archive, is the dynamic-link version of this library. Doors/2 is a shareware product. If you are a C developer, and you're interested in producing OS/2 door software, your doors can benefit from the same multithreaded performance, chat capabilities, internode messaging, and BBS interface as Iron Ox. Look for a copy of DRS2V5B*.ZIP for more information! (The latest version is available for download by name, or for FREQ as DOORS2, from The Dreaming City, listed below.) 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 December, 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/746 619-277-4140 Zoom 28.8 San Diego, CA Common Sense 1:215/705 510-713-7336 USR HST/V.34 Newark, CA Comp. Connection 1:157/574 216-671-2574 V.FC Cleveland, OH C.R.I.S.I.S. HQ 1:134/31 403-686-0449 V.FC Calgary, Alberta The Harry Beast 1:343/102 206-859-6157 V.32bis Kent, WA Hole in the Wall 1:104/651 303-841-5515 USR HST/V.34 Parker, CO Holston River Vlly 1:3615/42 615-932-1490 USR HST/V.34 Knoxville, TN Holston 2 1:3615/43 615-932-1492 USR HST/V.34 Knoxville, TN Land of Gypsy's 1:3800/39 504-923-3053 V.32bis Baton Rouge, LA Mayberry BBS 1:3663/302 910-789-8183 28.8 Hayes Mt. Airy, NC Programming Link 1:301/3 505-822-8944 USR HST/V.34 Albuquerque, NM Ruby's Joint 1:112/129 904-777-6799 28.8 Hayes Jacksonville, FL Test Pattern BBS 1:259/524 905-890-2531 16.8 Dual Ontario, Canada Unknown Gateway 1:318/7 505-784-3275 V.FC Clovis, NM 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. Full RIP graphics support, including a graphics-mode map with icons and mousable game menus. 4. Support for multi-BBS "tournament mode." 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 When I first began planning for this generation of Iron Ox, my goal was to produce a focused release including computer-controlled players and, as I put it at the time, "one or two minor goodies." Obviously, the scope of the project ballooned from there to include a half-dozen other major features. I owe my deepest thanks to a number of people for helping me make this project work. Special mention goes to Andrew Crispen, a local tester who has spent an unthinkable number of hours playing the game in local mode and has provided scores of bug reports and playability suggestions. Andrew has also written a strategy guide to the game, OXTIPx.TXT, which I wholeheartedly recommend (even though I wish he hadn't given away so many of my secrets <g>). Greg Allen, Sandy Jones, Jessie Martin, Mark Zidel and Karen Goza also provided great feedback on TDC. I'm also deeply indebted to my beta testers, Mike Burgett, Micheal Cody, Brad Jackson, Scott Kuntzelman, Wes Landaker, Nancy Porter, Paul Sidorsky, Nicholas Balog, Randy Culler, Mike Fergione, Albin Gersich, Dan Harvey, Bob Haw, Jay Jackson, Bud Jamison, Tom Morgan, 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> 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 always to Evvie Vincow for putting up with me and making countless glasses of iced tea. Iron Ox for DOS 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. Iron Ox for OS/2 uses the Doors/2 development system, a multithreaded port of OpenDoors. Thanks to Brian for allowing me to develop and distribute that library. 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.