OS/2 Shareware BBS: 2 BBS

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

/ OS/2 Shareware BBS: 2 BBS / 02-BBS.zip / gmn!2_10.zip / GMON.DOC < prev next >

Wrap

Text File | 1993-08-09 | 87KB | 2,159 lines

╓──┐ ╓─┐┌─╖ ╓──╖ ╓┐ ╥ ║ ─╥ ║ └┘ ║ ║ ║ ║└┐║ ╙──╜ ╨ ╨ ╙──╜ ╨ └╜ ╓─────── ║ ╙──────╖ ║ ║ ───────╜ A N D ╓──┐ ╓─┐┌─╖ ╓──╖ ╓┐ ╥ ║ ╓──╖ ║ ─╥ ║ └┘ ║ ║ ║ ║└┐║ ╓╜ ╓──╜ ╙──╜ ╨ ╨ ╙──╜ ╨ └╜ ║ ╙──╜ Door File Conversion, Integrator, and Organizer By John Morris SysOp Reference Guide Copyright (c) 1991-1993 by John Morris All Rights Reserved Page 2 CONTENTS Software License . . . . . . . . . . . . . . . . . 2 Warranty. . . . . . . . . . . . . . . . . . . . 2 Features. . . . . . . . . . . . . . . . . . . . 3 Hardware Requirements . . . . . . . . . . . . . . . 3 GMon Version History. . . . . . . . . . . . . . . . 4 Manual Conventions . . . . . . . . . . . . . . . . 6 Command Line Switches . . . . . . . . . . . . . . . 6 Function Keys . . . . . . . . . . . . . . . . . . 8 Batch Files Needed To Invoke GMon 5. . . . . . . . . . . 9 BBS Programs GMon 5.0 Will Run With. . . . . . . . . . . 10 How To Interface You Unsupported BBS To GMon. . . . . . . . 13 Getting Started With GMon 5.0. . . . . . . . . . . . . 18 GMon Editor - Main . . . . . . . . . . . . . . . . 18 Command Letters & Security Levels . . . . . . . . . . 22 Time Limits. . . . . . . . . . . . . . . . . . 23 Program Editor. . . . . . . . . . . . . . . . . 23 User Editor. . . . . . . . . . . . . . . . . . 28 Category Editor . . . . . . . . . . . . . . . . 28 GMon Text Files . . . . . . . . . . . . . . . . . 29 GMon Macros. . . . . . . . . . . . . . . . . . . 30 Upgrading To GMon 5.0 . . . . . . . . . . . . . . . 31 GMon Files . . . . . . . . . . . . . . . . . . . 32 GMon Bulletins. . . . . . . . . . . . . . . . . . 32 Program Menus . . . . . . . . . . . . . . . . . . 33 Before & After Text Files . . . . . . . . . . . . . . 33 Thanks . . . . . . . . . . . . . . . . . . . . 33 Problems? . . . . . . . . . . . . . . . . . . . 34 How To Reach Me . . . . . . . . . . . . . . . . . 34 APPENDIX A: How The Points System In GMon Works. . . . . . . 35 SOFTWARE LICENSE GMon is released as Shareware. You may use GMon for any commercial, or non-commercial purpose. Use it on your company, private, or school BBS. If you have thought of another way to use GMon, feel free to use it that way. You may copy and distribute as many copies of the program as you like, as long as you don't charge money for the program itself. A small fee is allowed for copying, handling, mailing, and the diskette carrying the copy, but this amount is not to exceed the real costs. GMon should not be used or distributed in modified form. If you use this program on a regular basis, you are required to register your copy. By registering GMon, you are helping the author to continue to provide quality software. WARRANTY GMon is provided as is, with no warranty of any kind, either expressed or implied. The only guarantee is that GMon will take up space on your disk. Page 3 FEATURES OF GMON o Allows the use of virtually any door program from any BBS program. o Acts as a central door 'hub' program. All your doors can be run from GMon eliminating the need for complex door menus. o Many different BBS's are supported thru the following files: DORINFOx.DEF CALLINFO.BBS PCBOARD.SYS DOOR.SYS CHAIN.TXT LASTUSxx.DAT EXITINFO.BBS SFDOORS.DAT & more! o Converts from the above file formats to even more door file formats, including: all of those above & OPENDOOR.SYS (Fast Finger Doors) USERINFO.TXT (MG Generic doors, like Planet Busters) DOORFILE.SR (Solar Realm Doors) & more! o Up to 500 doors can be set up to run from GMon at any one time. o Full network support using SHARE.EXE for file sharing & record locking. o Supports 'local only' operation for local use without having to load your BBS. o Support for up to 256 nodes. (36 under RBBS-PC) o Contains its own ANSI driver. (ANSI.SYS does not need to be loaded) o Support for FOSSIL communications drivers. o Support for BPS rates to 115200 (38400 with a FOSSIL driver) o Support for non-standard communications ports. o Supports flow control for high speed modems. o Contains its own carrier detection routine. (no watchdog program needed) o Multi-tasker aware. (Desqview, DoubleDOS, & DOS/Windows/OS2 idle calls) o Keeps track of time used. o Time of day usage can be controlled. o Time limits according to security level. o 20 separate security levels/time limits can be configured. o SysOp can chat with user. o Bulletin support. You can have your door programs create bulletins that can be read by GMon, eliminating a lot of game bulletins in your BBS. o Editor program built into main program. o Full control over how a door runs. By COM, EXE, or BATch file. o Macro language for text files used by GMon. o Support for 4 different ways of naming text/color menus & bulletins. o Controls use of non-network programs on multi-node systems. o & MORE! HARDWARE REQUIREMENTS GMON 5.0: o Any IBM PC or compatible computer with at least 200K of memory. o DOS 3.1 or above (3.3 or higher recommended) o Approximately 300K of disk space. GMON/2: o Any IBM PC or compatible computer with a 386 (or greater processor) o OS/2 2.1 o Approximately 300K of disk space. Page 4 GMON VERSION HISTORY I conceived of GMon over 6 years ago. It has gone thru many revisions, and is now finally becoming a program I like. I wanted a small, flexible, and fast 'monitor' program for my BBS. I orignally wanted a 70-80K program, but GMon 4.0 weighs in at about 140K. The good part about that is the fact that GMon can now shrink the amount of memory it uses to an amount close to 1 or 2K when running a door. GMon is now always in memory while a doors are being run. This allows for better door control and eliminates the need for a bunch of batch files to run each door. GMon started out as a central program from which I could run all my doors, but it ended up as more of a door control program allowing me to run nearly any door thru it. 01/10/88 - GMon 1.0 -------- First release of GMon. Written to be compatible with Bob Westcott & Rod Bowman's Door Monitor program, with improvements in speed and size. Also included conversion code to run PCB 11, or PCB 12 doors. GMon knew they were PCBoard doors by the fact that a string (either PCB11 or PCB12) was in the description). Made to run under RBBS-PC only! 01/24/88 - GMon 2.0 -------- The GAMES.DOR file was completely reworked to be more flexible. Eliminated the need for certain strings (ie. 'PCB11' or 'PCB12') in the description to run PCBoard doors. Instead you just change the program 'type'. The batch file used by GMon was changed from GMONPCB.BAT to GMONEXTx.BAT. Two reasons for that, 1: to make sure the correct batch file was being run on multi node systems, and 2: to reflect the fact that not all doors would be PCBoard ones in the future. The user interface was changed to look more like an RBBS command prompt, thus making the user feel more at home (I hope!) You can now customize the menu the users sees. The X-pert toggle command was added to switch the menu on/off. 02/28/88 - GMon 2.1 -------- Several bugs fixed. More complete info on batch files was included in the docs. It should now run single and multi node BBS with the same ease. 03/13/88 - GMon 2.2 -------- These were the days of the quick update huh? Fixes applied to the PCBoard interface which includes a total rewrite of the PCBOARD.DAT files that GMon outputs. This seems to clear up the 'error 62 at line 10040' problem with PCB12 doors (using Door Patch). Also PCBoard mode 4 was included which will write out a plain PCBOARD.SYS and PCBOARD.DAT file. Hopefully this will make GMon compatible with other PCB 12 games. SysOps, hitting F1 will tell GMon to immediately exit to DOS.. (just in case) 04/10/88 - GMon 2.3 -------- The PCBoard interface was rewritten (again) so that GMon would output a 'fake' PCBoard USER file along with the other PCB files GMon was already creating so that Dorpatch routines greater than 2.6 would run. These fixes work automatically, so you don't need to anything except add the game to the GAMES.DOR file, and they should run. A bug in the program which caused the amount of time used to be miscalculated was cleared up. Also added was an improved GMon edit program call GMedit20. It includes a NAMES.DOR editor in addition to the older GMONEDIT functions. Page 5 02/15/89 - GMon 3.1 (3.0 only released as a beta test) -------- Several new features added this time. Main feature? hmmm.. howsabout a 15K smaller EXE file.. thats the main feature. Added several new switches. You can now tell GMon to use separate GAMES.DOR files for each node. The filename would then be GAMESx.DOR (where 'x' is the node number). You can shorten the GMon prompt to 'GMon Command?' eliminating the actual command letters (A,B,C.. etc.) If you have this feature turned off, GMon will look and behave exactly as before. GMon also has a batch mode so it can be used as a simple RBBS to PCB11/PCB12/PCB14/GAP/WILDCAT file conversion program. GMEdit30 has been rewritten to be used locally, or from remote! Added to GMEdit30 is a GAMES.DOR editor. GMEdit30 can be accessed by using the SysOp command 'E'. Be sure GMEDIT30.EXE is in the current GMon directory. When editing the GAMES.DOR file, GMEdit may change the 'look' of your GAMES.DOR file but does not effect the way it works in any way. 02/25/89 - GMon 3.11 -------- A maintenance update to fix a problem in the /C3 and /C4 modes which caused an 'illegal function call' error. 09/24/89 - GMon 3.13 -------- Another maintenance update, along with a couple added interfaces. GMon should now enforce time limits correctly in all cases. Formerly an entry in the TIMLIMIT.DOR file which looked like: 9,45,90,, would give the error "you must call between 0000 and 2359" This error was fixed. Added interfaces are an OPENDOOR.SYS (Fast Fingers Door Program), and a USERINFO.TXT (MG Generic format for games like Planet Busters) Also **NEW** batch file info. Some external door programs tend to -eat- command line parameters. So if you run a multi-node system this causes items like node numbers to get lost! The fix is in the batch file section. MONITOR1.EXE is written in C to save on some disk space, and file xfer size. OH YEAH!... Almost forgot. I did some work on GMEdit30.. and fixed some really nasty GAMES.DOR Editor errors. It is now know as GMEdit31. 1990 - GMon 3.2 -------- Given out to only a few guys.. featured FOSSIL driver support. 01/19/92 - GMon 4.0 -------- GMon was utterly rewritten. It is now in C in place of BASIC. Now is no longer RBBS-PC specific. It should work under any BBS program, and convert files to almost any BBS interface or door interface file. Is now one single program, with the editor in the main program. All file formats have changed, so GMon 4.0 is not fully compatible with the old Door Monitor, or even older versions of GMon. _BUT_ it still works in a similar manner. All files can be edited by the GMon editor included in the program. Instead of exiting to DOS, or RUNning a program as in the BASIC version, GMon will swap itself out of memory and 'spawn' to the door. The door can be a COM file, an EXE file, or a BATch file. If it is a batch file, GMon will execute a copy of COMMAND.COM (or whatever your DOS shell is) and have it execute the batch file. This way GMon never actually leaves memory. This also usually eliminates the need for batch files. Swapping takes place to either EMS, XMS, or to disk. Specific commands lines and evironment variables can be specified for each door! Games can still be listed by category, Page 6 if you choose, or all together as in the older versions of GMon. A Bulletin menu was added. This allows you to tell your door programs to create bulletins for use by GMon. This eliminates large amounts of game bulletins in your BBS. In other words, the users can read the game score bulletins from the game area, instead of the BBS. Text files (menus, bulletins) can be named in 4 different ways (to work similarly to several different BBS programs). 05/25/92 - GMon 4.01 -------- Maintenance release. Tweaked a couple of the BBS interfaces. I still am looking for some more differences of opinions on how handles should be worked on systems which don't have them, and games that do. Another release to follow shortly. 12/02/92 - GMon 4.02 -------- Maintenance Release - Updated door I/O routines. Chat mode string now properly says SysOp & User name. MANUAL CONVENTIONS This manual contains the following conventions: [option] Any information inside double square brackets is OPTIONAL. Keep that in mind when you read this manual. GMON 5 COMMAND LINE SWITCHES The command line is the information following the program name at the DOS prompt. Command line options must ALWAYS be separated by a space! If there isn't a space, then that command line paramter will be missed. GMON [options] The following options are always preceded with a '/' (forward slash) or a '-' (minus sign) Bxx - Tells GMon to run in Batch conversion mode. 'xx' is the type of file to convert to. [not yet implemented in 4.0] Cv[,ww,xx,yy,zz] Communications port information. You will not need to use this command unless, 1: The GMon docs specifically says to for your BBS program, or 2: You are using a non-standard communications port. (usually COM3 or above) v - com port you wish the program to use. The following information is optional, and is only used when using non-standard communications ports. ww - Base address, in HEX format, of your UART chip. For example: COM1 uses 0x3F8, COM2 uses 0x2F8 xx - IRQ number you wish to use in decimal format. For example: COM1 uses 4, COM2 uses 3 yy - Base address, in HEX format of your 8259 interrupt controller chip. Page 7 In the IBM PC/XT or compatibles, this is ALWAYS 0x20 In the IBM AT there is a second 8259 located at the address 0xA0 The first 8259,at address 0x20,has IRQ numbers of 0 thru 7. The second 8259 chip, found in AT class machines at address 0xA0, contains IRQ numbers of 8 thru 15. zz - Interrupt vector number. For example: COM1 uses 12, COM2 uses 11. At this point you are probably thoroughly confused! Not to worry! There are some general rules to follow in order to set up your non-standard com port. If your IRQ number is in the range 0 to 7, your 8259 address is always 0x20. If your IRQ number is in the range 8 to 15, your 8259 address is always 0xA0. If your IRQ is 3, then your interrupt vector MUST be 11, and vice versa. If your IRQ is 4, then your interrupt vector MUST be 12, and vice versa. Your modem or serial port board manufacturer will supply you with the correct IRQ and UART base address. For Example: Your COM3 serial port is located at 0x2E0, and your IRQ is 4. Remember, IRQ 4 is on the 8259 located at 0x20, and interrupt 12 is always associated with IRQ 4. Your /C command line parameter would be: /C3,0x2E0,4,0x20,12 Another example. Lets say your BBS program doesn't supply communications port information in the information file that GMon reads. You would then need to specify that com port on the command line. Lets say you need com 2: /C2 COM2 is a standardized port, so you don't need to specify the additional port info! E[DITOR] - If you wish to use just the editor (in local mode) use this switch. Fxxxx - This is the directory in which to find the BBS info file to get info in the current user. This overrides the BBS directory you entered in GMon Edit. 'xxxx' is the directory in which to find the file. No trailing backslash. G[RAPHICS] - This switch forces ANSI color on. This is used in Local-only mode. Hxx - (GMON/2 ONLY) Specifies the file handle of the currently open com port. Page 8 L[OCAL] - This forces GMon to operate in Local-Only mode. This is how you can use GMon locally. GMon always assumes that it is the SysOp who is on when it runs locally. Nxx - Where 'xx' is the current node number. Must be used to tell GMon which node it is running under. (unless your BBS info file contains node info) You might want to use it anyway to make sure GMon knows which node it is running under. Pxxxx - This command tells GMon to use a different file to get configuration info from, instead of GMON.DEF. You might do this for a different set up on different nodes, or whatever else you can think of. Usually you will not use this command. Sxxxx - This is used to tell GMon at which speed to operate. If the program saw /S19200 It would open the com port at 19,200 bps. The S command used infrequently, and is only needed in certain situations. If you aren't sure whether or not to use it, don't. Most BBS interface files provide the bps rate for GMon. Remember, most switches never need to be used. The only switches you may frequently use are: /L[ocal] (local mode) /G[raphics] (turn on ANSI mode) /Nxx (node number) To run GMon in local mode, you would use the command: GMON /L You could add a /G to that to turn on Graphics. GMon assumes that it is running on Node 1. On multi-node systems you need to tell GMon which node its on, you would use the /Nxx command like so: GMON /N3 for node 3. For RBBS-PC users, you would still use regular RBBS node numbers, in other words: '1234567890ABCDEFGHIJKLMNOPQRSTUVWXYZ' for RBBS node 11, you would use: /NA GMON SYSOP FUNCTION KEYS GMon has a few function keys enabled so you can control certain aspects of the current session. Page 9 F1 - Pressing the F1 key will the cause GMon to immediately terminate the current session. It will not drop carrier on the user, but simply end the game, and return to DOS and the batch file that ran it. F2 - Shell to DOS. Since this is so infrequently used it isn't set up very well. You must have COMMAND.COM in the current directory for this to work. Type EXIT at the DOS prompt to return to GMon. F9 - This toggles the local display on and off. RBBS-PC and PCBoard SysOps will be familiar with this feature. By pressing F9 you simply change the display status of GMon not the display status of your BBS. F10 - This invokes the SysOp chat mode. Hit ESCape to exit back to GMon. PGDN & - These two keys are used to DECREASE a users time limit. PGDN CTRL-PGDN will subtract 1 minute from the users time limit. CTRL-PGDN will subtract 10 minutes for each press! The results are shown to you in the lower right hand corner. PGUP & - PGUP and CTRL-PGUP are used to INCREASE a users time limit. CTRL-PGUP Pressing PGUP once will increase the limit by 1 minute. Each press of CTRL-PGUP will increase time left by 10 minutes! As above, the results can be found in the lower right-hand corner. End of Function Key Section. SETTING UP BATCH FILES TO RUN GMON To run GMon you usually need to set up a small batch file. This batch file needs to do 4 or 5 things. These are the steps: 1: Change directory to where GMon is located 2: Optional. Copy the BBS interface file to the GMon directory 3: Run GMon 4: Change directory back to your BBS 5: Re-run the BBS batch file (if needed) Step 2 is optional, because in many cases you can tell GMon where to find the BBS interface file in the GMon editor (or on the command line) instead of copying it. A sample batch file, lets call it GMON.BAT, you're running RBBS, node 2, the DORINFO2.DEF is in the \RBBS\NODE2 dir, and you are using COM3, a non-standard port. CD\GMON40 GMON /N2 /C3,0x3E8,3,0x20,11 /F\RBBS\NODE2 CD\RBBS You would need to modify this for your set-up, but you can see how simple the batch file is. In many cases you won't even need a command line, just 'GMON'. Multi-node systems would just need to tell GMon which node, like so: GMON /N4 Page 10 BBS PROGRAMS GMON WILL RUN WITH GMon is no longer 'RBBS-PC specific'.. It will run under many different BBS programs. When you run GMon the first time, you will be shown the GMon editor, and there is where you will tell GMon which BBS program it is running under. I'll give you a list of BBS programs, and what files GMon will expect to get its information from. RBBS-PC 15.1C & Greater (DORINFOx.DEF & MESSAGES) In this mode, GMon will try to read the DORINFOx.DEF, and the node records of the main message base file. When you specify that you are running GMon under this mode, you will be shown option 'C' in the main GMEdit screen. This command allows you to specify the _name_ of the main message base. Commonly this file is called either MESSAGES, or MAINM.DEF. GMon will also ask what the BBS directory is. This is where it expects to find both the DORINFOx.DEF and main message file. If this is not the case on your system, not to worry. If your main message file, and your DORINFOx.DEF file are in separate directories, you will need to temporarily copy your DORINFOx.DEF file to the same directory as your main message base. Then specify that directory as the BBS directory. After you GMon is done running you could then delete that temporary copy of the DORINFOx.DEF file, it is up to you. Why does GMon read the node records? Well, it doesn't _have_ to, but I try to create complete file conversions, and the more info I have the better. The DORINFOx.DEF file just doesn't contain a whole lot more than the necessary info. The node records hold a lot more info on the current user. If you don't want GMon read your main message file node records, then you can do one of two things. Don't put in any filename for the main message file (in GMEdit), or switch to QBBS mode. The former is preferable. Since GMon both, can read _and_ write a DORINFOx.DEF and MESSAGES file (just the node records) it is imperative that you do not put any door programs in your BBS directory. Well.. okay.. it isn't imperative, but don't do it, just to be on the safe side. RBBS-PC was the first program to create a DORINFOx.DEF file for doors. The format of the RBBS style DORINFOx.DEF file is the one I consider the standard (even though it is a bit flaky in some spots) GMon will also read and write what I call an 'Odd DorInfo File', in other words ones which don't exactly follow the RBBS standard. I'll explain more about that below in the special DORINFO section. PCBOARD 12.x & 14.x (PCBOARD.SYS) In this mode GMon will read a PCBOARD.SYS file in the BBS directory you specify. If you have a multi node system, then you probably will have each nodes PCBOARD.SYS in different directories. If this is the case, then specify, on the command line, the directory in which to find this nodes copy of PCBOARD.SYS. Use the '/Fxxxx' command for this (see above in the command line switch section) The '/F' switch overrides the default BBS directory you enter inside the GMon editor. If you find it easier to rename your PCBOARD.SYS files for each node (PCBOARD1.SYS.. PCBOARD2.SYS.. etc.) and put them all in the same directory (like some doors require) you can do this with GMon too. Tell GMon that you are running PCB 12 or 14 (depending on your version of PCBoard) _and_ turn on the 'BBS info file has node#' switch. GMon will then look for Page 11 a PCBOARDx.SYS (where 'x' is the node number on the cmd line) This is not standard operation, but will work just fine. GMon will read only the PCBOARD.SYS file in PCB mode. It will not read your PCBOARD.DAT, or user file. WILDCAT! 2.x (CALLINFO.BBS) In this mode GMon will read the CALLINFO.BBS file in the directory you specify in the GMon editor. If you have more than one directory in which GMon may need to find the CALLINFO file, then you can specify each directory on the command line instead using the '/Fxxxx' command line parameter. GAP & WILDCAT! 3.x (DOOR.SYS) In this mode GMon will read the DOOR.SYS file in the directory you specify in the GMon editor. If you have more directory in which GMon may need to find the DOOR.SYS file (as in a multi-node set-up), then you can specify each directory on the command line instead using the '/Fxxxx' command line parameter. RA 1.x (EXITINFO.BBS & DORINFOx.DEF) In RA mode, GMon will try to read both the DORINFO1.DEF and EXITINFO.BBS files in the BBS directory you specify in the GMon editor. If you are running multiple nodes, then you will have multiple directories in which to find these two files (according to node). If this is the case, then you will need to use the '/Fxxxx' command line parameter to tell GMon where to find those two files for that node. Both of those files should be in the same directory. OPUS 1.1x (LASTUSxx.DAT) Gmon will try to read the LASTUSxx.DAT file in the directory you specify in the GMon editor in this mode. 'xx' is the node number (in HEX format) and GMon will put in the node number according to the node number you specify (in DECIMAL) on the command line. For instance, if you had a 10 node system and this copy of GMon was running on node 10, then you would tell GMon the node was node 10 like this: 'GMON /N10' GMon would then look for the following filename: 'LASTUS0A.DAT' I haven't been told whether or not the LASTUSER file has changed with OPUS 1.7.. so I am going to take a wild guess and say it hasn't changed. Let me know if I made the wrong assumption. SPITFIRE (SFDOORS.DAT) GMon will look for an SFDOORS.DAT file in the BBS directory you specified. If you have multiple SFDOORS.DAT files, then use the '/Fxxxx' command line parameter. WWIV (CHAIN.TXT) In this mode, GMon will look for a CHAIN.TXT file in the BBS directory you specify in the GMon editor. If you have multiple CHAIN.TXT files in multiple directories, then you can override the default BBS directory with the '/Fxxxx' command. Page 12 GTPOWERCOMM (GTUSER.BBS) [Not Implemented.. yet] PHOENIX (INFO.BBS) [Not Implemented.. yet] QBBS (DORINFOx.DEF) In this mode GMon will look for information in the DORINFOx.DEF file. The DORINFO file is searched for in the path that you specified in the GMon editor. If you have more than one path in which to find those DORINFO files, then you will need to use the '/Fxxxx' command to tell GMon where to locate the DORINFO file it needs. SPECIAL CASE (DORINFO1.DEF) I threw this one in there for doors which can only read a DORINFO1.DEF (it appears that this is so, even though that '1' should be whatever the node is.) GMon can also read from just a DORINFO1.DEF (no matter what the node number is) if your BBS program creates a DORINFO1.DEF by that filename only. And this mode _requires_ that! I don't know if anyone would have any use for that, but it's in there anyway. In this mode GMon will read the DORINFO1.DEF file no matter what node number you specify. So be wary when using this mode. OTHER BBS INTERFACE INFO If your BBS info filename normally does not have a node number in it, but on your BBS you rename those files to reflect the node, GMon can operate in that fashion. If you turn on the 'BBS Info File Name Has Node #' switch GMon will look for a filename with a node number in files that usually don't contain one. ie. If you tell GMon you are running under Wildcat! 2.x, GMon will normally look for CALLINFO.BBS.. but if you turn on the above switch GMon will look for CALLINFx.BBS where 'x' is the node number. The following files, which normally don't have node numbers in the filename, will be converted like so (with the special switch turned on): PCBOARD.SYS -> PCBOARDx.SYS CALLINFO.BBS -> CALLINFx.BBS DOOR.SYS -> DOORx.SYS EXITINFO.BBS -> EXITINFx.BBS SFDOORS.DAT -> SFDOORSx.DAT GTUSER.BBS -> GTUSERx.BBS INFO.BBS -> INFOx.BBS 'x' is the node number. Once again, I don't know if there is much use for this option, but it fit into the code automatically.. so I wanted to document it! Thats it for BBS's which GMon can operate with. Page 13 HOW TO INTERFACE YOUR UNSUPPORTED BBS TO GMON I suggest two different methods of interfacing to GMON. Both are simple text files. One is more complex than the other, but contains more complete information on the user. First I'll cover the DORINFOx.DEF standard, then the DOOR.SYS standard. The DORINFOx.DEF file. The 'x' in the filename is always the node number. So for a single node BBS, the file would be named: DORINFO1.DEF For multi-node BBS programs, the file would be named like so: DORINFO1.DEF for node 1. DORINFO2.DEF for node 2 etc. This file is an RBBS-PC standardized file, and there are only 36 node numbers supported. the 36 nodes are numbered like so: 1234567890ABCDEFGHIJKLMNOPQRSTUVWXYZ So, node 10's DORINFO file would be DORINFO0.DEF, node 36's would be DORINFOZ.DEF GMon accepts a command line parameter to specify the current node number. If your command line read GMON /N8 GMON would look for DORINFO8.DEF. Get the idea? Now we move onto the format of the file itself. The format of the DORINFO file is as follows: BBS Name SysOps First Name SysOps Last Name Com Port BPS Rate and Parity RBBS Network type Current Users First Name Current Users Last Name Current Users City/State Graphics Security Level Minutes Left in Session FOSSIL Driver present Page 14 All lines are in capital letters. I'll give you two examples of what the file typically look like: Example 1 Example 2 THE ABANDONED LAND THE ABANDONED LAND JOHN JOHN MORRIS MORRIS COM2 COM0 2400 BAUD,E,7,1 9600 BAUD,N,8,1 0 3 JOE SYSOP BBS RENO, NV RENO, NV 0 2 5 20 57 119 0 -1 In example 1, the remote user is at 2400 BPS, even parity, with 7 data bits. No graphics (regular text), and RBBS is not using a FOSSIL driver. In example 2, the local user is the SysOp. ANSI color is on, and a FOSSIL driver is present. There are several 'quirks' in the DORINFO standard. They are as follows. 1: A local user is online when the com port is set to COM0 Also, GMon will recognize a BPS rate of '0' as a local user, but this is not the standard method. 2: When the SysOp is using the game, the 'Current Users First Name' is "SYSOP" (without the quotes), and 'Current Users Last Name' is "" a null string. (the only chars found on that line are a carriage return/linefeed combo) Also acceptible is setting the Users first and last name to match the SysOps first and last name exactly, but this also in not standard. 3: Graphics are off when a 0 is found in the graphics field. RBBS-PC uses a 1 when the user can accept IBM high bit chars, and 2 for ANSI color. When in RBBS mode, a 2 is needed to turn on ANSI color in GMon. When in QBBS mode, a 1 in the graphics field will turn on ANSI color. This difference is due to different BBS's doing slightly different tweakage to the DORINFO standard. GMon tries its best to cope with these differences. 4: Note the BPS Rate and Parity field. Whatever the BPS Rate and Parity is, it must match the format shown! Here are some more examples: 300 BAUD,N,8,1 1200 BAUD,E,7,1 19200 BAUD,N,8,1 GMon will parse out the " BAUD" part of the string, and go from there. 5: GMon doesn't use all the fields in the DORINFO file. Here are the fields GMon DOES NOT use: BBS Name, SysOps first or Last name, Network type, and FOSSIL driver. These lines are not used, but must still be present in one form or another. 6: Everything in the file should be in CAPS. Page 15 7: The space seen in front of the numbers is due to the way BASIC writes numbers to disk. They may or may not be present. Doesn't matter really. This file is small and simple, and I like it. The only real drawback is the limited number of nodes, and lack of complete information on the system it is running under. But it does what it set out to do, run doors, and it does that just fine. The DOOR.SYS file. The DOOR.SYS file is also a text file but contains more information about the system it is running on, and more information on the user too. The DOOR.SYS file always keeps the same name. It is just found in different subdirectories for different nodes. So when you run GMon, you need to tell it where to find the DOOR.SYS file for that node. You use the '/Fxxxx' command to do it. GMon uses the 52 line version of this file, which is a super-set of the original DOOR.SYS file. If this is an inconvenience, then I'll make a mode which will accept the old style DOOR.SYS file also. We'll drop to the next page to explore the file format. Page 16 The format of the file is as follows: (with some notes on exact format) Com Port (COM1: for com port 1. COM0: is used for local user) BPS Rate (Speed user called in at 300-38400) Parity (7 or 8) Node Number (1 to 99) DTE Rate (actual com port speed to use) Display On/Off (Y=On N=Off) Printer On/Off (Y=On N=Off) Page Bell On/Off (Y=On N=Off) Caller Alarm On/Off (Y=On N=Off) Full User Name Users City/State Home Phone Data Phone Password Security Level Total Times On Last Date Called Seconds Remaining This Call Minutes Remaining This Call Graphics Mode (GR = Graphics, NG = No Graphics, 7E = E,7,1) Page Length Xpert Mode (Y = Expert, N = Novice) Conferences Registered In Conference In When Opened Door Expiration Date (mm/dd/yy) User File Record Number Default Xfer Protocol (C, X, Y, Z, Etc.) Total Uploads Total Downloads Daily K-Bytes Downloaded Daily Maximum K-Bytes To Download Callers Birthday (mm/dd/yy) Path to User File Path to GEN Directory (?) SysOps Name (as on BBS) SysOps Alias Event Time (hh:mm) Error Correcting Modem (Y or N) ANSI Supported By User but Not Being Used (Y or N) Use File Locking (Y or N) Default Color (IBM type color code.. 1 to 15) Time Credits In Minutes (this can be positive or negative) Last New Files Scan Date (mm/dd/yy) Time Of This Call (hh:mm) Time Of Last Call (hh:mm) Maximum Daily Files Available Files Downloaded Today Total K-Bytes Uploaded Total K-Bytes Downloaded Comment On User Doors Opened Messages Left By User As you can see, this file has a LOT of information in it. GMon will not use even a half of that info. But the DOOR.SYS file is intended as a standard for all BBS's to use. And hopefully more of them will use it in the future. On the next page, I'll give you an example of what a DOOR.SYS file might look like. Page 17 On this page I'll give you an idea of what a DOOR.SYS file might look like. COM2: 9600 8 1 19200 Y N N N Joe Bbs Reno, NV 702 746-1364 702 746-1365 BAGEL 10 125 01/01/95 2701 45 GR 24 Y 1,2,3,4 3 01/01/96 54 Z 0 15 100 1024 12/31/60 C:\BBS C:\GEN John Morris E-Male 02:00 Y N Y 12 -5 01/01/95 03:47 05:12 20 1 0 2314 Likes To Play TW2 176 18 Just another ordinary text file. Most of the information contained in the file makes life easier for file transfer doors to work. (lots of file xfer info contained in the file) Page 18 Some notes on the DOOR.SYS file. 1. Like the DORINFO file, a local user is specified by saying COM0: (note the different format of the com port string. The DORINFO file uses COM0, while the DOOR.SYS file uses COM0: a colon is added.) 2. Use the DTE rate line to give the speed to open the port at. There is a difference between the BPS rate and the DTE rate. Say your BBS modem is locked at 19200 at all times. Some guy calls in at 2400. The BPS rate would be 2400, but the DTE rate would be 19200. 3. GMon will use the 'seconds left in session' field to get the time remaining. 4. GMon will use field 4 to get the node number instead of you having to specify it on the command line. That is pretty much the extent of it. When making the file make sure you fill in all the info, even if it is faked! Every line has to be there so GMon won't get out of sync with the contents of the file. GETTING STARTED WITH GMON GMon is simple to set-up. Simply unZIP the contents of the GMon ZIP file into its own directory. Then run GMon with the command: INSTALL This batch file will provide you with a bit of info, then run GMon. GMon will then create GMON.DEF, USERS.GMN, and PROGS.GMN. You are then brought into the GMon editor automatically. At this point you want to change the GMon defaults to match your system. You can edit these at any time, but you might as well do it the first time you run it. Add in some games using the program editor.. and.. After you have used the GMon editor, you can exit out, and create the batch file which will run GMon. See the batch file section (above) on how to do that. Make GMon available to your users on your BBS, and away you go! GMON EDITOR PROGRAM The GMon editor is part of the main GMon program. In local mode, you use the 'E' command to enter the editor. Once you have entered the editor you will see a screen full of options you can edit. I'll go thru these options one by one. A - GMon Directory This is set automatically by GMon when it is first run. If you need to change this from the default, then do so here. B - BBS Directory This is the directory in which GMon expects to find the BBS info files To read. If you have more than one directory containing the BBS info files, then you can override this default BBS directory by using the '/Fxxxx' command line parameter. Page 19 C - RBBS Message File Name This option is used only to specify the _name_ of the main RBBS message base (usually MESSAGES, or MAINM.DEF). GMon will use this name when in reading a messages file in RBBS-PC mode, and will also use this name when writing a pseudo-messages file when the in 'RBBS' mode for a door. D - Bulletin Menu Name This is the name of the menu shown to the user when they choose the B)ulletin command. The default name is BLT. All GMon bulletins must reside in the GMON directory at this point in time. E - Bulletin Prefix Name GMon bulletins are numbered. Here you give the prefix of the filename onto which GMon will append the numbers. The default is BLT. If the user chose to read bulletin 1, GMon would search for the filename 'BLT1' GMon will also accept separate text and color versions of each bulletin. See the GMon text file section for more info on that. F - Last Maintenance Run * Currently not editable.. coming soon.. This is the date and time that the maintenance program last ran. The maintenance program serves to clean up the USERS.GMN file, so it doesn't grow overly large. G - Time Between Uses Of GMon * Currently not editable.. coming soon.. If you don't want users entering GMon, then going back, and then immediately rerunning GMon, then you can tell GMon not to let that user back on until a specified time period has occured. In other words, the users will have to wait the period you specify before they can re-enter GMon. H - Maximum Days Of Inactivity This is period of time GMon will keep an inactive user in the user file. After this date, the user will be deleted from the USERS.GMN file. I - Local Foreground Color * Not currently used. This is the color of the foreground on the local SysOp screen. Not used when the user is in ANSI mode. J - Local Background Color * Not currently used This is the color of the background on the local SysOp screen. Not used when the user is in ANSI mode. Page 20 K - Bulletin Path This is the path where GMon can find the bulletins it is to display. All bulletins should be located here. L - Keyboard Time-Out Period This is the time in which GMon will wait for user input. Past this time period, and the user is automatically logged off. M - Maximum Number Of Nodes Set this to the maximum number of nodes in your system. N - SysOp Security Level This is the security level used by the SysOp. Valid numbers are -32767 to 32767 (standard integer range). Default is level 10. SysOp commands are also set to have a default level of 10.. Don't forget to change these if your security level is different. O - SysOps First Name This your first name. P - SysOps Last Name This is your last name. (if any) Q - System Name This is the name of your BBS. R - BBS Type This is the type of BBS program that GMon is running with. See the 'BBS PROGRAMS GMON RUNS WITH' section for more info. When editing this, you will be shown a complete list of BBS types GMon will run with. Pick one from the list. S - Swap Directory When GMon runs a door program it will 'Swap' itself out of memory to provide the maximum amount of memory to the door. If GMon can't locate any EMS, or XMS memory to use for the swap, then it will swap itself to disk. You can specify a ram disk here, if you have one, to make the swap just as fast as one to EMS, or XMS. The default swap dir is the current GMon directory. T - Comm Input Buffer (not used when a FOSSIL driver is present) This is the size of the communications port input buffer in bytes. The default is 256, and you should be able to leave it set to this. U - Comm Output Buffer (not used when a FOSSIL driver is present) This is the size of the communications port output buffer in bytes. The default is 256, but valid sizes are 128 to 4096. 256 to 1024 are good sizes. Page 21 V - Program Files By Node? The door programs GMon has access to are kept in a file called PROGS.GMN. This file is normally used by all nodes, but if you want separate PROGS.GMN files for each node, then turn this option on. The file that GMon would then look for is PROGxx.GMN where 'xx' is the node in HEX format. Each node would then have to have its own PROGxx.GMN file. If you wish to have a special PROGS.GMN file, lets say for a certain node, you can override the default PROGS.GMN filename by using the '/Pxxxx' command, where 'xxxx' is the name of the PROGS.GMN file you wish to use. See command line section for more info. W - Prompt has commands? GMon has one main prompt. You can either have GMon show the valid command letters in the prompt, or leave them out. The prompts look like so: <with> [30 min. left] GMON Command <A,B,..,X>? <without> [30 min. left] GMON Command? If the user has insufficient security for a certain command, it is not included in the prompt. They are shown only commands they can use. X - Programs By Category? On systems with a LOT of doors, it is easier for a user to list games by category. When they want a list of games, they are asked which category to use, then they are shown the games that are in that category only. You create valid category names using the '!' command (see below) Up to 20 are allowed, and it's your job to keep track of the categories. You will have to edit each game to tell GMon which category it should be placed in. Y - Allow User Aliases? This will allow a user to use an alias when playing the games. They will be asked for their alias when they first log on to GMon. They cannot change it after that. Let me know if you think they should be able to change their alias. Z - Keep a Log? Should GMon keep a log of what is occuring? If so, it will log info to GMON.LOG 1 - Network Mode? GMon requires DOS 3.1 (or greater) to run, and will almost always open a file in shared mode even with network mode turned off! Network mode tells GMon to lock records in those files when it makes changes. GMon never keeps file open for more than a split second anyway, so clashes rarely, if ever, take place. Page 22 2 - Debug Mode? This will tell GMon to show a little extra info on the local SysOp screen. If there is a question as to whether GMon is reading the right files, or getting the users name or BPS rate correct, you can turn this on to check things out. 3 - Use .ASC & .ANS for text files? GMon can treat text/color text files in 4 different manners! If your BBS program normally uses .ASC to indicate a plain text file, and .ANS to indicate an ANSI text file, then turn this switch on to make GMon act in a similar manner to your BBS program. This is also how TheDraw names its ASCII, and ANSI files. Lets say a user wanted to read bulletin 1.. In this mode, a plain text bulletin 1 would be called: BLT1.ASC A color bulletin 1 would be called BLT1.ANS See the text file section for more info. 4 - Max # of Bulletins This is the maximum number of bulletins GMon will look for, or allow. You can actually have 'fewer' than this number of bulletins, but GMon won't recognize bulletins if they are numbered higher than this amount. 5 - Use PCBoard style names for text files. This switch is similar in function to the ASC/ANS switch but enables the PCBoard method of naming text/color files. The letter 'G' is always appended to a filename if it is a color file. So.. Lets say a user wanted to read bulletin 1.. In this mode, a plain text bulletin 1 would be called: BLT1 A color bulletin 1 would be called BLT1G 6 - Log Files By Node? Use this to have GMON.LOG files separatly created for each node. They will have the filename GMONx.LOG (where 'x' is the node number). If you have more than 1 node, and you choose _not_ to have separate log files, the node number will be prepended to each entry. @ - BBS Interface filename has node #? This will make GMon look for a BBS info file with a node number in it when it normally doesn't have a node number. See the 'BBSs GMon runs with' section. # - Smart Text Character This tells GMon which character denotes smart text. Default is '%'. 7 - Edit GMon Command Letters And Security Levels. When you enter this command you will be shown a screen with all the available commands, what letter executes that command, and what security level is needed to execute that command. If you wish to change a command, enter the number of the command, you will be asked which letter should invoke that command. If you type [ENTER] then the letter won't be changed. You will then be asked for the security level needed to use this command. Page 23 Three commands are considered SysOp commands, D)elete log, E)ditor, and L)og viewer. So set these to the security level you deem appropriate. 8 - Edit GMon Time Limits Here you will be shown a screen with security levels, and their associated time limits. You can set a session time limit, a daily time limit, and you can set a certain when the user can use GMon. If they call out side of that time period, they aren't allowed in! You can also associate a 'Name' with a security level. This is for BBS programs which use security names instead of numbers. GMon thinks in numbers, so it will convert Names to Numbers, and vice versa. (Names of up to 20 chars are allowed. Case is important) There are 20 time limits allowed. If your system has more than 20 valid time limits, not to worry! read on. You should enter time limits in numerical order according to security level. On my system I have security levels ranging from 1 to 20, but I only use a few of those 20 security levels. My time limit screen looks like so: #. SecLvl Session Daily Start Finish Name 1. 1 30 45 06:00 18:00 SCREWOFF 2. 5 30 60 00:00 23:59 NORMAL 3. 6 30 75 00:00 23:59 GUESTSYSOP 4. 7 45 90 00:00 23:59 COOLDUDE 5. 8 45 90 00:00 23:59 REALLYCOOL 6. 9 45 90 00:00 23:59 DONATOR1 7. 10 45 90 00:00 23:59 DONATOR2 8. 15 45 90 00:00 23:59 ASSTSYSOP 9. 20 60 120 00:00 23:59 SYSOP 10. 32767 30 60 00:00 23:59 11. 32767 30 60 00:00 23:59 . . (all these in here are the same) . 20. 32767 30 60 00:00 23:59 GMon will read thru this list BACKWARDS from 20 until it finds a security level 'less than or equal' to the current users security level. If you're using Security 'Names' there must be an exact match. So if it was a level 20 user, it would search 20 thru 10 without finding a match. Number 9 is a 'equal' to the user, so the time limits shown would be used: 60 minutes per session, 120 per day. And they are allowed on basically all day. What happens if the user is a level 12? It isn't listed! Well GMon would search thru the list 20 thru 8 without finding a match, but it would see that entry 7 fits the 'less than or equal to' rule, and use the level 10 limits as the default. 9 - Edit Programs That GMon Can Execute Here is where you tell GMon which programs it can execute, and what 'flavor' to make 'em. You will be asked which program to edit, 'A' to add a pgm, 'D' to delete a pgm, 'L' to list all current programs, 'R' to rebuild the program file (deletes empty records, you rarely need to use this!). Page 24 If you choose A)dd, then GMon will look for an empty record, or add on a new record, and make a dummy filename for the program. You will then be asked to edit that program. You will need to change the dummy filename to the one you actually want. When you just enter the game number, you will be shown a screen with same options as when you add a game. Here are those options: A - Program Name This is the name of the program the user will see. It is also the name of the COM, EXE, or BAT file that GMon will execute. If that name is 'TW2' then GMon will expect to find either 'TW2.COM', 'TW2.EXE', or 'TW2.BAT' to run the game! It will look for a batch file only if you turn the 'use batch file command' on. The 'COM' or 'EXE' file is searched for in the 'Program Directory' whereas the 'BAT' file is searched for in the current GMon directory. ** That is important to remember! ** B - Program Directory This is where the program is located. This should be full drive and path, with no trailing backslash. This can be on a different drive than GMon! No problems there. GMon will changes drives _and_ directories when it executes a COM or EXE file. This is also the directory where GMon will write the info files that that program needs. C - Program Command Line You can specify the _exact_ command line you need to use to run this program, up to 128 chars long. GMon will not use this command line unless you use the 'Use Cmd Line' option. (below) If you tell GMon to 'Use Cmd Line' but you don't have a command line specified here, then GMon will use the command line used to invoke GMon as the command line for the program. The following Macros are valid in Command Lines _and_ Environments. The 2 char combinations are converted to information based on the current user & BBS info. (Default macro char is '%' you can change it) %a = Full Alias Name %L = Local Mode 1=yes, 0=no %b = Modem to Modem BPS Rate %n = Full User Name %B = PC to Modem BPS Rate (DTE) %N = Node Number %c = Com Port Number %o = SysOps First Name %C = Com Port as 'COM#' %O = SysOps Last Name %d = Data Bits (7 or 8) %p = Parity (N or E) %f = Users First Name %P = Pause Screen %g = GMon Directory %s = Security Level %G = ANSI Graphics 1=yes, 0=no %S = System (BBS) Name %h = (GMON/2) Comm Port Handle %t = Seconds Left in Session %l = User Last Name %T = Minutes Left in Session For instance, if you were running a door that only need the node number on the command line, you would set the command line to: %N If it was on node 2, then the '%N' would be converted to '2' before being sent to the program as the command line. As you can see, you can put a whole lot more on the command line than just the node number! This will help you run doors which expect complete user info on the command line. These macros can be put right along side regular text also. Page 25 D - Program Environment You can specify an separate environment for each program! Some doors need an environment variable to control how it works. For instance, DoorPatch doors used to require that you put the statement "SET DOORPCH=PCB" in your environment. Well instead of doing that and using up some of your valuable environment space, you can tell GMon the environment is 'DOORPCH=PCB' and do it that way. Much simpler. Most programs will NOT need their own environment. This is just for those rare instances when a door will need some extra info. If you don't specify an environment, then the program recieves a copy of the 'parent' environment (the one GMon got..) The Macros shown above will work equally well in the environment! E - Program Security This is the security level required to run this program. If the user doesn't have a security level high enough then the program will not even be loaded into memory, and therefore they can use it. GMon, in fact, wouldn't even know of the programs existance, so the user could not even hack away and get into that program. F - Program Type This is a similar list as to what you read in the 'BBS PROGRAMS GMON WILL RUN WITH' section. This controls which interface file(s) GMon will create for that door. All interface files are created in the program directory you specified (with no exceptions). RBBS-PC 15.1C & Greater (DORINFOx.DEF & MESSAGES) In this mode GMon will created an RBBS-PC standard DORINFOx.DEF file, and a 'pseudo' MESSAGES file with just a checkpoint, and node records. The MESSAGES file name is the one you specified in the main GMon editor screen. If no filename is given for the main message file, then this file isn't written. NOTE: I consider the RBBS-PC DORINFOx.DEF file the standard for DORINFO files! The DORINFOx.DEF file created in the QBBS mode is slightly different. The differences are: In RBBS mode the 'User First & Last Name' when a SysOp is on-line is 'SYSOP' & '' (null) respectively. In QBBS mode, the first and last name are the same as the SysOps first and last name when the SysOp is on. In RBBS mode a local user is specified by 'COM0' on the com port line. RBBS sets the BPS rate to 9600 for a local user. In QBBS mode a local user has a com port of 'COM0' and a BPS rate of 0. In RBBS mode a '2' is required in the graphics field to turn indicate ANSI mode. In QBBS a 1 means ANSI mode. I also don't think QBBS mode has a FOSSIL driver indication line. Those are the main ones. If you encounter a door which doesn't appear to work correctly with an RBBS DORINFO file, then try the QBBS style DORINFO file. Page 26 I hate it when standards get hashed around like that! <g> PCBoard 12.1 (PCBOARD.SYS, PCBOARD.DAT, USERS) PCBoard 14.x (PCBOARD.SYS, PCBOARD.DAT, USERS) In PCBoard 12.x mode, a PCBOARD.SYS (12.1 format), PCBOARD.DAT, and USERS file is created in the program directory. Choose option 'Q' to write a PCBOARDx.SYS, PCBOARDx.DAT, and USERS file. In PCBoard 14.x mode, a PCBOARD.SYS (14.x format), PCBOARD.DAT, and USERS file is created in the program directory. Choose option 'Q' to write a PCBOARDx.SYS, PCBOARDx.DAT, and USERS file. Wildcat! 2.x (CALLINFO.BBS) In this mode a CALLINFO.BBS file is created in the program directory. Choose option 'Q' to make a CALLINFx.BBS file. GAP & Wildcat! 3.x (DOOR.SYS) A DOOR.SYS file is created in the program directory. This DOOR.SYS file follows the 52 line format. If this causes a problem, I'll stick in a new mode which will created te older format DOOR.SYS file. RA 1.x (DORINFO1.DEF & EXITINFO.BBS) In this mode a DORINFO1.DEF _and_ an EXITINFO.BBS file are created in the program directory. Spitfire (SFDOORS.DAT) In this mode an SFDOORS.DAT is created in the program directory. if you choose option 'Q', the filename will be 'SFDOORSx.DAT' WWIV (CHAIN.TXT) In this mode a CHAIN.TXT file is created in the program directory. If you choose option 'Q', the filename will be 'CHAINx.TXT' Fast Fingers Door (OPENDOOR.SYS) An OPENDOOR.SYS file will be created in the program directory, enabling you to run Fast Fingers doors without a conversion program (other than GMon) MG Generic (USERINFO.TXT) A USERINFO.TXT file will be created in the program directory. This will allow doors like the ol' Planet Busters to work. QBBS (DORINFOx.DEF) Special Case (DORINFO1.DEF) & (DORINFOx.DEF - 3=ANSI) This mode will create a QBBS 'style' DORINFOx.DEF file in the program directory. See RBBS mode for details on the differences in DORINFO files. The 'Special Case' mode is used for doors which accept only 'DORINFO1.DEF' (ie. it doesn't expect a node number, just a '1') The 2nd special case puts a 3 in the graphics mode portion of the file to indicate ANSI mode. Page 27 SRDoors (DOORFILE.SR) Creates a DOORFILE.SR file in the program directory. Used for games like SRE, AC6, or PC. Eliminates the need to run SRDOOR.EXE before the game executes. G - Program Category If you told GMon to list games by category, then you need to specify the category number here. H - Program Description Here you have 38 characters to describe the program. I - Use Command Line? If you turn this option on, then GMon will use the command line specified above as the command line for the program. If you did NOT specify a command line above, then the command line supplied to GMon itself is used instead. If this switch is off, then no command line is supplied to the program! J - Use Environment? If you turn this option on, then GMon will use the above environment as the programs environment. If this switch is off, or there is no environment listed above, the program is given a duplicate of GMons environment. K - Use Batch File? GMon 4.0 eliminates the need for batch files. Well, in most cases, not all. If you turn this option on, GMon will search the current GMon directory for the program batch file, and execute it instead of changing drives & directories and running the COM and EXE files directly. This is good for times when you need to do some extra things in the batch file like copying files over, etc. L - ANSI Mode A lot of programs nowadays require that a user have ANSI capabilities. Not exactly ANSI color, but also ANSI cursor movements. You can tell GMon 3 things about this program. 1. Let the user use this door, even if they don't have ANSI mode turned on. This is the default. 2. Don't let the user use this door, unless they have ANSI mode turned on in GMon. 3. Let the user use the door, even though they have ANSI turned off, and the door probably requires ANSI mode. Just give them a warning before the door is executed. M - Program Times Used This is the number of times a program has been used. Page 28 N - Program Can Only Have One User? Some doors are not made to work in a network environment, and recommend that you keep more than one user from using the game at one time. If you turn this switch on, only one user will be able to use the game at one time. O - Null Cmd Line In Local Mode? I put this in for Doorware which appear to run locally if there is _no_ command line, and remotely if there is a command line. Even if you specify 'use a cmd line' the cmd line in local mode is null ("") with this switch turned on. P - Is program currently being in use? If someone on another node is using the program, this is 'ON'.. Q - Put a node # in the filename? If you wish to change the default filename which contains no no node number in the filename to one which has the node number then turn this switch on. This affects PCBOARD.SYS, CALLINFO.BBS, DOOR.SYS, EXITINFO.BBS, SFDOORS.DAT, CHAIN.TXT. R - Doorware mode? If this is turned on, GMon will write a TIMEOFFx.DOR when opening the door, and reads in POINTSx.DOR after the program exits. This allows GMon to get the points earned/lost in the door. S - Disallow alias in door? Aliases are not appropriate for some doors. If your turn this switch on, then their real name is used for the door instead of their alias (if you have chosen to allow aliases) You will also be shown that last date & time the program was last used. 0 - Edit Users You will be asked which user to edit, or you can enter a search string. Once you have the user you wish to edit, you will see the user edit screen. A - User Name This is the name of the user according to the BBS info file, and is the name GMon will look for when searching for the user. B - Alias Name If you have the Alias option turned on, this will contain the alias the user picked. No two users can have the same alias.. This is for everyones protection. C - Seconds Used Today GMon keeps track of seconds used to keep a clear idea as to how much time a user has used. It is very easy for a user to enter and exit GMon in just a few seconds. Page 29 D - Last Date & Time On This is the last date and time a user last logged on, and is currently not editable. E - Expert mode This determines whether or not the menus are displayed. F - ANSI mode This tells whether or not the user has ANSI mode turned on or off. ! - Edit Categories You can have up to 20 categories. Use them in order, ie. don't have any gaps. It is up to you to keep track of what the name and number of each category is. You can then place games in these categories according to number using the program editor. GMON TEXT FILES GMon offers four (4) different ways to differentiate between plain text and ANSI color text files. Two of these methods are defaults. Two defaults? Yup.. Two defaults. The standard method of creating plain text and color text files is very similar to the RBBS method of naming the files different for text & color. The text version of the file is just the plain filename. For all of the following examples I'll use the main GMon menu file called GMENU. The plain text version is called GMENU. The color version has a C appended to the filename, or GMENUC. If the user is in color mode, and GMon couldn't find GMENUC, it will display GMENU to the user. That is one default method GMon uses to differentiate text & color menus. The other default method is to NOT create a GMENUC file, but place color macro commands in the text file (GMENU) itself. GMon, as above, will look for GMENUC, not find it, and display GMENU, into which you put the color macros. But what if the user isn't using ANSI and I put color macros into GMENU which is supposed to be plain text? Good question. GMon will not put in the color macros into the file if the user isn't in ANSI mode! It will strip the color macros out! So _one_ text file can act like a plain text and a ANSI color file! This method will only work for relatively simple text files, but it is an option. That is the second 'default'. To see what the color macros look like, check out the next section 'MACROS' There are two optional methods for differentiating text & color text files, and they can be chosen in the GMon editor. The first method is called 'Use ASC & ANS for files' In this method the GMENU file will be named like so: GMENU.ASC (plain text.. or ASCII) GMENU.ANS (ANSI color) This method is similar to ones used by some BBS programs, and is also the default file naming procedure used by TheDraw. Page 30 The other option method is one similar to the way PCBoard names its text files. Instead of appending a 'C' onto the end of the filename, a 'G' is appended. So: GMENU (plain text) GMENUG (ANSI color) These options are included in GMon to make it easier for you to differentiate between text & color files. ie. make it similar to the method you are already using! Things to remember. If the color version of the file can't be found, then the plain text version is shown to the user. If that one can't be found then no file is displayed to the user. Macros can be put into any text file, color or plain text. Color macros are never inserted into a file if the user is in plain text mode. GMON MACRO COMMANDS The default character which denotes a macro is the percent '%' sign. You can change this default in the main editor to any char that you wish.. make sure it is a character which isn't used often. For the examples I will use the default macro character '%'. These macros are basically the same ones you saw in the program editor! (Its actually the same routine!) The following macros are converted as shown: %a = Full Alias Name %L = Local Mode 1=yes, 0=no %b = Modem to Modem BPS Rate %n = Full User Name %B = PC to Modem BPS Rate (DTE) %N = Node Number %c = Com Port Number %o = SysOps First Name %C = Com Port as 'COM#' %O = SysOps Last Name %d = Data Bits (7 or 8) %p = Parity (N or E) %f = Users First Name %P = Pause Screen %g = GMon Directory %s = Security Level %G = ANSI Graphics 1=yes, 0=no %S = System (BBS) Name %h = (GMON/2) Comm Port Handle %t = Seconds Left in Session %l = User Last Name %T = Minutes Left in Session The color macros are for foreground colors only: %1 = Bright Red %5 = Bright Magenta %2 = Bright Green %6 = Bright Cyan %3 = Bright Yellow %7 = Bright White %4 = Bright Blue You can use these macros in the text files you create for GMon. For instance lets say 'Joe BBS' has logged into GMon, and in one of your text files you have the line: %n, This is the new version of GMon. I hope you like it. This line is changed to: Joe BBS, This is the new version of GMon, I hope you like it. and then it is displayed to the user. That's about it for macros, they are pretty straight forward, and I leave it up to your imagination as to how they are used. Use the 'P'ause screen macro at the beginning of a line. Page 31 UPGRADING TO GMON 5.0 Upgrading from the older versions of GMon (prior to 4.0) may not be a really simple process. All of the file formats have changed, and the basic functionality of GMon has changed. I suggest making a directory for GMon 5.0 and unZIPping the GMon ZIP file into it. Then run INSTALL.BAT and use the editor. Use GMon edit to add in the games, and set the switches. The way programs are run is the biggest change. GMon no longer exists out to a batch file to run an external door. It will execute the file from within GMon, no matter if that command is a COM, EXE, or BAT file! For instance, with GMon 3.x I had my Stellar Quest game set up as an external generic RBBS door. (Type 1 in GMon 3.x) I had a batch file called SQUEST.BAT which GMon exited and executed. This batch file looked like so: ECHO OFF ECHO ┌─────────────────────┐ ECHO │ STELLAR QUEST │ ECHO └─────────────────────┘ D: CD \DOORS\SQUEST SQUEST %NODE% \DOORS\SQUEST RBBS C: CD \RBBS GAMES %NODE% Notice the drive change, and the command line. Under GMon 4.0 I was able to eliminate the batch file! Here is the info for the SQuest program under 4.0: Program Name: SQuest Pgm Directory: D:\DOORS\SQUEST Pgm Cmd Line: %N \DOORS\SQUEST RBBS Pgm Type: RBBS-PC 15.1C & up Use Cmd Line: YES Use Environment: NO Use Batch File: NO ANSI mode: ANSI must be on to run this program Page 32 When GMon 4.0 runs a program it will change drives _and_ directories before it executes an EXE or COM file. It will then run that program with the command line I chose (notice the %N macro to tell the program the node #) When the program exits, GMon changes drives and directories back to the GMon directory, and then shows the command prompt to the user. In other words, GMon does all of the batch file commands shown without ever exiting! So... You will want to set up GMon 4.0 completely from scratch! and then test it out. Then you can change your current batch file that runs GMon 3.x over to run GMon 4.0 and see how it works. GMON FILES GMon uses very few files. CHAMPS.GMN Monthly Doorware points champions GMENU & GMENUC are the main menu files. GMEPLG & GMEPLGC File shown to user when they use the G)oodbye command GMHELP & GMHELPC is the help file shown to the user using 'H' or '?' GMNEWS & GMNEWSC is the file shown to the users when they log into GMon. PROGS.GMN is the file which contains program info. USER.GMN is the GMon user file. Optional files include the BLT (bulletin) files, and CATx & CATDx (category) menus of games. GMON BULLETINS GMon allows you to put all door 'score' bulletins in a directory so the users can view them from GMon! This helps simplify your setup in that you can put all your games bulletins in the GMon area where most of your games are run from! You can specify the directory, and what the bulletin menu, and the bulletin prefix filenames are. The bulletin menu is called 'BLT' by default. It lists the current bulletins you have available and their desciptions. GMon bulletins are numbered. The number of the bulletin comes directly after the 'prefix filename'. The default prefix filename is BLT, so bulletin 1 would be 'BLT1' bulletin 22 would be BLT22. The text and color version work just like you were shown above in the 'text file' section. A color version of bulletin 22 would be BLT22C. If you chose the 'ASC & ANS' option, the text version would be BLT22.ASC, and the color version would be BLT22.ANS. Under PCBoard text mode, the files for bulletin 22 would be BLT22, and BLT22G. You can nest the bulletin files. When the user chooses the bulletin command they are shown the bulletin menu, but it is not shown to them again unless they ask for the menu with the L)ist command. Therefore, your bulletin menu could describe, lets say, 10 other bulletins which match your categories. If you said in your bulletin menu that bulletin 1 was a list of bulletins from your adventure game bulletins, then your bulletin 1 would describe which numbers to type to see those bulletins. All bulletins must have a unique number. This method is sort of a false way of nesting bulletins. Pressing enter Page 33 brings the user back to the GMon menu, not to the previous bulletin menu. If they want a previous bulletin menu, they must specify the number directly or use the L)ist command to get the main bulletin menu shown. PROGRAM MENUS GMon supports a default method of displaying what programs are available, and optionally, you can create your own menus to show what programs are available. The default methods are pretty generic looking, and you can spruce up the display by creating CATx & CATDx program menus. If GMon finds these files, they will be displayed instead of the default method. For instance, the default display for 'programs without descriptions' looks like so: Programs available on The Abandoned Land 1. TW2 2. SQuest 3. Carib 4. King etc.etc. You can make a menu which displays the games like you want it to. In this case you want a CATx file. The CATDx file takes the place of the 'programs with descriptions' display. These files are named according to category, CATx & CATDx where 'x' is the category number. What if you aren't using categories? Then use CAT0, and CATD0. This menu is also displayed when you use categories but only when the user chooses A)ll categories. ie. Category '0' is all categories. If you are using categories, then the category files are named according to the categories you made. Just remember: CATx -- Where 'x' is the category (0=all) and this file has no descriptions. CATDx -- Where 'x' is the category (0=all) this file has descriptions. The text & color file naming conventions work here also. CAT0 is the all category text file, CAT0C is the all category ANSI file. Etc. BEFORE & AFTER TEXT FILES GMon allows you to create text files to be shown to the user before and/or after the program is run. The file shown to the user is called BEFORE, the file afterwards is called AFTER. These files are found in the same directory as the game. These files are shown only if they exist. These files also conform to the GMon text/color text file conventions. For instance, the default color versions of these files would be BEFOREC, and AFTERC THANKS I would like to thank all of the guys who have helped me improve GMon throughout the last 4 1/2 years. Roger Reesor - Who helped me figure out exactly how those original Doorware programs did their thing.. (and boy did they work in wierd ways!) Mike Hammer - Who made some mods to get GMon running on pre-15.1C RBBS's (The versions that didn't make a DORINFO file) Darrin Calcutt - This wacky canuck is a good friend, and supplied some mods to improve the conversion section of GMon. I haven't heard from him in awhile, I hope he is doing okay. Page 34 Vanessa Kimble - Who provided the inspiration to get me off my butt and get GMon 4.0 off the spiral notepad, and into code. Mitchell Anstine - Who ran a hell of a lot of doors under GMon in the early days, and really put it to the test. The whole RBBS-PC Beta Gang.. Don Smith, Mike Davis, Rod Bowman, & all the rest! The Guys who registered earlier versions of GMon. I can't possibly remember all of you. But Thanks! HAVING PROBLEMS WITH GMON?? First of all, don't ever assume that I know about every bug. _Always_ assume I DON'T know about ANY bugs. Its better to inform me of a bug I may know about, than not to report it at all! When you discover a bug, please try and get a capture file which shows the bug in action. As someone anonymous once said: "Gather enough information, and the solution will be obvious" I can't stress the importance of that enough. I also will need to know the release number, the BBS program you're running, and a complete description of the problem. See the next section on how to reach me to report bugs, or incompatabilities. PROGRAM SUPPORT / HOW TO REACH ME I support this program to the best of my ability. There are several different ways of contacting me. Mail: John Morris 1718 Woodhaven Ln. Sparks, NV 89434 Netmail: RBBS-Net 8:919/1 or 2 -or- Fidonet 1:213/760 or 761 BBS: The Abandoned Land (702) 359-1138 (702) 359-0629 Voice: (702) 359-1303 If I'm not at home, and you have a bug report, you can leave a message about the bug on my answering machine. As you may hear on my answering machines message, I don't get a chance to return many phone calls.. maybe 1 in 100.. thats it. I wish I could return more of them, but this program is just a hobby at the moment, and I have lots of other things I need to do. Its mainly a lack of time. I always return mail left to me on my BBS. So if you must have a reply, e-mail me on The Abandoned Land. Page 35 APPENDIX A HOW THE POINTS SYSTEM IN GMON WORKS You can tell GMon that a door will return points to GMon by turning on the Doorware switch in the program editor. When this mode is on, GMon will write a TIMEOFFx.DOR in the program directory (along with the usual BBS interface files) When the door program exits, GMon will read a POINTSx.DOR to determine how many points were won or lost. The TIMEOFF file is named like so: On single node systems the file is called TIMEOFF0.DOR.. If the BBS is multinode, then the 'x' is the node number. On node 1 it would be TIMEOFF1.DOR.. node 3 would be TIMEOFF3.DOR.. etc. The TIMEOFF file is a plain text file with 8 lines. The format is as follows: Time, In Seconds After Midnight, When User Session Limit Ends User Number In GMon (not used by GMon 4.0.. always set to 1) Current User Points Minutes Left In Session (or so GMon 4.0 thinks..) Nulls (-1=TRUE 0=FALSE, GMon 4.0 always sets this to 0) ANSI Graphics Mode (0 = text.. -1 = ANSI) GMon Subdirectory (with trailing backslash) Sound on or off (Y or N) On the next page I'll show you what a typical TIMEOFFx.DOR looks like: A typical TIMEOFFx.DOR looks like: 76134 1 1500 30 0 -1 C:\GMON40\ N Thats about it.. GMon is basically concerned with the POINTS field of the file..(line 3) and for door authors, thats what you should look for. It contains the current number of points that the user has. You can use this in gambling games.. or just about anything. It really adds an incentive to use the doors. When the door exits it should write a POINTSx.DOR file (in its own directory) which will tell GMon how many points the user won or lost. The POINTS file is named like so: On single node systems the file is called POINTS0.DOR.. If the BBS is multinode, then the 'x' is the node number. On node 1 it would be POINTS1.DOR.. node 3 would be POINTS3.DOR.. etc. Page 67 The POINTS file is a text file with 2 lines, like so: Time, In Seconds After Midnight, When This File Was Created Points Won (positive #) or lost (negative #) which might look like: 12365 -512 (user lost 512 points..) GMon ignores the first line, and _adds_ the number in the second line to the users current point total. If the users point total is 'below' zero, then the users point total is set to 0. The users points are saved in a long integer which give possible point totals in the 0 to 2,100,000,000 range.. (give or take a few mill) DOOR GAME AUTHORS! I encourage door authors to use the 'Doorware' mode in their games. This version of GMon should tie things together pretty well, and since GMon 4.0's Doorware mode isn't specific to any BBS type, even PCBoard, or RA, or Wildcat! games could use this system. Just have your program look for a TIMEOFFx.DOR file in your programs directory, and if it is there, have your program create a POINTSx.DOR for GMon to use in return! This points system has been around 5 1/2 (as of this writing) and really encourages use of doors. [END OF GMON.DOC]