home *** CD-ROM | disk | FTP | other *** search
/ OS/2 Shareware BBS: 2 BBS / 02-BBS.zip / ox2v3wb2.zip / IRONOX.SAM < prev    next >
Text File  |  1995-12-01  |  7KB  |  187 lines
  1. //               SAMPLE.CFG -- Sample config file for Iron Ox
  2.  
  3. // This is a sample configuration file that would work on many single and
  4. // multinode systems.  Note that blank lines and comment lines (like this
  5. // one!) are ignored.  Keywords (like "Timeout" and "BBSName") must
  6. // be flush left on a line, followed by blank space and the value you would
  7. // like to assign to them.  To create a quick default configuration, just
  8. // enter COPY SAMPLE.CFG IRONOX.CFG at the command prompt.
  9. //
  10. // Note:  If you are setting up an InterBBS game, a default configuration
  11. // won't do the trick.  You will need to "uncomment" and provide values
  12. // for at least some of the IBBS variables:  Outbound, Inbound, FidoMail,
  13. // and UUCPSpool.
  14.  
  15. // The name of the sysop who owns this game.  If the game is not registered,
  16. // this field will be ignored.
  17.  
  18. SysopName UNREGISTERED
  19.  
  20. // The BBS on which the game is running.  If the game is not registered, this
  21. // field will also be ignored.
  22.  
  23. BBSName UNREGISTERED
  24.  
  25. // When the door is registered, you may wish to give credit to the
  26. // person(s) who donated to register the door.  If you put a name or
  27. // other phrase here, it will be displayed on the main menu screen along
  28. // with your name and the name of your BBS.  See "SysopName," below.
  29.  
  30. CourtesyOf Your Sysop
  31.  
  32. // Game registration code.  See "REGISTER.FRM" for details!
  33.  
  34. RegCode 01234567890123456789
  35.  
  36. // This value determines how long (in seconds) Iron Ox will wait for a 
  37. // keystroke before it decides that a user is "sleeping at the keyboard."  
  38. // Timeout value does not apply to local players, only to remote users.  
  39. // Note:  a value of zero disables timeout.  360 (6 minutes) is the 
  40. // recommended value.
  41.  
  42. Timeout    360
  43.  
  44. // Determines whether the game will blank the local display during remote 
  45. // play in games in which the sysop and other local mode players are 
  46. // participating.  Very useful option if you are planning to play 
  47. // competitively in games on your board, but it does make
  48. // monitoring and maintaining the game more difficult.  Change to TRUE
  49. // to enable the feature.
  50.  
  51. Secure FALSE
  52.  
  53. // If a player doesn't play Ox regularly, he/she will get hopelessly
  54. // behind and slow down the game.  Players who miss the number of
  55. // consecutive turns you specify here will be removed from the game.
  56.  
  57. // The recommended default is five days.  Entering "0" disables
  58. // AWOL-checking.
  59.  
  60. AWOLDays       5
  61.  
  62. // Iron Ox has a messaging system that allows internode messages and
  63. // multiplayer chat.  This system works for nodes on a single machine
  64. // and for nodes distributed across a LAN.
  65.  
  66. // By default, Iron Ox tests for ten active nodes. If you have more than
  67. // ten nodes, you should set this value to your highest node number. If
  68. // you have fewer, lowering this value will improve performance and save
  69. // memory.  To disable messaging, set this value to zero.
  70.  
  71. // WARNING:  DO NOT DISABLE MULTINODE MESSAGING IF YOU *ARE* RUNNING THE
  72. // GAME MULTINODE, OR DATABASE CORRUPTION WILL RESULT.  THE NODES HAVE
  73. // TO BE ABLE TO "TALK TO EACH OTHER" TO SHARE RESOURCES CORRECTLY!
  74.  
  75. MaxNodes       10
  76.  
  77. // Here are the new keywords you will want to add to your
  78. // IRONOX.CFG file to support InterBBS play.  Basically, these keywords
  79. // give Iron Ox the information it needs to find/read/process league
  80. // packets.  If your system doesn't support some of the features
  81. // referred to in this file, just comment out the lines that apply to
  82. // them.  (For instance, if you don't have UUCP, comment out the line
  83. // for your UUCP spool directory.)
  84.  
  85. // This is the league number your BBS is playing in.  It must be a
  86. // three-digit number (e.g., 001 or 959 or 333).  If you are starting a
  87. // league, pick a number that isn't already being used by leagues in
  88. // your area to avoid confusion.  If you're joining a league, you'll get
  89. // this number from your league coordinator.
  90.  
  91. // LeagueNum 001
  92.  
  93. // This number identifies your place in the IBBS nodelist, OXNODES.DAT.
  94. // It will be the number directly above the name of your BBS.
  95.  
  96. // LeagueID 2
  97.  
  98. // This is the directory where Ox creates outbound packets.  I would
  99. // recommend creating a subdirectory of your Iron Ox game directory, but
  100. // the location you choose doesn't matter much.  (I might have used
  101. // \FD\OUTBOUND, for instance.)
  102.  
  103. // Outbound    C:\DOOR\OXIP\PACKETS
  104.  
  105. // This is where inbound file attachments are placed by your mailer (for
  106. // instance, where inbound echomail packets are placed).  For FrontDoor
  107. // and InterMail, you will find this setting in the setup program under
  108. // Global|Filenames|Files or Global|Filenames|Sec Files.
  109.  
  110. // Inbound     C:\FD\SECURE
  111.  
  112. // This is where your mailer keeps its netmail folder.  Iron Ox will
  113. // create netmail here to send file attachments to other systems, and
  114. // look here for netmail *from* Iron Ox on other systems.
  115.  
  116. // FidoMail    C:\FD\MAIL
  117.  
  118. // If your system has UUCP, this is where Iron Ox should create/look for
  119. // e-mailed Ox packets.
  120.  
  121. // UUCPSpool   C:\VU10\WAFFLE\SPOOL\CRASH
  122.  
  123. //                          *        *       *
  124. //
  125. //                           ROUTING COMMANDS
  126. //
  127. // The rest of the keywords in this file control routing -- the way
  128. // Iron Ox sends data to other BBS'es.  You will want to configure this
  129. // part of your game setup carefully to avoid unwanted long distance or
  130. // toll calls!  Unlike other keywords, routing keywords may meaningfully
  131. // be used more than once -- you may have many ROUTE or HOLD statements,
  132. // for instance.
  133. //                          *        *       *
  134.  
  135. // ROUTE:  This keyword tells Iron Ox not to send packets directly to
  136. // one or more BBS'es, but instead to route the information through a
  137. // third system.  If you're in a long-distance league, for instance, you
  138. // will probably be connecting with a single hub and that hub will be
  139. // routing packets to the rest of the league.  Examples:
  140. //
  141. // ROUTE 5 1
  142. //
  143. // will route all data for BBS 1 through BBS 5.
  144. //
  145. // ROUTE * 1
  146. //
  147. // Will route all data for *EVERYONE* through BBS 1.
  148.  
  149. // DIRECT:  This keyword tells Iron Ox *not* to route data for a
  150. // particular BBS.  The most common use for this keyword is to state an
  151. // *exception* to a Route command.  For instance, say that you're in a
  152. // long-distance league.  BBS numbers 5 and 6 (your hub) are in your
  153. // area, and the rest are a long way away.  You want to connect directly
  154. // with 5 and 6, and route packets for everyone else through 6.  The
  155. // simplest way to do this is with a Route command followed by a direct
  156. // command:
  157. //
  158. // Route * 6
  159. // Direct 5
  160.  
  161. // CRASH:  This keyword tells Iron Ox to set the "Crash" flag on packets
  162. // sent to a given BBS or (if you use '*' instead of a number) to all
  163. // BBS'es.
  164. //
  165. // Crash *
  166. //
  167. // tells Ox to crash all outbound data, while
  168. //
  169. // Crash 3
  170. //
  171. // tells Ox just to crash material going to BBS 3.  Specifying Crash for
  172. // a UUCP system (one that doesn't use Fido) has no effect.
  173.  
  174. // HOLD:  This keyword tells Iron Ox to set the "Hold" flag on packets
  175. // sent to a given BBS or (if you use '*' instead of a number) to all
  176. // BBS'es.
  177. //
  178. // Hold *
  179. //
  180. // tells Ox to hold all outbound data, while
  181. //
  182. // Hold 3
  183. //
  184. // tells Ox just to hold material going to BBS 3.  Specifying Hold for
  185. // a UUCP system (one that doesn't use Fido) has no effect.
  186.  
  187.