
5. You need to write 2 text files and 2 batch files.
        A. One text file and one batch file will be used when users
        ENTER the room, and the other text and batch files will be used
        when they EXIT.

           (a) The ENTER files;
              entry batch <pcin.bat> is simply -

      @echo off
      copy c:\sbbs\xtrn\pcsuprt\pcin.txt c:sbbs\node%1\moduser.dat > nul


              The ENTER text file is a 17 line long text file <pcin.txt>,
              all lines blank except the affected flag areas. See the
              MODUSER.DAT example in the Synchronet manual, right before the
              Glossary) for contents. On the "Flags #3 to remove" line,
              type in the flag ("A" was mine) that is to be removed -
              this takes away the user's main board access. On the
              "Flags #4 to add" line, type in the flags for the room
              ("A" was mine) to turn on John's access to this room's
              functions.

           (b)  The EXIT files;
              exit batch <rmreset.bat> -

 @echo off
 copy c:\sbbs\xtrn\pcsuprt\rmreset.txt c:\sbbs\node%1\moduser.dat > nul

              The exit text file is the same as the entry file except it
              reverses the accesses. It removes room access flags and
              replaces main board access flags. Since Flag Set 4 is
              always going to be used from room Access Requirements on
              my system, I use the same "rmreset.txt" for all rooms. It
              removes ANY/ALL Flags from Set 4, and ADDS the main board
              access FLAG 3A. (Yours may be handled completely differently.)
              > Each room requires both *.bat files and both *.txt files.

              You have now written external programs, and Synchronet
              ONLY looks for and reads moduser.dat files on returning
              for external programs that have been configured in SCFG,
              so now...

6. Goto SCFG > External Programs > External Programs and add your
external program wherever in that setup you want it. Give it a memorable
name so that if you end up with lots of doors, you'll know what's what.

        a. In the external program setup screen set:
             >  the name of the external program, internal code, startup
                directory (C:\sbbs\xtrn\pcsuprt), command line (very
                important) "pcin %#", MultiUser-Yes, Modifies User data
                - Yes. Drop file none.

             >  Do the same for the exit rmreset.bat file. You'll have two
                external programs for each room and call each from
                baja - one before entering mymod.bin, and one after
                exiting mymod.bin.

             >  Set the Access Level to 90+ so noone can see them from
                the BBS.


7. Modify the main command shell that will call the room to include a
way <keystrokes> to call it. If you're going to have more than one,
add a room selection menu, or add them to your main menu. Whatever you want.

                        ------------------------

That's it! You now have a room! The external programs run lightning fast
and don't display to remote users, so they don't even know it's
happening.

There's one other external program (batch file and text file) that you
should write. Some users will undoubtedly drop carrier (hang up) while
in a room without going through the exit.bat procedure, so their flags
will be wrong the next time they log in. One way to prevent this is to
add code in mymod.src so that after they press "O" or "/O" (while IN the
room), but before "logoff" or "logoff_fast", the rmreset xtrn is called
to reset their accesses to "normal".

But, in my command shell, just before :main, I placed code to test the
user's Flag 3A, and if he doesn't have it, it calls the rmreset external
program to return his accesses to "normal". Hopefully, this prevents
screwed up accesses if mymod.bin has undetected defects, or if the
user's accesses get warped by another module or room.

How complicated can you make it? Well, you can nest these rooms as deep
as you can conceive. BBS within BBS within BBS, room within room within
room! (Careful of your baja calls though. Don't get lost!)

Rooms done with this method require no unusual handlings in the board
itself. It stays the same except for ARS access settings. So you'll
never corrupt or misplace a message base or library.

Power users can request an account that you toggle all room accesses
permanently ON in their accounts and they never have to go into a room,
or they can have special access to another command shell that has no
rooms.

