DP Tool Club 15

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

/ DP Tool Club 15 / CD_ASCQ_15_070894.iso / vrac / oxv111.zip / SYSOP.DOC < prev next >

Wrap

Text File | 1994-06-17 | 42KB | 809 lines

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