≪ View Page

Differences

This shows you the differences between two versions of the page.

Link to this comparison view

Next revision		Previous revision
conference_setup:doors [2024-01-17 16:31] – created stimpyconference_setup:doors [2024-01-25 10:41] (current) – [Using One Batch File For All Nodes] stimpy
Line 18: Line 18:
 If you load PCBSetup, and select a conference to edit you will see the following fields at the bottom of your display: If you load PCBSetup, and select a conference to edit you will see the following fields at the bottom of your display:
  
-                     Menu Listing                     Path/Name List File +| |**Menu Listing**|**Path/Name List File**|     
-     +|**Doors**|C:\PCB\GEN\DOORS|C:\PCB\GEN\DOORS.LST| 
-      Doors       : C:\PCB\GEN\DOORS            : C:\PCB\GEN\DOORS.LST +|**Bulletins**|C:\PCB\GEN\BLT|C:\PCB\GEN\BLT.LST| 
-      Bulletins   : C:\PCB\GEN\BLT              : C:\PCB\GEN\BLT.LST +|**Scripts**|C:\PCB\GEN\SCRIPT|C:\PCB\GEN\SCRIPT.LST| 
-      Scripts     : C:\PCB\GEN\SCRIPT           : C:\PCB\GEN\SCRIPT.LST     +|**Directories**|C:\PCB\GEN\DIR|C:\PCB\GEN\DIR.LST| 
-      Directories : C:\PCB\GEN\DIR              : C:\PCB\GEN\DIR.LST +|**Download Paths (listing only)**| |C:\PCB\GEN\DLPATH.LST|
-      Download Paths (listing only)             : C:\PCB\GEN\DLPATH.LST    +
  
 The two fields that relate to door operation are the following: The two fields that relate to door operation are the following:
  
-                     Menu Listing                     Path/Name List File +| |**Menu Listing**|**Path/Name List File**| 
-     +|**Doors**|C:\PCB\GEN\DOORS|C:\PCB\GEN\DOORS.LST|
-      Doors       : C:\PCB\GEN\DOORS            : C:\PCB\GEN\DOORS.LST +
  
 The following is a brief description of each of the files: The following is a brief description of each of the files:
Line 52: Line 49:
 |**DOOR SYS**|Like the USER SYS field, this field will determine if PCBoard should create a DOOR.SYS file for the door. Again, you should check the door documentation to see if a DOOR.SYS file is required for door operation.  If not, leave this field set to N.| |**DOOR SYS**|Like the USER SYS field, this field will determine if PCBoard should create a DOOR.SYS file for the door. Again, you should check the door documentation to see if a DOOR.SYS file is required for door operation.  If not, leave this field set to N.|
 |**SHELL**|This field has three possible options (Y, N, and S).| |**SHELL**|This field has three possible options (Y, N, and S).|
-||**N** - Do not shell to DOS to execute the door.  This means that PCBoard will unload completely and then load the door. If you  +| |**N** - Do not shell to DOS to execute the door.  This means that PCBoard will unload completely and then load the door. If you use this method then you will have the same amount of memory for the door to execute as you had just before you first loaded PCBoard.| 
-use this method then you will have the same amount of memory for the door to execute as you had just before you first loaded PCBoard.| +| |**S** - If you use this option, PCBoard will shell to DOS, swapping itself to XMS, EMS, or to Disk (whichever is available) and will then execute the door batch file.  Using this method means that will get about 25k of memory less than if you had used N.| 
-||**S** - If you use this option, PCBoard will shell to DOS, swapping itself to XMS, EMS, or to Disk (whichever is available) and will then execute the door batch file.  Using this method means that will get about 25k of memory less than if you had used N.| +| |**Y** - Shell to DOS and then execute the door rather than exiting PCBoard completely to load the door.  This means that you will have less memory available to run the door but it also means that it will be quicker loading and returning from the door. Typically you may have only 100-200k of memory available to the door if you shell to it.|
-||**Y** - Shell to DOS and then execute the door rather than exiting PCBoard completely to load the door.  This means that you will have less memory available to run the door but it also means that it will be quicker loading and returning from the door. Typically you may have only 100-200k of memory available to the door if you shell to it.|+
 |**Path to..**|In this field, enter the path where your door batch file can be found.  For example if the batch file for this door is stored in C:\PCB\, enter C:\PCB\ in this field.| |**Path to..**|In this field, enter the path where your door batch file can be found.  For example if the batch file for this door is stored in C:\PCB\, enter C:\PCB\ in this field.|
  
Line 204: Line 200:
 Now, lets say in the ND.CFG file is the following: Now, lets say in the ND.CFG file is the following:
  
-    C:\PCB\NODE3\PCBOARD.SYS ;location of PCBOARD.SYS +    C:\PCB\NODE3\PCBOARD.SYS    ;location of PCBOARD.SYS 
-    5                        ;number of times game can be played per day +    5                           ;number of times game can be played per day 
-    400                      ;points per win+    400                         ;points per win
  
-If you could use environment variables in other files, the solution would be easy enough, you would replace the C:\PCB\NODE3\PCBOARD.SYS in the ND.CFG file to say %PCBDRIVE%%PCBDIR%\PCBOARD.SYS.  However, you cannot do that because environment  variables cannot  be  read  in  from configuration files.  Therefore, you need another alternative.+If you could use environment variables in other files, the solution would be easy enough, you would replace the C:\PCB\NODE3\PCBOARD.SYS in the ND.CFG file to say %PCBDRIVE% %PCBDIR%\PCBOARD.SYS. However, you cannot do that because environment variables cannot be read in from configuration files. Therefore, you need another alternative.
  
 At this point you need to create a configuration file for each node.  You will want to come up with some sort of naming convention. Since the original config file was called ND.CFG you may want to simply tack on the node number to each config file (e.g. ND1.CFG, ND2.CFG, ND3.CFG).  By naming them with the node numbers in the filename we will be able to use the PCBNODE environment variable. The most important thing to remember is that you should remain consistent in your naming conventions. If you do not, you will not be able to use environment variables. At this point you need to create a configuration file for each node.  You will want to come up with some sort of naming convention. Since the original config file was called ND.CFG you may want to simply tack on the node number to each config file (e.g. ND1.CFG, ND2.CFG, ND3.CFG).  By naming them with the node numbers in the filename we will be able to use the PCBNODE environment variable. The most important thing to remember is that you should remain consistent in your naming conventions. If you do not, you will not be able to use environment variables.