home
***
CD-ROM
|
disk
|
FTP
|
other
***
search
/
DP Tool Club 31
/
CDASC_31_1996_juillet_aout.iso
/
vrac_os2
/
ox2v300.zip
/
IRONOX.SAM
< prev
next >
Wrap
Text File
|
1996-05-17
|
8KB
|
201 lines
// SAMPLE.CFG -- Sample config file for Iron Ox
// This is a sample configuration file that would work on many single and
// multinode systems. Note that blank lines and comment lines (like this
// one!) are ignored. Keywords (like "Timeout" and "BBSName") must
// be flush left on a line, followed by blank space and the value you would
// like to assign to them. To create a quick default configuration, just
// enter COPY SAMPLE.CFG IRONOX.CFG at the command prompt.
//
// Note: If you are setting up an InterBBS game, a default configuration
// won't do the trick. You will need to "uncomment" and provide values
// for at least some of the IBBS variables: Outbound, Inbound, FidoMail,
// and UUCPSpool.
// The name of the sysop who owns this game. If the game is not registered,
// this field will be ignored.
SysopName UNREGISTERED
// The BBS on which the game is running. If the game is not registered, this
// field will also be ignored.
BBSName UNREGISTERED
// 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.
CourtesyOf Your Sysop
// Game registration code. See "REGISTER.FRM" for details!
RegCode 01234567890123456789
// This value determines how long (in seconds) Iron Ox will wait for a
// keystroke before it decides that a user is "sleeping at the keyboard."
// Timeout value does not apply to local players, only to remote users.
// Note: a value of zero disables timeout. 360 (6 minutes) is the
// recommended value.
Timeout 360
// Determines whether the game will blank the local display during remote
// play in games in which the sysop and other local mode players are
// participating. Very useful option if you are planning to play
// competitively in games on your board, but it does make
// monitoring and maintaining the game more difficult. Change to TRUE
// to enable the feature.
Secure FALSE
// 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.
AWOLDays 5
// 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!
MaxNodes 10
// Drones move around in real time while your players move around the
// map and play the game. This value determines how many times a user
// must pass the main command prompt for each drone to be checked. In
// other words, a higher value here will SLOW DOWN the drones, and a
// lower value will SPEED THEM UP.
// The default value is 30 cycles. Increasing the value will make
// the game run faster. On a 286 or slow 386 system, you will want to
// choose a value near the maximum (150). On a fast 486 or Pentium
// system, you may want to reduce this number to 10 or even 5 for more
// exciting real-time action.
DroneCycles 30
// Here are the new keywords you will want to add to your
// IRONOX.CFG file to support InterBBS play. Basically, these keywords
// give Iron Ox the information it needs to find/read/process league
// packets. If your system doesn't support some of the features
// referred to in this file, just comment out the lines that apply to
// them. (For instance, if you don't have UUCP, comment out the line
// for your UUCP spool directory.)
// 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.
// LeagueNum 001
// This number identifies your place in the IBBS nodelist, OXNODES.DAT.
// It will be the number directly above the name of your BBS.
// LeagueID 2
// 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. (I might have used
// \FD\OUTBOUND, for instance.)
// Outbound C:\DOOR\OXIP\PACKETS
// 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.
// Inbound C:\FD\SECURE
// 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.
// FidoMail C:\FD\MAIL
// If your system has UUCP, this is where Iron Ox should create/look for
// e-mailed Ox packets.
// UUCPSpool C:\VU10\WAFFLE\SPOOL\CRASH
// * * *
//
// ROUTING COMMANDS
//
// The rest of the keywords in this file control routing -- the way
// Iron Ox sends data to other BBS'es. You will want to configure this
// part of your game setup carefully to avoid unwanted long distance or
// toll calls! Unlike other keywords, routing keywords may meaningfully
// be used more than once -- you may have many ROUTE or HOLD statements,
// for instance.
// * * *
// ROUTE: 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. Examples:
//
// ROUTE 5 1
//
// will route all data for BBS 1 through BBS 5.
//
// ROUTE * 1
//
// Will route all data for *EVERYONE* through BBS 1.
// DIRECT: 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. For instance, say that you're in a
// long-distance league. BBS numbers 5 and 6 (your hub) are in your
// area, and the rest are a long way away. You want to connect directly
// with 5 and 6, and route packets for everyone else through 6. The
// simplest way to do this is with a Route command followed by a direct
// command:
//
// Route * 6
// Direct 5
// CRASH: 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.
//
// Crash *
//
// tells Ox to crash all outbound data, while
//
// Crash 3
//
// tells Ox just to crash material going to BBS 3. Specifying Crash for
// a UUCP system (one that doesn't use Fido) has no effect.
// HOLD: 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.
//
// Hold *
//
// tells Ox to hold all outbound data, while
//
// Hold 3
//
// tells Ox just to hold material going to BBS 3. Specifying Hold for
// a UUCP system (one that doesn't use Fido) has no effect.