OS/2 Shareware BBS: 2 BBS

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

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

Wrap

Text File | 1995-12-01 | 57KB | 1,153 lines

IRON OX Version 3.00 wide beta two (C)opyright 1995, Joel W. Downer (Development in Progress) 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 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 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, 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 375k of memory to run in text mode, and about 435k to run with local graphics. (Having more memory, and some EMS memory available, will make it run faster.) 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. Iron Ox for DOS 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.) Iron Ox for DOS 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 distribution sites. 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 then runs IRONOX /LOCAL /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.) At the end, the installation process displays some instructions on the screen about setting up a batch file and 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 The first time you run the game, it will bring up a screen including lots of reset options; for a quick look, just accept the defaults. 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. Don't be intimidated that this section is long! The reason is that Iron Ox works on three radically different kinds of BBS system. Only about a third of this information will apply to you (less if you're running a plain-vanilla DOS system). 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. If you don't want local graphics, the batch file will probably look like this: C:\DOOR\IRONOX\IRONOX.EXE If you do want local graphics, 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 3. You may wish to place a copy of the file OXICON.ZIP in your file area so that RIP terminal users can download it and enjoy the game in RIP mode! (In-game downloading of icons is planned soon.) 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 DRS2V5B5.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 4. You may wish to place a copy of the file OXICON.ZIP in your file area so that RIP terminal users can download it and enjoy the game in RIP mode! (In-game downloading of icons is planned for wide beta two.) 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.) /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 may 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.) CONFIGURING IRON OX Iron Ox looks for configuration information in a file called IRONOX.CFG, which must be located in the game directory (the same directory where IRONOX.EXE is located). By far, the easiest way to create/manage your IRONOX.CFG file is to use OxConfig -- not only does OxConfig include extensive help and easy-to-use menus, it checks for a number of possible errors and corrects them before they have a chance to do harm. However, if you detest configuration programs (or if your interBBS league routing is more complicated than OxConfig knows how to handle), you can also edit IRONOX.CFG manually. IRONOX.CFG is a normal ASCII text file, and you can edit it with your favorite text editor or word processor. The Iron Ox distribution archive contains a file called IRONOX.SAM, which contains quick documentation of the basic configuration options for the game. Here is more complete information about your options: 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, Iron 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. WARNING: DO NOT DISABLE MULTINODE MESSAGING IF YOU *ARE* RUNNING THE GAME MULTINODE, OR DATABASE CORRUPTION WILL RESULT. THE NODES HAVE TO BE ABLE TO "TALK TO EACH OTHER" TO SHARE RESOURCES CORRECTLY! 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 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/2 node will create a named pipe for each node using the format "\PIPE\MSGPIPE" and the node number (thus, Node One would create "\PIPE\MSGPIPE.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\PIPE\MSGPIPE 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. (Note: This option has no effect under DOS.) 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. Note: Timeout is automatically disabled when the game is run in local mode. Game/Playability Options Keyword Default Function 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. The recommended default is five days. Entering "0" disables AWOL-checking. InterBBS Options Keyword Default Function LeagueNum 000 This is the league number your BBS is playing in. It must be a three-digit number (e.g., 001 or 959 or 333). If you are starting a league, pick a number that isn't already being used by leagues in your area to avoid confusion. If you're joining a league, you'll get this number from your league coordinator. LeagueID 0 This number identifies your place in the IBBS nodelist, OXNODES.DAT. It will be the number directly above the name of your BBS. Outbound NONE This is the directory where Ox creates outbound packets. I would recommend creating a subdirectory of your Iron Ox game directory, but the location you choose doesn't matter much. (You could use your mailer's OUTBOUND directory, for instance.) Inbound NONE This is where inbound file attachments are placed by your mailer (for instance, where inbound echomail packets are placed). For FrontDoor and InterMail, you will find this setting in the setup program under Global|Filenames|Files or Global|Filenames|Sec Files. FidoMail NONE This is where your mailer keeps its netmail folder. Iron Ox will create netmail here to send file attachments to other systems, and look here for netmail *from* Iron Ox on other systems. UUCPSpool NONE If your system has UUCP, this is where Iron Ox should create/look for e-mailed Ox packets. InterBBS Routing Keyword Default Function Route NONE This keyword tells Iron Ox not to send packets directly to one or more BBS'es, but instead to route the information through a third system. If you're in a long-distance league, for instance, you will probably be connecting with a single hub and that hub will be routing packets to the rest of the league. Both single and global commands ("ROUTE 5 1", to route everything for system five through system one, and "ROUTE * 1", to route everything for *everyone* through system one) are supported. Direct NONE This keyword tells Iron Ox *not* to route data for a particular BBS. The most common use for this keyword is to state an *exception* to a Route command. Crash NONE This keyword tells Iron Ox to set the "Crash" flag on packets sent to a given BBS or (if you use '*' instead of a number) to all BBS'es. Hold NONE This keyword tells Iron Ox to set the "Hold" flag on packets sent to a given BBS or (if you use '*' instead of a number) to all BBS'es. Normal NONE If you use a "Crash *" or a "Hold *" directive, this keyword allows you to specify exceptions to the rule. 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. CourtesyOf (blank) When the door is registered, you may wish to give credit to the person(s) who donated to register the door. If you put a name or other phrase here, it will be displayed on the main menu screen along with your name and the name of your BBS. 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 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. 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: 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. 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. 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 $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. If you are a league coordinator or a member of an interBBS league including ten or more BBS'es, be sure to see LC-OFFER.TXT for information about a limited-time offer that could save you money on registration! 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), RemoteAccess, Apex, and QuickBBS (EXITINFO.BBS), 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 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. 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.cts.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 Courier "V.Everything" 28.8 (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 place to get help with the game, discuss improvements for future versions, and get access to game tips for your players! 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 General Mail conference on my BBS. 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 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 July 1995; 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 Dual La Mesa, CA TDC 2 1:202/705 619-462-7146 16.8 V.32bis La Mesa, CA Common Sense 1:215/705 510-713-7336 V.34+ Dual Newark, CA Comp. Connection 1:157/574 216-671-2574 V.FC 28.8 Cleveland, OH EVIL DEAD BBS 1:3550/566 907-278-3845 V.FC 28.8 Anchorage, AK The Harry Beast 1:343/102 206-859-6157 V.32bis Kent, WA Hole in the Wall 1:104/651 303-841-5515 28.8 Dual Parker, CO Holston River Vlly 1:3615/42 615-932-1490 28.8 Dual Knoxville, TN Holston 2 1:3615/43 615-932-1492 28.8 Dual Knoxville, TN Mayberry BBS 1:3663/302 910-789-8183 28.8 Hayes Mt. Airy, NC Test Pattern BBS 1:259/524 905-890-2531 28.8 Dual Ontario, Canada Ruby's Joint 1:112/129 904-777-6799 28.8 Hayes Jacksonville, FL 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: DRS2V5B5.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. First of all, thanks go to RogueMoonRips and Sandy Chidester for providing *fabulous* RIP art for the game. Sandy was too shy to want her name on the game welcome screen, but she deserves credit for her terrific work! Special thanks for this version also go to Dan Hunt, the ZC of Dragon Net, who generously volunteered to let me use his IBBS gaming network for Iron Ox IBBS testing. Particular thanks also to Dan Shore, whose work promoting the game and working on a player's FAQ has been a big help, and Jim Chapman, whose experience as an interBBS LC helped me avoid some nasty pitfalls. Greg Allen's enthusiasm back here on The Dreaming City has also made a huge difference. Thanks also to everyone in Dragon Net who helped to test this version! I apologize for not mentioning you all individually, but the IRONOX_BETA echo has been extremely active and I'm concerned about leaving someone out. It's been a pleasure, and I look forward to working with you further. 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.