OS/2 Shareware BBS: 2 BBS

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

/ OS/2 Shareware BBS: 2 BBS / 02-BBS.zip / ox2v300.zip / SYSOP.DOC < prev next >

Wrap

Text File | 1996-05-17 | 51KB | 1,050 lines

IRON OX Version 3.00 (C)opyright 1993-1996, Joel W. Downer Support BBS: Fido 1:202/704, 619-462-8406/462-7146 Inquiries: joel@dreamcty.cts.com CONTENTS This documentation file includes the following sections: SUMMARY What this door is and why you want it! EVALUATION VERSION Shareware notice; evaluation terms COMPATIBILITY/REQUIREMENTS What you need to run this program INSTALLING THE GAME How to get the game running TRYING OUT THE GAME How to take a look at this door IRON OX AND YOUR BBS Getting the game working from your BBS COMMAND-LINE ARGUMENTS List of options accepted by the program MULTINODE SETUP Special issues for multinode sysops COMMON PROBLEMS Please read *before* calling me at 3 AM <g> CONFIGURING IRON OX Customizing your IRONOX.CFG file EXTERNAL PROTOCOLS Setting up external protocols with Iron Ox MAINTAINING IRON OX To keep the door running over time... CUSTOMIZING Touching up the program to your taste ERRORLEVELS Information for tech geek sysops <g> LICENSE/REG. INFORMATION How to register your copy of Iron Ox! ADDITIONAL LICENSE INFO Info on distributing/licensing this door FUTURE PLANS Some information about what lies ahead SUPPORT Where to get more help! DISTRIBUTION SITES Where to find the latest version. OTHER SOFTWARE BY JOEL DOWNER If you like Iron Ox.... DISCLAIMER Boilerplate courtesy of legal dept. <g> ACKNOWLEDGEMENTS The names of a few heroes/heroines SUMMARY Iron Ox is an interactive strategy game intended to be run as a BBS external program (door). The players have been sent against their will to an untamed alien world: they start with their bare hands, a few automated "iron oxen" to help them build things, and a small pack of cybernetically modified dogs ("cybermutts") to protect them. Will your callers work together to master the world and build a flourishing civilization, with roads and freeways and a powerful economy? Or will they destroy each other and the planet beneath their feet as they struggle for dominance? And what about neighboring worlds? Rumors brew that the other colonies are building armies ... if war erupts, will your BBS's callers be ready? Iron Ox is a rich game, with exciting features like: * RIP graphics support, with beautiful art and (optional) local RIP! * five-minute setup with a one-line batch file on most systems, * detection and timeslicing for DESQview, Windows, and OS/2, * full multinode support, with real-time chat, messaging, and combat! * 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, * a native, 32-bit OS/2 version available, * purchasable drones that work the land and fight in real time, and * full InterBBS league support, including IBBS attacks and ops! 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. Thanks for evaluating Iron Ox! COMPATIBILITY/REQUIREMENTS The DOS version of Iron Ox requires about 400k of memory to run in text mode, and about 450k to run with local graphics. (Having more memory, and some EMS memory available, will make it run faster.) Iron Ox requires a minimum 286 or better CPU, and a 386 or better is recommended for best performance. On slower systems, you may wish to adjust "Drone Cycles" in OxConfig (slowing down the computer-controlled characters) to reduce the delay between moves. On a fast 486 or Pentium system, you may actually want to *increase* the speed of the drones for more exciting real-time action. :-) Running Iron Ox in graphics mode (with the /LRIP parameter) requires a monitor with EGA or better graphics support. The game will work fine on any sort of monitor running without the /LRIP parameter. Local graphics will work under DESQview and other DOS multitaskers, but using graphics on multitasking multinode systems is not recommended. In particular, having two or more sessions on one machine trying to do local graphics at the same time is a bad idea. Iron Ox (for DOS or OS/2) requires a minimum of 1.5 megabytes of disk space. When running with local graphics, it may consume another 200-350k of space for temporary icon storage. A hard disk is required. The DOS version runs under (and gives up timeslices to) DESQview, Windows, and OS/2. (If you're running OS/2, though, you'll probably want Iron Ox for OS/2.) The DOS version 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. Support for some specialized requirements (DigiBoards, shared IRQ's) is provided in the DOS version through the FOSSIL standard. Recent versions of several popular FOSSIL drivers are available through the support BBS. If you're running the OS/2 version of the door, don't worry about any of these issues: your device driver will take care of them. Iron Ox requires that the remote user (your caller) have ANSI, AVATAR, or RIP graphics, but does not require special drivers on the sysop end. INSTALLING THE GAME This section describes how to set up Iron Ox in single-BBS mode. If you're setting up Iron Ox for interBBS league play, see INTERBBS.DOC for instructions. Here's what it takes to install Iron Ox: 1. Unpack the Iron Ox archive into its own directory (all of the examples in this .DOC file assume you've used C:\DOOR\IRONOX, but any directory will do). 2. Run INSTALL.BAT (INSTALL.CMD under OS/2) and follow the instructions that appear on the screen. (In case you want to recreate these steps manually, INSTALL.BAT/INSTALL.CMD runs OxConfig to create your configuration file and your batch file and then runs IRONOX /RESET to create a new Iron Ox game.) 3. Be sure to say "Yes" to the questions about saving your configuration file and creating a new game. Otherwise, though, you can mostly just accept all the defaults at this point. (You can always go into OxConfig later and fine-tune your configuration.) If you have an external protocol like DSZ (DOS) or CEXYZ/2 (OS/2) installed, be sure to visit General Settings|General Config in OxConfig and set the pathname for your external protocol so Ox can automatically send RIP icon files to RIP terminal users. At the end, the installation process displays some instructions on the screen about adding Iron Ox to your BBS. You can follow those instructions now, or wait until you've "previewed" Ox as described in the next section. TRYING OUT THE GAME Iron Ox is at its best with multiple players. However, if you like to get acquainted with a game before offering it to your callers, you can easily play a few turns on your own to see what it feels like. After you've set up the game as described under "INSTALLING THE GAME," above, just access the game locally by typing: C:\IRONOX>IRONOX -LOCAL If you're running the DOS version of Iron Ox and you have an EGA monitor or better, you can have graphics by using this command-line instead: C:\IRONOX>IRONOX -LOCAL -LRIP When you're done playing a turn, you can advance to a new turn using: C:\IRONOX>IRONOX -MAINT IRON OX AND YOUR BBS If you've gotten this far, I assume that you liked what you saw when you followed the "TRYING OUT THE GAME" instructions. Great! Now, let's get Iron Ox working as a door on your BBS. This section includes three subsections: getting Ox for DOS to work with a DOS BBS, getting the OS/2 version to work with an OS/2 BBS, and using the OS/2 version with a DOS BBS running in the OS/2 DOS box. (Whew! That was a mouthful. <g>) Make sure you understand which situation applies to you and that you have the right version for your operating system, because the differences are important. Iron Ox for DOS and a DOS BBS: Here are the key steps to installing Iron Ox for DOS: 1. Create a batch file your BBS can use to start the door. The easiest way to do this is to use the "Make Batch File" option in OxConfig. If you need to build a batch file manually from scratch (say, because the one OxConfig creates isn't working for you), start with this: C:\DOOR\IRONOX\IRONOX.EXE If you want local RIP graphics and you have an EGA monitor or better, it'll look more like this: C:\DOOR\IRONOX\IRONOX.EXE -LRIP If you are running a multinode DORINFOx.DEF BBS, if your BBS doesn't launch door execution from the same directory where it creates dropfiles (Maximus often doesn't), or if you're using a non-standard comm port under DOS and aren't running a FOSSIL driver, you'll need to use additional command-line parameters. See the file SAMPLE.BAT for examples, or the section below on "COMMAND-LINE ARGUMENTS" for detailed explanations. Advice: Keep it simple. Assume that you don't need to use extra command-line arguments unless you have special reason to think otherwise. The above one-line batchfile will work for a vast majority of systems, and making things more complex (copying the dropfile to the game directory, changing directories, etc.) will often introduce problems instead of avoiding them. 2. Add lines to your nightly maintenance file to run Ox maintenance on a daily basis. Depending on your directory structure, the lines might look like this: C: CD\DOOR\IRONOX IRONOX /MAINT If you have activated any bulletins in OxConfig, you will also want to add a line like this to update the bulletins: IRONOX /BULLETINS You may choose to add IRONOX /BULLETINS to the batch file that runs the game -- so that bulletins are updated whenever a player exits the game -- but be aware that writing a complete set of bulletins, including interBBS bulletins, may be somewhat slow (it takes about 5 seconds, for instance, on my 486-100). That's all it takes! You're ready to add Iron Ox to your door menu and get rolling! Iron Ox for OS/2 for a Native OS/2 BBS: Here are the key steps to installing Iron Ox for OS/2: 1. Copy the file DOORS2V5.DLL to a directory on the LIBPATH defined in your CONFIG.SYS. On a typical system, the \OS2\DLL directory on your boot drive works fine. 2. Create a batchfile or script to run the game. If you're running Maximus or a similar BBS system, no batchfile is necessary: you can add a script directly to your MENUS.CTL file. See below for examples. 3. Add lines to your nightly maintenance file to run Ox maintenance on a daily basis. Depending on your directory structure, the lines might look like this: C: CD\DOOR\IRONOX IRONOX /MAINT If you have activated any bulletins in OxConfig, you will also want to add a line like this to update the bulletins: IRONOX /BULLETINS You may choose to add IRONOX /BULLETINS to the batch file that runs the game -- so that bulletins are updated whenever a player exits the game -- but be aware that writing a complete set of bulletins, including interBBS bulletins, may be somewhat slow (it takes about 5 seconds, for instance, on my 486-100). Here's a script that will work fine on a single-node system using the default DORINFO.MEC script that comes with Maximus: Display_File C:\Max\Misc\Dorinfo Normal "Iron Ox/2" NoDsp Xtern_Dos C:\Door\IronOx\IronOx.exe Normal "I" Important question: Have you changed your DORINFO.MEC script to write the name of the correct comm port to the dropfile instead of the number of an open comm handle? (Many OS/2 sysops who run DOS doors have done this.) If so, your script should look like this: Display_File C:\Max\Misc\Dorinfo Normal "Iron Ox/2" NoDsp Xtern_Dos C:\Door\IronOx\IronOx.exe_/PORT Normal "I" Note: If you get errors accessing the port with this configuration, make sure you have your serial driver configured to allow a comm port to be shared across sessions (with SIO, you would need to use the "-" parameter, described in the section on running from a VDM). Are you running multinode? If so, copy MLTINODE.MEC (from this archive) to your scripts directory, and use the following commands to run Iron Ox/2: Display_File Misc\MltiNode Normal "Iron Ox/2" NoDsp Xtern_Dos \Door\IronOx\OX.cmd_%k Normal "I" OX.CMD should look like this: C:\DOOR\IRONOX\IRONOX.EXE /N:%1 C:\MAX\MISC\%1\ Note: For this setup to work, you will need to create node work directories under \MAX\MISC\ for each node, like so: C:\MAX\MISC\1\ (for node 1) C:\MAX\MISC\2\ (for node 2), and so forth. Another 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 you run a multinode BBS and your users spend a lot of time in ill-behaved DOS doors. Installing Iron Ox for OS/2 for a DOS BBS in a VDM: 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. I am now running my DOS BBS full-time under OS/2, so compatibility has been a high priority for me from the beginning. Your mileague running an OS/2 door under a DOS BBS may vary (some people report impressive results, while others notice little difference), but I hope you'll be glad to have the choice. :-) To run Ox/2 from a DOS BBS, you must be using Ray Gwinn's SIO or compatible drivers (COM.SYS/VCOM.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 my BBS; see the section on "SUPPORT," 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. 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. (Note: This option has no effect under OS/2.) /BULLETINS Updates any bulletin files you have activated in OxConfig. /LOCAL This option tells Iron Ox to run in local mode, and not to access the comm ports or look for a BBS dropfile. By default, when running in local mode, Ox assumes it is running on node 0. If you are running a multinode system and want to run on a different node number, use the /N option documented below. /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). (Note: This option has no effect under OS/2.) /LRIP This option tells Iron Ox to run in graphics mode using the same RIPScrip graphics a caller will see if he/she logs in using a RIP terminal (like RIPTerm or QMPro). Notes: (a) Local graphics are currently not supported in the OS/2 version of Iron Ox. (They are a possibility for an upcoming version -- let me know if it's a feature you want to see!) (b) When you're not running in local mode (i.e., you aren't using the /LOCAL parameter), the game will only run with local graphics when the remote user (the caller) also has RIP graphics. In other words, if the caller only has ANSI, you see ANSI with or without /LRIP. (c) If you run more than one node under a multitasker like DESQview, you will probably want to ensure that only one copy of Iron Ox is running in /LRIP mode at a time. If multiple instances of the game try to access the graphics display at once, screen corruption can result. /MAINT This option runs daily maintenance, advancing the game to a new turn. It MUST NOT be run when the game is in use on another line, so IRONOX /MAINT is a good candidate for your nightly maintenance event. Running IRONOX /MAINT *more* than once a day (for a faster-moving game) works fine in single-BBS mode; it's disabled in interBBS league mode to prevent cheating. /N: This option allows you to indicate the current node number when the game is run on a multinode system. Example: IRONOX /N:3 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 DORINFO BBS packages like RemoteAccess. /NASTY 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 Iron Ox running very slowly and/or you know you run lots of non-timeslicing DOS doors. (Note: This option has no effect in the DOS version.) /NICE The /NICE parameter is the natural counterpart of the /NASTY parameter, documented above. Using the /NICE parameter indicates to Iron 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 control over game performance. (Note: This option has no effect in the DOS version.) /NOFIFO Some Western Digital 16550 cards have a bug that causes them to lock up when their FIFO buffers are used. This flag tells Iron Ox to disable its use of FIFO buffers. Note: If you've never heard of this FIFO bug before, assume it *DOESN'T* apply to you and do not use this option! If you had the problem, you'd know by now. <g> (Note: This option has no effect under OS/2.) /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. (Note: This option has no effect under OS/2.) /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. (Note: This option has no effect under OS/2.) /PLANETARY This option runs interBBS planetary maintenance: it packs up all outbound information waiting to go to other systems, processes any inbound packets from other systems, and (if enough time has passed since the last planetary maintenance) creates recon information packets from other systems. Running IRONOX /PLANETARY has no effect on a game that isn't part of an interBBS league. This option may be run any number of times per day, and works fine if run with a user on another node. It should not be used in conjunction with /RESET or /MAINT. /RESET This option tells Iron Ox to purge the current game and brings up the "create new game" menu. Note: Do not use this option while people are playing the game on another node. [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 use the same configuration file, and (for the most part) they can use the same batch file, too. Because the program supports FOSSIL drivers under DOS and uses the standard device driver model under OS/2, it can handle issues like non-standard IRQ's *completely automatically* -- no need to treat individual nodes specially on FOSSIL or OS/2 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 OS/2 or the file-sharing facilities on LANs). If you're running multinode *without* such a utility, now would be a good time to start. To set up the door for multinode use, create batch files for each node like those 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 under DOS and you are *NOT* using a FOSSIL driver. If you have a local node and you like to play the game with RIP graphics, you may want to have a special batch file for the local node to bring up the game with the /LRIP parameter. (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.) Iron Ox includes a multinode chat/messaging system. By default, Iron Ox looks for up to ten nodes on your system. If you have more nodes than that (or if you have considerably fewer, and you want to save your CPU a little work) you can visit the Multinode Menu in OxConfig and adjust your Highest Node Number. One more thing for DOS users: When you first enter OxConfig, you will see a message about IRONOX.EXE being flagged read-only. This is a workaround to cope with a bug in Borland's overlay manager, and should have no effect on day-to-day use of the game. If you should ever need to reverse the process (to upgrade or remove IRONOX.EXE), type the command ATTRIB IRONOX.EXE -R from the DOS prompt. This issue does not come up under OS/2. 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 clears all of its locks every time it enters or exits the door normally, so "lingering locks" will be cleared automatically. 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). COMMON PROBLEMS 1. My BBS makes one of the dropfiles the door supports, but the game keeps telling me it can't find a dropfile! This game assumes that you are running it from the directory where your BBS dropfile is located. If you aren't, include the directory where your dropfile is located on the command line, thus: C:\DOOR\IRONOX\IRONOX.EXE C:\WC30\WCWORK\NODE1\ If you're running a DORINFO system, specifying the node number on the command line might also be useful: C:\DOOR\IRONOX\IRONOX.EXE /N:3 C:\QBBS\ 2. The game works fine locally, but doesn't work over a modem! If you're running under DOS and you're having trouble getting 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 my system (listed under "Support," below), and many other places as well. If you don't wish to use a FOSSIL, the /ACCEPT, /LOCK, /P and /I options explained in the section on command-line arguments may help with the problem. If not, or if you're already *using* a FOSSIL and are still having problems, feel free to contact me for further assistance. 3. I'm running Iron Ox for OS/2, and I keep getting a "critical error setting DCB" or something like that whenever the game tries to run across a modem! Usually, this error means that Iron Ox is trying to open the wrong comm port or a comm port that doesn't exist. There are two common causes for this: (a) you're using the /PORT parameter when you shouldn't be or not using it when you should be, or (b) the door is finding the wrong dropfile. If you're running a DOS BBS in a VDM, you need to use the /PORT parameter. If you're running a native OS/2 BBS, you may or may not need it: try removing it/adding it. If fixing your /PORT setting doesn't address the problem, try specifying the location/name of the door dropfile on the command line. 4. I'm running the DOS version of the game. 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, the Borland C overlay manager has 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; you can do this by running OxConfig, or by using ATTRIB IRONOX.EXE +R. 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. If you're using /N and Iron Ox is *still* getting confused, chances are that Ox is finding a stray dropfile. Try specifying the name and location of the dropfile on the command-line (as described above). 6. I run under DOS, and I'm getting some weird message about SHARE not being loaded! If you're running Iron Ox multinode, you need to have SHARE (or an equivalent utility) loaded. Consult your operating system manual for information on using SHARE. If you're not running multinode, you shouldn't need to have SHARE loaded on your system. Go into OxConfig, visit the Multinode Options menu (under "General Options") and set your "Highest Node Number" to zero. (Actually, you probably won't even get as far as the main menu -- OxConfig will detect the problem with SHARE and prompt you to turn off multinode support as soon as you run the program.) 7. The game runs fine multinode, but my game files are getting corrupted or I am having sharing violations when nightly maintenance runs! As mentioned above in the section on "COMMAND-LINE ARGUMENTS," nightly maintenance (IRONOX /MAINT) *MUST NOT* be run while users are in the door. (Future versions may support running /MAINT multinode, but even then it won't be recommended for performance reasons.) IRONOX /MAINT should be run as part of your nightly maintenance when no users are online. Note: This restriction only applies to nightly maintenance, run with IRONOX /MAINT. IRONOX /PLANETARY, IRONOX /BULLETINS, and other game maintenance routines work fine run multinode. 8. When I run the game, I'm getting a weird message like: Assertion failed, iRec < OvrFileHeader.iOvrRecords[Overlay] This error usually means that your IRONOX.EXE and your TEXT.OVR file (two files that come in the standard Iron Ox distribution archive) are different versions. One common reason this happens is that you have recently upgraded to a new version while IRONOX.EXE was flagged read-only -- TEXT.OVR was successfully upgraded to the new version, but your unarchive utility failed to update IRONOX.EXE. If this situation could apply to you, here's the solution: Un-flag IRONOX.EXE using ATTRIB IRONOX.EXE -R, repeat the upgrade procedure, and then enter OxConfig to reflag the game read-only. If this doesn't work for you, please contact me for more help. CONFIGURING IRON OX The easiest way to configure Iron Ox is to use the OxConfig utility included with Ox. This utility allows you to edit values in your IRONOX.CFG file, and includes range-checking and online help. If you prefer to edit IRONOX.CFG (an ASCII file) manually, see IRONOX.SAM for information on the options in the file. Note: If you are running an interBBS league and have relatively complicated routing (more than one hub, numerous routing exceptions), you may need to edit the routing section of your IRONOX.CFG manually. Information about IBBS routing appears in IRONOX.SAM and INTERBBS.DOC. 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 two 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: ASCII Art Annoying Pun Political Tirade O.J. Simpson Joke 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. 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. EXTERNAL PROTOCOLS Iron Ox supports automatic in-game downloading of RIP icon files. To activate this option, visit OxConfig's General Settings|General Config menu and entered a valid path and filename for an external protocol. One important caveat about Iron Ox's use of external protocols. The MS-DOS version of Iron Ox assumes that any protocol will use a DSZ-style command line: dsz port 1 sz @files.lst The OS/2 version assumes that any protocol will use a CEXYZ/2-style command line: cexyz2 /P12 /B38400 /Sz @files.lst Note that the CEXYZ/2 command line includes a comm handle, not the name of a comm port to open. Iron Ox has been tested with DSZ and CEXYZ/2, and those protocols are recommended. If you are using a protocol other than DSZ/CEXYZ/2 that uses a similar command line, you may be able to run that protocol by entering a batch file name in OxConfig and using that batch file to "translate" the command line arguments. MAINTAINING IRON OX In the installation instructions (above), you read about how to use IRONOX /MAINT in your nightly maintenance batch file to advance the game to new turns. You also will need to run IRONOX /RESET to create new game files when the game comes to an end (by default, this will only happen every few months). In general, that's all the maintenance you'll need to do! If you have a problem user and you need to delete him/her or edit an alias, running IRONOX /LOCAL /EDIT calls up a very minimal editor that includes this function. As you may know, Iron Ox 1.x and 2.x included a much more complete game editor. However, because Iron Ox 3.x is intended to run interBBS, and because accusations of cheating are so common in interBBS leagues, a comprehensive editor is not included in this version, and the data files were encrypted to discourage direct modification. 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 US$20. If you wish to register using a credit card, you can use your modem to call 619-462-8406 or 619-462-7146 to obtain your registration key instantly using online registration. (Note: To do this, you have to go through my normal questionnaire/login process. If you're concerned about long distance expenses -- e.g., if you're calling internationally -- see INTLREG.DOC for instructions on how to work around that!) If you prefer to use conventional mail and a check or money order, see REGISTER.FRM for information on shipping and delivery options. Iron Ox is not "crippleware": the unregistered version is a complete and enjoyable game. However, the registered version of Ox does include the following enhanced features: 1. MORE LAND IMPROVEMENTS: In the registered version of the game, your players are allowed to build three powerful improvements (the luxite refinery, ore refinery, and power plant) that noticeably improve production of luxite, ore, and energy. Because these improvements are "unique" -- each colony may only have one of them! -- the battle over who controls them can add extra excitement to the game. 2. EXTRA RACES: In the registered version 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. EXPERT AND NIGHTMARE MODES: In the evaluation version, you may only choose beginner and intermediate skill levels for the game. In the registered version, you can give your players an extra challenge by selecting expert or nightmare mode! 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! (3.x USERINFO.DAT and 4.x SYSINFO.DAT), SpitFire (SFDOORS.DAT), and many other systems. 5. TROJAN OXEN: Trojan Oxen are a valuable defense against sabotage: They look like ordinary oxen, but *fight back* if attacked. Very helpful in cutthroat and interBBS games. Please see REGISTER.FRM to find out how to register your copy of Iron Ox. Iron Ox is the product of countless hours of work. 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 for DOS and 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 on request via U.S. Mail or electronic mail. Registrations are non-transferable without my direct permission. FUTURE PLANS Iron Ox has an exciting future. You can find out the latest about Iron Ox development and new features by visiting the Iron Ox Home Page on the World Wide Web (See "SUPPORT," below). Here are a few of the features I am considering for upcoming versions of Iron Ox: 1. Four more drone classes, including a drone capable of attacking forts, a hunter/killer drone to track specific players, a "carrier" drone to transport cybermutts, and a "ground-mauler" drone to destroy land. If you have other ideas, I'd like to hear about them! 2. A completely reworked message system including support for "multimail," carbon copies, quoting on reply, messages to all, and global (interBBS) announcements. 3. Support for remote reset, remote configuration reports, and remote configuration changes in interBBS leagues. 4. "Multi-BBS" attacks where several BBS'es can pool resources to attack more powerful systems. Many of the most important features in Iron Ox originated in user suggestions. If you have ideas you'd like to see in future versions, please let me know! SUPPORT I appreciate your feedback and ideas. If you have problems getting Iron Ox to run, please feel free to contact me. I am moderator of the Fidonet IRONOX echo, which is distributed via the Zone 1 echomail backbone. This echo is an excellent place to get help with the game, discuss improvements for future versions, and get access to game tips for your players! Please note: I attempt to read all of my personal mail regularly. However, due to the large volume of mail I receive, I do sometimes get behind. If you need a reply from me quickly, please feel free to e-mail or crashmail me, but also consider posting a public message in the IRONOX echo. Many knowledgeable people read that area, and may be able to provide faster answers than I can. 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 also monitor the General Mail and Ox Local Support conferences on my BBS for personal mail. I can be reached via netmail at Fidonet address 1:202/704. I am also reachable via the Internet as joel@dreamcty.cts.com. 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 Courier "V.Everything" 28.8 (619) 462-8406 Node 2: ZyXEL 16.8 v.32bis (619) 462-7146 The latest version of Iron Ox for DOS and for OS/2 is available for download on my BBS, for FREQ (magic names: IRONOX for the DOS version, OX2 for the OS/2 version) from either of my Fido nodes, and for anonymous ftp from ftp.cts.com, in the /pub/joeld directory. Iron Ox also has a home page on the World Wide Web, at http://www.free.cts.com/crash/j/joeld/ox.html The WWW page is a new experiment, and I welcome your feedback. :-) It includes information on recent development, future plans, and more! 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 1996; 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 28.8+ La Mesa, CA TDC 2 1:202/705 619-462-7146 V.32bis La Mesa, CA Blackbeard's BBS 1:19/19 318-468-3385 V.34+ Ville Platte, LA Common Sense 1:215/705 510-713-7336 V.34+ Newark, CA The Harry Beast 1:343/102 206-859-6157 V.32bis Kent, WA Hi-Flite BBS 1:137/217 941-753-4458 V.34 Bradenton, FL Hole in the Wall 1:104/651 303-841-5515 V.34+ Parker, CO Holston River Vlly 1:3615/44 615-932-1490 V.34+ Knoxville, TN ISMWare Support 1:134/31 403-686-0449 V.FC Calgary, AB Mayberry BBS 1:3663/302 910-789-8183 V.FC Mt. Airy, NC Test Pattern BBS 1:259/524 905-890-2531 V.34+ Ontario, Canada The Toyland BBS 1:123/117 901-835-4016 V.34 Drummonds, TN Ruby's Joint 1:112/129 904-777-6799 V.FC Jacksonville, FL Phantom BBS 2:259/26 +44-1224-709833 V.34 Aberdeen, Scotland S.P.I. BBS 2:259/61 +44-1506-857709 V.FC Broxburn, Scotland OTHER SOFTWARE BY JOEL W. DOWNER Fiction Factory Fiction Factory is a "never-ending story" door aimed at the modern BBS. It includes full RIP support (including optional local RIP); a full-screen, scrolling windowed text editor and file viewer; context-sensitive, popup help; real-time multinode support; up to 255 stories at a time; password- protected stories; and more! File: FFCV100.ZIP (DOS Version), Magic Name: FICTFACT File: FFC2V100.ZIP (OS/2 Version), Magic Name: FF2 Doors/2 Doors/2 is a complete toolkit for developing C/C++ doors for OS/2. It's based on the OpenDoors API, and allows you to port a DOS door written for OpenDoors with little more than a recompile! Features include 32-bit multithreaded performance, full support for a wide range of BBS'es/dropfiles, built-in multinode messaging and chat, full-screen editing capabilities, and more! File: DRS2V500.ZIP, Magic Name: DOORS2 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 do a reliable job of that. Your use of Iron Ox and/or any companion material constitutes your acceptance of these terms. ACKNOWLEDGEMENTS To paraphrase J.R.R. Tolkien, Iron Ox is a tale that has grown in the telling. When I wrote the first version of Iron Ox in the Fall of 1993, I don't think I could have imagined that it would some day have features like local graphics, interBBS support, and real-time multinode interaction. Credit for the continued growth of the door belongs to many people who have provided inspiration, encouragement, or concrete help along the way. Please see the HISTORY.TXT file for a specific list of heroes who have made a big difference in the creation of this version. Iron Ox's support for RIP uses a C RIP library that is (loosely) based on Tom Morgan's Pascal RIPLink library. Thanks to Tom, and to the maintainers of DDPlus -- Steve Lorenz and Bob Dalton -- for making RIPLink and the DDPlus tookit, in which RIPLink is now contained, available in source form to door authors everywhere. The DOS version of this door also 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. The OS/2 version uses my own Doors/2 port of OpenDoors; see "OTHER SOFTWARE BY JOEL W. DOWNER" for more information. Finally, thanks to Evvie Vincow for near-lethal persistence.