Sysop Documentation for DOS Czarwars Game System 4.12 (C) Copyright 1987-1990 Ray Yeargin. All rights reserved. -= A brief description of Czarwars =- Czarwars is a multi-player 'environment' game implemented as a BBS and as a PCBoard DOOR. It is intended to provide a complex, balanced, and stable environment for long term strategy games. The Czarwars environment supports many strategies - far more than I could hope to describe here. In fact, new viable strategies are formulated regularly - a player's approach to the game is truly limited only by his or her imagination. The best Czarwars players are able to balance economic concerns against military considerations to produce a strategy for maximum growth and security. Of course, as in real life, politics and psychology can play a commanding role. Eliciting the aid and cooperation of other players can sometimes make the difference between life and death. In Czarwars there is no defined goal nor is there any declared winner - unless the Sysop establishes some criteria for such. Instead, the objective is left up to each player to define for himself. Some players strive to be 'Top Gun' - the most powerful player in the universe. Others set their sights on the highest military rank - determined by wins versus losses in battle. Others attempt to take and hold a complete galaxy as their own domain where only they can travel freely. And, of course, there are always those who delight in simply making life hard for others. As for me, I tend to set my sights on single-minded missions such as... Destroy the Top Gun! A. System Requirements: Minimum Configuration: IBM personal computer or compatible with 320K RAM (or more) Hard disk drive with 1 megabyte of free space (1.25 megabytes free disk space required for 4000 sector map) Hayes compatible modem usable through COM1 or COM2 NOTE: Many so-called "Hayes compatible" modems aren't actually very compatible at all. This system has been tested only with Hayes modems. Some other modems may work... Recommended: Real-time, battery backed clock/calendar Good quality surge suppressor The following instructions in Item B are for a fast setup of the system using default settings. Once the quick setup is completed you will be able (at your option) to read the Configuration section of this manual and customize your board to your individual preferences. If you are not already familiar with Czarwars you should read the CZAR_HLP.TXT file prior to doing the quick setup. You should also make back up copies of the distribution disks. B. Quick Setup for standalone mode: NOTE: If you intend to run this software under a PCBoard door (or as a door under other software using command line parameters), read section G below before continuing here. Likewise, if you are upgrading from an earlier version of Czarwars, be sure to read the file called HISTORY. Hardware: 1. Ensure that your modem is set to NOT auto answer the phone. Software: 1. Create a Czarwars directory on your hard disk and copy all the files on the distribution disks into the directory. All included files should be in the Czarwars directory for the system to operate properly except for the following: README LICENSE.TXT CZAR_DOC.TXT CONFIG.SYS CZARDOOR HISTORY Copy the CONFIG.SYS file to your root directory of your boot disk drive or, if you already have a CONFIG.SYS file there, make sure it includes the following two statements: FILES=12 BUFFERS=12 The numbers in the preceding statements can be larger but not smaller than 12. You will have to re-boot your system to put these options into effect. 2. Run CZAR_UTL. The CZAR_UTL program will check for missing files in the Czarwars directory and will generate new copies of the data files and bulletins, if necessary. You will be asked a couple of questions concerning the location and speed of your modem. If you do not already have a map file (CZAR_MAP.DAT) in the Czarwars directory, you will also be asked questions about the size and type of galaxies to install in the map file that will be generated. You will then be asked for a name and password for the Sysop. You should enter your name or simply 'SYSOP' at the name prompt. Both the Sysop's name and password must be entered in UPPER CASE. This will be the name and password you enter when you log into Czarwars. When the automatic configuration of Czarwars is completed you will see the Czarwars utility program main menu on your screen. You may select option 1 (Configure the System Parameters) at this point to further customize your installation of Czarwars. Some items you may consider changing at this time are: a. Select item 15 (Enable programmatic upgrades to 'A') If you intend to ask for donations to help support your BBS then you will probably want to this set to '0'. If you don't plan to solicit donations, leave this at '1' so players can upgrade their own ships. (a '0' here would enable you to give superior class ships to contributors only - or give them to no one, if you prefer) b. Select item 13 (Initialize the map). If you start with the advanced map file you may want to 'freshen' the inventory levels of the ports and planets. To do this enter a number from 1 to 10 to set the initial inventory levels (2 to 4 recommended). NOTE: If you have the advanced map file and you do not run this routine, the inventory levels will be very high when the game first starts. As a result, the first few players to log on will encounter planets and ports with the maximum quantitys and prices, therefore gaining an early advantage. 3. You should now be able to run CZAR_PGM and move around on the board as a regular player. You can buy and sell things, leave signs, and even leave mail. You can now bring up the BBS by entering CZAR_PGM /M. Using the /M switch causes the program to look to the modem for incoming calls rather than going straight to the console as before. If your modem is on and attached to the COM: port that you selected during the automatic installation then you should see a 'waiting for a call' screen on your display which will move every six seconds to prevent screen burnin (if you forget to turn off your monitor). Note: If you intend to run Czarwars in standalone BBS mode, it is recommended that you use the supplied batch file CZAR_BBS.BAT rather than running CZAR_PGM.EXE from the command line. If the phone rings now, the system will answer it and attempt to detect a carrier tone. You're online! If you were actually bringing up the system you would now turn off your monitor to save electricity and to prevent burn-in. Of course, you also may press the escape key and bring down the system at any time. C. Configuring and Customizing Czarwars: The CZAR_UTL program option <1> (Configure the System Parameters) allows you to customize Czarwars into a unique game. When you select option <1> you will be presented with a menu of numbered options. Lets take them one by one in order. 1. Game Cycle in days = 12 The 'Game Cycle' controls the maximum inventories of goods at the various ports and planets. For example, a port with a daily ore productivity level of 20 will produce 20 cargo holds of ore per day. If no one ports there to purchase ore for (say) several weeks then the inventory of ore would just keep growing indefinitely - if not for the limits imposed by the Game Cycle. If the Game Cycle is set to 10 then the port will accumulate no more than 10 times the daily production. 10 x 20 = 200. Therefore, if no one buys the ore to keep the levels of inventory down, production will stop when 200 holds of ore accumulate there. When someone buys some ore thereby causing the inventory to drop below the limit of 200 then production of ore will resume at the 20 hold-per-day level. Commodities produced on planets and the quantities of goods that ports attempt to purchase are controlled in the same way. I recommend starting with this number in the range of 6 to 12. 2. Logon Delay in 5 minute periods = 12 The Logon Delay is measured in 5 minute periods (5 minutes=1 'Starday') and controls how long a player must wait between LOGONS. Note that the duration of the session has no bearing on when a person is eligible to log on again. 3. Daily antimatter per player (grams) = 80000 Antimatter is fuel. The more you issue, the more a player can move around, trade, and gamble. Class 'A' ships are given an additional bonus above the number you enter here if the second parameter from item #16 below is set above zero. This enables you to give (for example) class 'A' ships a 10-100%+ antimatter bonus. The reasoning here is that if you are soliciting donations, the extra antimatter is an additional incentive to give. 50000-100000 grams is a good range to stay in until you've had the board up for a while. 4. Start Holds in new ship = 40 This controls how many cargo holds are included with a new ship. 5. Start Cash issued with new ship = 2000 The number of credits ($) issued to a player getting a new ship. 6. Max Holds: Class F ships + upgrades = 75 25 The maximum number of cargo holds that class 'A' and class 'B' ships can contain. 7. Price of a (125 fighter) Star Base = 8000 The amount of credits a player must pay to build a type 1 Starbase. For simplicity, this parameter is actually entered as a 'price per fighter strength'. Since a fighter costs 100 you can easily set the Starbase price to, say, half of the equivalent fighters price... in this case, 50 credits per 'fighter strength'. 8. Time limit parameter (10 - 60) = 30 This parameter is used along with antimatter quantity to determine the time limit for a session. A session time limit is based on 2 things. First of all, each session automatically gets 5 minutes regardless of antimatter quantities and the setting of the time limit parameter - if the player has any time left at all that day. Second, aside from default 5 minutes, time is issued based on the quantity of antimatter the person possesses AND this parameter. For example, if a person has a full daily issue of antimatter and this parameter is set to 20 they would get a 20 minute session limit. If the they have 10% more than the daily issue of antimatter, then a setting of 20 would get them 22 minutes (1.1 * 20), etc. If, however, they have used half of today's issue of antimatter in an earlier call, then a setting of 20 would yield them only a 10 minute time limit (20/2). A setting of about 4 minutes per 10000 grams of antimatter usually gives plenty of time. If your system has mostly experienced players, use a smaller number. The total daily time limit is simply twice this number. Therefore, if the time limit is set to 30 minutes, no one can get more than 60 minutes REGARDLESS of how much antimatter they might have. The sysop (player #1) always gets a 60 minute session limit regardless of this setting. 9. Bell on time (don't ring before) = 9 This controls the bell when a person uses the summon the sysop function. Enter the hour that you want the bell enabled. For example, if you get up at 9 am, set the parameter to 9. (use 24 hour format). To disable the bell, set this and the 'Bell off time' to the same number. 10.Bell off time (don't ring after) = 20 Like the 'bell on time', this controls the bell. Enter the hour in 24 hour format that you want the bell disabled. To have the bell disabled at 8 pm, set the parameter to 20. 11.Price of player strength calculations = 1000 This is the price in credits that players will be charged to do "net worth calculations" on other players. 12.Operating through Com: port 1 or 2 = 1 This switch tells the system which COM: port your modem is attached to. If your modem is attached to COM2: then set this should be 2. 13.Start Fighters with new ship = 100 This number controls the quantity of fighters issued to new players and to players getting a new ship after losing their old one. 14.Remote Validation Password = none This will be the secret password that you would use to validate someone at validation level 1 (class F) remotely. It can consist of upper case letters, numbers, and special characters. For example, to validate JOE BLOW (a new, registered but not yet validated player) you can call the board and enter JOE BLOW at the name prompt and then this secret code at the password prompt. Of course, if you are at your computer you can use CZAR_UTL to set a validation level to any valid setting. NOTE: Entering a password in lowercase here will disable this feature. 15.Enable programmatic ship upgrades = 1 This switch controls upgrades to higher class ships. If set to 1 players will be able to upgrade their ships ships (and raise their validation level as well) at any Hardware port. If set to 0 they will not be able to upgrade - you will have to do any upgrading with CZAR_UTL. You might want to disable programmatic upgrades if you solicit donations to your system. As an additional incentive for your users to contribute you can then give Class 'A' ships only to those users that do. 16.Cost of ship upgrades / Antimatter bonus = 25000 10 The first parameter (upgrades) represents the cost in credits of an upgrade to the next validation level (and ship class). This is the price a player would have to pay at a Hardware port to upgrade his ship. Of course, this parameter is meaningless unless programmatic upgrades (parameter #15) is enabled by setting it to 1. The second parameter (Antimatter bonus) has an effect regardless of the setting of parameter #15. It controls the awarding of extra antimatter to superior class ships. The number represents the percentage over the standard antimatter issue to be given to players with upgraded ships for EACH level they have upgraded over class 'F'. If it is set to '10' then class 'A' ships will be given 50 percent more antimatter than class 'F' ships. If you have programmatic upgrades enabled, keep this one small. If, however, you set programmatic upgrades to manual and charge your users for class 'A' ships, you can use this to make contributions much more attractive by setting it to give contributors an extra 10-100% (or more) antimatter. 17.Lock out 300 baud access = 0 Setting this parameter to a '1' causes 300 baud callers to get this message; "300 baud in not supported". Setting it to 0 enables 300 baud callers to connect. This parameter applies only in stand-alone BBS mode [CZAR_PGM/M]. 18.Modem Setup & modem options = ATS12=20S10=99S7=40E0X1V1M0 This is the setup string that is sent to initialize the modem each time the system goes to wait for a call. It is set up for a Hayes compatible modem but can be changed to any string up to 40 characters long. Other options here include : modem reset string modem answer string modem hangup string Each of these three options can be disabled by entering "NONE" (in uppercase as shown) rather than a modem string. In the case of the modem reset string, entering NONE will prevent resetting the modem prior to sending the setup string each time the program goes to wait on a caller. Disabling the modem answer string by entering NONE will prevent a string from being sent to the modem when the phone rings. If you do this you will have to set your modem to autoanswer either by a hardware switch or by putting S0=1 (or appropriate instruction) in the setup string. In the case of the hangup string, entering NONE will cause the system to hangup by the 'DTR drop' method. This will be faster than using a hangup string but may not work with all modems. 19.Modem type (1=300, 2=1200, 3=2400, 4=9600 bps) = 2 This parameter tells the software what speed modem you have. As indicated, enter a '1' for a 300 bps modem, '2' for 1200 bps, '3' for 2400 bps, and '4' for 9600 bps. 20.Map size (1, 2, 4, or 8) = 4 This parameter tells the program how much of the map to use. If you set this option to 1, then players will only be able to get to the first 500 sectors of the map. Using a 2 opens 1000 sectors and a 4 opens up the entire map of 2000 sectors. You may want to start out with a 500 sector map and only raise it as you get additional users (to keep it lively). I recommend setting it at 500 until you get about 15 active players, then raising it to 1000 and raising it again when you add 15 more players. NOTE: Although all new maps are only 2000 sectors in size, you can now set this option to 8. A setting of 8 will cause the CZAR_UTL program to build a mirror image of the first 2000 sectors starting in sector 2001. The end result will be a 4000 sector universe with all the galaxies, planets, and ports duplicated - only reversed in position. For example, sector 1 would be duplicated in sector 4000, sector 2 in 3999, etc. Do not do this until your game has become quite active. I would suggest you leave it at 2000 sectors until you get about 40 active players. NOTE: If you do decide to expand the map, you can use option 17 under the CZAR_UTL main menu to reorganize the galaxies in the upper 2000 sectors (using manual galaxy selection). Please note that you can not use this option to reorganize an area in an ongoing game that has previously been available to players - use it only on the upper 2000 BEFORE allowing players access to it. 21.Public mail fixed and char cost = 3000 5 These parameters control the cost to post public mail. The first one (fixed cost) is a fee for posting a public message, regardless of length. The second number (character cost) is an additional charge for each character typed into the message. For example, a 100 character message would cost 6000 credits using the above prices (5000 + 100 * 10). 22.Price of a sector sign = 3000 This price controls three things: 1) the price to post a sector sign 2) the refund when you remove a sign of your own 3) the fee to remove someone else's sign If this parameter is set to 3000, then it would cost a player 3000 credits to post a sector sign. He would then be given a refund of 90% of the original price when he removed it (2700). If, however, he attempted to remove someone else's sign, it would cost 50% above the sign cost (4500 credits). D. Routine system maintenance: In addition to configuring the system and validating users CZAR_UTL has 15 other assorted maintenance functions. They are explained below: <1> Configure the System Parameters (explained in section C above) <2> Validate/invalidate/change validation level The Sysop was entered initially during the automatic installation process with a validation level of '1'. There are other validation levels you will need to become familiar with since you will need to use this option to validate players. The validation levels have the following definitions: ' ' (a space) a new player, not yet validated '0' a player deliberately un-validated (has no access) '1' a player validated at class 'F' ship level '2' class 'E'. '3' class 'D'. '4' class 'C'. '5' class 'B'. '6' class 'A'. When you need to change someone's validation level (a new, recently verified player, for example) you can use this function. Simply enter 2 to select this routine and then enter the name of the person to be validated (or invalidated, as the case may be). You will then be asked for a new validation level for the person. Select one of the above options and press return. <3> List players to video or printer This option will list all players' validation levels, names, phone numbers, Stardate of last logon, and player number. You will be prompted for whether you want the list to go to the video or to the printer. This is frequently used to list new players (blank validation level) along with their phone numbers for validation purposes. This routine also has an option to search by validation level. For example, if you wanted to list only those players with a validation of 0 then you would enter a 0 at the validation level prompt. Likewise, if you wanted only players with a space in the validation field (new players), then you would enter an "S" for Space. You can also use the "N" option and search through the player file for names or name fragments. For example, if you will looking for someone named "RAY" you would enter "RAY" as the text to search for. You would then get a list of all players whose name contains the fragment "RAY", regardless of where it occurs in the name. <4> Delete players by name, date, or 0 validation This option allows the SYSOP to purge old and inactive players from the user file to make room for new players. It also will purge any messages in the history file and the mail file that are addressed to a user being purged. Any signs left by a person being deleted are automatically removed from the map file as well. You will be prompted for whether you want to delete users based on date (period of inactivity), name (select a specific individual), or those with a validation level of 0 (people un-validated by the SYSOP). NOTE: When deleting an individual by name you MUST enter the COMPLETE name in UPPER CASE characters. NOTE: Deleting users by either date or validation 0 can be very time consuming if there are a lot of players affected. Therefore, an option has been added to terminate purging prior to completion. Pressing the [Esc] key during these multiple user deletes will cause the purge to terminate immediately after removing the current user. (there may be a delay of 10 or 20 seconds before it actually quits) <5> Edit a player record. Be careful with this one! It allows you to change a player's name, address, ship name, amount of fighters, amount of cash, etc. <6> Edit map file (change ports/planets/warps) Be very careful with this one! It lset you to change warps, add, change, and delete planets and ports, insert and delete signs etc. In general, it allows you to change any feature of any sector in the universe. With it you can redesign the entire map, change productivity of ports and planets, add and delete Pulsars and Black Holes (and their warning signs!), create additional government controlled sectors, and accidentally make areas with no exit!! So again, be careful. <7> Search map file for ships This option will search the entire map file and report all ships (along with the owners name) to the video. It will also report and, at the same time, purge any 'ghost ships' (with an audible 'beep') in the universe. A ghost ship is an image of a ship that appears in the wrong sector. It should only happen when a player moves from one sector to another and the power goes down between the times that the map file and the player file are updated - causing them to get out of sync. Though generally not serious, it does have two effects. One, a ghost ship (invisible to other players) appears in one or more sectors. And two, the persons ship disappears from the sector it is really in (meaning other players cannot see any evidence of the ship in ANY sector). The players ship will reappear as soon as the they get back on and play out the rest of their turn. <8> System Statistics This item will tell you how many players there are in the player file, how many messages in the mail file, and how many entries in the history file. In addition to those numbers, it will also tell you the percentage of each of the previous files that is filled - useful when determining if you need to purge some inactive players. It will also give you a login count. This count is the number of SUCCESSFUL connections received by all players CURRENTLY on the user file. Therefore, if you purge some players from the system, this number will decrease. <9> Scan the map for signs This routine will search the entire map file and list all signs in the entire universe to the screen. It also shows the user number of the player who posted each sign (signs with a user number of 0 are government signs). This option should be used now and then to make sure no obscene signs are being posted in remote sectors of the universe. If such a sign is found, you can use option <5> (Edit a Player Record) to determine who posted it and then take appropriate action. Also, you can easily remove any sign with option <6> (Edit map...). Don't forget to reset 'Sign Author' back to 0 if you remove a sign. <10> Scan the map for fighters This routine will search the entire map file and list all fleets of fighters (and Starbases) guarding sectors in the universe. It will also list the owner of each fleet of fighters. <11> Reset a player's last logon date This option allows you to reset a player's last 'logon time' so that they may be able to log on and (optionally) issued the daily amount of antimatter. NOTE: If you reset a player's time back past midnight, they will be issued the daily allowance of antimatter even if they have already played today! <12> Banish a player from the system for X days This option allows you to reset a player's last 'logon time' so that they will be locked out of the system for the number of days specified. <13> Initialize the map (explained in section B-2 above) <14> Initialize the game This option is used only if you run games with time limits or otherwise want to end a game and start a new one. The advantage that it offers over repeating the installation process are: 1) All parameters are left as previously set. 2) All players registration information remains intact. 3) All players are notified that a new game has started. This routine will delete everyone's ship, remove all fighters and signs from the universe, and automatically do a map initialization (option 13). The starting of a new game is an excellent time to change a few parameters to better suit your boards desired 'personality'. <15> List the map file to printer or video This option allows you to list out sections of the map. It will prompt you for beginning and ending sector numbers, ask whether you want to list the map to the video or to your printer, and then proceed to list out the section of the map you are interested in seeing. It shows ports, warps, planets and signs. <16> List/Purge the message file This selection will allow you to browse through the message file, reading and purging messages. It skips over blank messages and prints an "*". <17> Generate sector warps (use to reorganize galaxies in map file) This routine is used to modify warp connections within the existing map file. When you first bring up Czarwars this routine will be automatically executed if needed. Therefore, it won't be necessary to select it unless you specifically want to change around the galaxies in the map. NOTE: Use this only when starting a new game - it will delete players' signs and Starbases! ===== A note to Sysops with a copy of the advanced map file ===== If you have a copy of the advanced map you may still want to re- organize part of the map with this routine (for your first game or two, anyway). Since this option can generate very simple maps including easily navigated 'toroidal' galaxies, new users may find it much simpler to move around and trade. However, it will also be less interesting than the advanced map which has dead ends, one-way warps, easily defended areas, and mazes. If you want a map that is half simple and half complex you can use this routine to re-organize the bottom 1000 sectors of the advanced map into simpler galaxies. You may also use this routine to convert the dreaded one-way maze in sectors 1001-1350 to simpler galaxies since it is by far the most difficult area to navigate. [99] Exit to DOS This option (the default) exits from CZAR_UTL and returns to DOS. E. Information on running the system: 1. Using the logfile (CZAR_LOG.TXT): If you invoke CZAR_PGM.EXE with the /L switch, Czarwars will keep a log of all calls. Contained in this log is information such as the time and date that the phone was answered, the baud rate of any successful connection, the name of the player who logged on, records of any errors (such as i/o errors), and other information. The logfile also can contain messages to the SYSOP by non-validated users. Whenever a new user registers on the system for the first time, a special entry is made in the logfile. It will include the players phone number, name, any message that he might have left, as well as some eye-catching characters to make it stand out from the rest of the routine log entries. You need to look at this file often (every day or two) so you will know when you need to validate new users, etc. (If you run in stand-alone mode without the /L switch, you will need to list players in the CZAR_UTL program who have a space in their validation field). It is also useful for determining when players are using "clone" ships - extra pseudonyms to gain an advantage. If several players call every day, one after the other, using the same baud rate, for example, you might look carefully to ensure that they aren't just one player who had some friends register and give him their passwords. The extended logging modes (the 'old' /L and /X switches) are no longer supported - having been replaced by the 'new' /L mode. 2. Terminating a user's session: If you have need to hang up on a player, just press the [Esc] key once. The system will then hang waiting on confirmation from you (Really hang up on this user? [N]). If you then press "Y" and the system will hang up and go on to wait for another call. 3. Chatting with a user: Press the F10 function key to toggle chat mode on at any prompt. Press F10 again to turn off chat mode. 4. Backing up the system: Periodically (preferably every day) you need to make back up copies of the Czarwars data files on a floppy disk. There are, of course, many things that can happen to files on a hard disk - most of them bad. With a day-old set of backup files you could simply reload the game and notify your users of what had happened - not a major inconvenience for anyone. Without backups you would be forced to start a brand new game - which some users will no doubt find very annoying. The only files that must be backed up are those that end with an extension of .DAT. They are: CZAR_PLR.DAT (player file - all player info except deployed forces) CZAR_MAP.DAT (map of the universe - and players' DEPLOYED forces) CZAR_HST.DAT (history file - events happening to players) CZAR_MAL.DAT (message file) CZAR_PRM.DAT (parameter file - has all system configuration info) CZAR_NEW.DAT (news file - encoded. use CZARNEWS.EXE to generate text bulletins for use elsewhere in the system if needed) I suggest that you compress these files with an archive program and then freshen the archive daily. The archive file will be a small fraction of the size of the full-blown data files and is easily backed up. My backup archive is usually under 130K. The logfile (CZAR_LOG.TXT) may be backed up as well, if desired. It is possible to continue a game if you have only the player and map files - but you will have to re-enter the configuration parameters and players will lose their mail and history information. So, at an absolute minimum, back up the player and map files - they are necessary to continue the current game. 5. The Bulletin, Pre-Logon Bulletin, and Information/Rules files: These three files are necessary for the system to run. The bulletin file (CZAR_BUL.TXT) is an ordinary text file and can be modified by most any word processor (in non-document mode) as well as ASCII editors such as EDLIN. Here is where you make announcements and post bulletins. You should keep this one SHORT since it lists for everyone who logs on. The Pre-logon file (CZAR_PRE.TXT), too, is an ordinary text file. It is displayed PRIOR to a person being prompted to log in. As a result, it is an excellent place to identify your system, list your hours, and possibly tell new users to use their real names. You should also keep this one as short as possible. The Information/Rules file (CZAR_NFO.TXT) is where you would put your system rules and any other information about your system (such as: Send $5 and you will be issued a class 'A' ship (more hold capacity and 50% more antimatter)). 6. The Help file: The help or 'instructions' file (CZAR_HLP.TXT) is required for the system to function. It ordinarily doesn't require any modification. 7. Connection information: Czarwars only supports 8 data bits, no parity, and 1 stop bit. 7 data bits is NOT supported. People who connect at 7 data bits will get strange results in both /PCB modes and /M mode. 8. Maps: Paper copies of the advanced map are not available. 9. SHELLing to DOS (REMOTE): This option is no longer supported. In order to validate users remotely, use SYSOP mode to enable the '? LIST LOG' option for identifying newly registered players and then use the remote validation password to validate them. As of version 3.55, it is possible for a sysop to configure the 'door' with DOORWAY or an equivalent utility to serve as a shell to DOS. See the information concerning /ES mode in section L below. 10.SYSOP mode: This option is only available to the sysop (player #1). It enables the sysop to move directly to any sector in the universe without being attacked by fighters left on guard. It also permits the sysop to send public mail and do player strenth calculations without paying. In addition, it permits the sysop to list (and delete) the log file while logged in the game. To activate it go to the tilities menu and type SYSOP. It will respond with "sysop mode on.". To disable this mode repeat the process used to enable it. It will respond with "sysop mode off." when disabled. 11.SHELLing to DOS (LOCALLY): In order to activate the F5 function key for shelling to DOS (as described below), CZAR_PGM must be invoked with the command line switch /SHELL. If you are using I/O redirection (DOORWAY, etc) do not do this! DOORWAY (and similar programs) route keyboard control to the modem and would permit the caller to shell to DOS! With the /SHELL switch supplied on the CZAR_PGM command line as in the following example the sysop can shell to DOS from the console: CZAR_PGM /SHELL/PCB14 The sysop can now shell to DOS locally by pressing the F5 function key while a player is logged in. In order to return the player to his session, you must return to the SAME DIRECTORY that CZAR_PGM is run- ning in. Failure to return to the czarwars directory before EXITing from DOS will cause a fatal error! F. Performance and maintenance considerations: The following information is for optional speed/performance improvements to the system. To speed disk access to the system, load all Czarwars files together (in adjacent spots) on the disk (especially the map file and the player file - the ones used most). Also, try to load them unfragmented. Once loaded, they will not move around or become fragmented on their own - they will stay in the exact spots where you put them. A program that reorganizes disk files and unfragments them will make this task simple (as well as improving the disk performance of other programs). Another way to both improve disk performance while simplifying backups is to put the entire Czarwars system in its own 1.5 or 2 megabyte disk partition. Of course, optimizing the partition with a program like the one mentioned above will further improve performance. With a very fast hard disk drive, these changes will make only a modest improvement. However, if you have a slow 'average access time' drive, following these recommendations will make it seem VERY fast since the drive heads will have only a very short distance to travel in even the worst circumstances. Czarwars runs completely maintenance-free in the /PCB14 mode. In the /M mode (as a BBS) it only requires that new users be validated by the Sysop. Though regular backups of the .DAT files are recommended and most Sysops like to answer their mail, there are actually no other on-going requirements to keeping a Czarwars game up and running. If you use the /L switch to cause Czarwars to keep a log file you will, of course, have to periodically remove it. G. PCBoard Doors / Running under PCBoard v12, v14 and other BBSs: There are several things to consider in addition to the advice given above if you intend to run Czarwars as a DOOR under another BBS. PCBoard mode: Running under PCBoard version 12 & 14: First of all, install Czarwars in its own directory. Since Czarwars will need to read the PCBOARD.SYS file in these modes, you must include in your door batch file a copy command to copy the PCBOARD.SYS file to the Czarwars directory. NOTE (4/15/89): Czarwars no longer looks for the PCBOARD.SYS file in its 'parent' directory. Your door batch file MUST be changed. Sample directory name: C:\PCB\CZAR Second, do NOT use a carrier monitoring utility such as 'WATCHDOG'. Czarwars will terminate on its own if the user drops carrier. However, if the system gets rebooted immediately after carrier drop (and prior to Czarwars closing its files and terminating) some of the Czarwars files may not be updated. Third, a sample batch file is included with the software called CZARDOOR. This file should work with version PCBoard v.14 if you name your Czarwars directory as indicated in the batch file. If you use PCBoard v.12 you must change the /PCB14 switch in the CZARDOOR file to /PCB. Fourth, since Czarwars doesn't support 7 data bits, you may want prevent connection at 7 data bits in PCBoard. Command line mode: Running Czarwars from doors using command line parameters: To run Czarwars in doors mode using command line parameters you must invoke it as follows: CZAR_PGM !2400 RAY YEARGIN As you can see, a ! is used followed immediately by a FOUR DIGIT baud rate. Valid baud rates are 0300 1200 2400 4800 9600 1920 and LOCA for connections at the console. Starting 2 spaces after the last character of baud rate is the user's name. This name should usually consist of first and last name separated by 1 space. It can be up to 20 characters in length. With the exception of the way baud rate and user name are passed to CZAR_PGM, this doors mode should behave exactly like /PCB mode. Another example follows (of the Sysop opening the Czarwars door while logged on locally) CZAR_PGM !LOCA SYSOP NOTE: any other switches that you may want to use must be placed BEFORE the ! on the command line as follows: CZAR_PGM /L !LOCA SAMPLE USER Generic Doors: Running the system through another (non PCBoard) BBS's 'DOORS' facility without the ability to build a PCBOARD.SYS file: Use an I/O redirection utility such as Doorway. Do not use any of the Czarwars switches except for the /L switch (if you want to log events). Use no other switches since they all attempt to handle the com port. In local mode (no switches except maybe the /L switch) it is easily handled by Doorway. Note: in this mode Czarwars will act like a stand-alone BBS - meaning you'll have to validate all the users with the CZAR_UTL program. H. Common (and some uncommon) errors codes that you may see: The most frequent error you will encounter is 'I/O error (57)'. These will be common when there is noise on the phone line. In addition, you will occasionally get one for no obvious reason. Another common error is 'error code 24' (see next paragraph for more on error 24). You will get this error whenever a user hangs up abnormally or otherwise drops carrier. A much less likely (though still fairly common) error is 'error code 69'. This one occurs when there is a buffer overflow - usually caused by someone uploading a message at a rate faster than the BBS can accept it. In some circumstances, it can be caused simply by holding the key depressed continuously. This error will be slightly more common with slower computers and when running the BBS in a multi-tasked environment. 'Error code 24' can also be caused by your cable or modem not supporting the CTS signal. If you're always getting this error - whether a user is on-line or not - this is probably the problem. Try the following to check for this problem. Run CZAR_PGM with the /M switch only. CZAR_PGM /M If it continually recycles after displaying 'Error code 24' about four times each, then try this: Run CZAR_PGM with the /M and the /CTS0 switches. CZAR_PGM /M/CTS0 The /CTS0 switch disables the checking of the CTS signal so, if this is your problem, /CTS0 should cure it. If so, add /CTS0 to the line that invokes CZAR_PGM. Other error codes: 64* Possibly means you have configured the BBS to use a com port that doesn't exist. This error is sometimes followed by error 52*. Also, error code 68* indicate possible problems with the communications port. 53* Possibly caused by the absence of one of the required BBS files or by too small a number of FILES declared in the config.sys file. 61* Probable cause: The disk drive containing the logfile is full. 6 Overflow/underflow. A number was used that exceeded the limits of a variable - this usually is a response to an invalid input by a player. * The preceding errors flagged with an asterisk are serious and will generally bring down the BBS. Other listed errors (57, 69, 6) should cause no problem unless 12 or more are detected in a single session. In that case, the system will recycle, therefore bumping off the player who incurred the multiple errors. Most other errors can be found in a GW-BASIC or BASICA manual. I. Support: Registered users of Czarwars are provided support via the "Home of Czarwars" BBS system. The latest version of Czarwars is available for examination through a door there. You must be registered on the system before you can enter the Czarwars door, however. This system is online 24 hours a day at 9600 Hayes/2400/1200 BPS at 8 data bits, no parity, and 1 stop bit. Home of Czarwars: (904) 878-7704 On your first call, leave any questions or remarks in a omment to the Sysop. As a registered Czarwars Sysop, on subsequent calls, you will have access to the regular mail system as well as the Czarwars Sysop Conference and file library. J. Upgrades: Any registered Czarwars or Tsarwars Sysop can upgrade to the latest version of Czarwars at any time for $10. NOTE 4/15/89: It is now possible to remove the 'UNREGISTERED Copy!' line from new, publicly distributed copies of Czarwars. Registered copies of Czarwars now include a file named REGISTER.COD which will include a code and instructions for putting registration information into all future releases. The upgrade by mail (described above) will still be offered for those who prefer it. Send any upgrade requests and written correspondence to: Ray Yeargin P.O. Box 5821 Tallahassee, FL 32314-5821 K. Running Czarwars in stand-alone mode from a batch file: Czarwars will automatically recycle when used in the /M mode. If you want to have it exit to DOS after each call (and subsequently be invoked again by a batch file) use the /1 switch: CZAR_PGM /M /1 A sample batch file [CZAR_BBS.BAT] is included to demonstrate the use of the /1 switch and to show how to implement a 'sysop-only door'. It can be modified to use in (external recycle) mode by simply adding a /1 switch to the end of the the CZAR_PGM line. This batch file also demonstrates how to test for the existence of the CZAR_BBS.END file which indicates that the Sysop pressed [Esc] to bring down the system. L. Opening the door under the Utilities menu: If you're running Czarwars in stand-alone mode, you will probably be interested in setting up a 'drop to DOS' or the CZAR_UTL program to be run under the main program. This can be accomplished by invoking Czarwars with the /ES switch. /ES (only the Sysop can open door - in SYSOP mode only) /EA (the Sysop -and- players with Class A ships...) /EB (everyone can open the door) The /ES switch tells CZAR_PGM to show the 'OPEN' menu option when the sysop enters SYSOP mode. When the door is opened, Czarwars will invoke the batch file named EXTERNAL.BAT. You must modify this file to run whatever program you need. See the CZAR_BBS.BAT and EXTERNAL.BAT files for an example of installing a 'door' under Czarwars. ===========================================================================