                          WWIVNEWS Volume 1, Issue 3
                                  March 1991


                               Table of Contents
                               ~~~~~~~~~~~~~~~~~
    SubEd099....................................................Filo 1@5252
    ANSI Menu System Preliminary Proposal.................Intuition 39@6991
    A Watchdog Council...............................Creator O'toole 3@2510
    Space Dynasty v3.03 Review.......................Creator O'toole 3@2510
    WOMR Preview............................................Darkster 1@3114
    G-Files Once-And-For-All Fix.........................Agent Steel 1@6556
    ...Form Letters and Macros.....................................Eric 1@7
    TWIT.EXE - Delete Them Thar Dumb Messages..............John Wash 1@8403
    The Pending File.........................................WWIVNEWS Staff
    Letters to the Editor...........................................Various
    The Editor's Corner.................................East Bay Ray 1@9964
    Acknowledgements.........................................WWIVNEWS Staff
    =======================================================================


                                   SubEd099
                                by Filo 1@5252

          SubEd099 is the third and last beta version of a Sub Editor
    program which I wrote to help me keep up with some of the large subs
    which I host. It is written in QuickBASIC and comes with an
    installation program which I also wrote. The installation program
    combines both QuickBASIC and Norton's BE.
          SubEd may be invoked from DOS, from Shift-F10 or from CHAINS. It
    cannot run remotely because I did not build any modem handling routines
    into the program. Its strength, in my opinion, is its ability to run
    from the Shift-F10 function in WWIV, because that allows a sub host to
    read his mail and upon finding a request to add or delete a node from a
    sub, the SysOp can drop to dos, run subed, and make the changes. In my
    case, after finishing the changes, I return to the BBS and invoke the
    Form letter function to notify the node that it has been added/deleted
    from the requested sub. The list of subscribing nodes is maintained in
    sorted order from lowest to highest node number.
          In addition to having a HOST command mode, the program also has a
    SUBSCRIBE mode which creates the appropriate NNxxxx.NET file in DATA
    with the host's node number in it and which permits a crude form letter
    to be sent to the host node informing him/her that you wish to
    subscribe to the sub. The form letter must then be sent with the
    //UPLOAD function. Admittedly, this is quite crude, but it does
    alleviate the necessity of having to have my program interface with the
    message structure inherent in WWIV.
          A REVIEW function exists in the program which permits the user to
    obtain a listing of all subs subscribed to. The listing is merely a
    listing of the NNxxxx.NET files that exist in the DATA directory. It
    also permits a listing of all nodes contained in a specific Nxxxx.NET
    file. This listing is in 4 columns and does not (at present) contain
    provision to page up or page down through the subscribers. Thus, if the
    sub has more than 196 subscribers, the first page(s) fly by.
          Finally, the program contains a feature to allow you to page
    through SUBS.LST, SUBS.1 and SUBS.2. If the latter two files do not
    exist in DATA, you must create dummy files for them in order to prevent
    the program from aborting.
          Several people have asked why the program does not contain
    features similar to the SUBEDIT program written by Richard Ruffner. The
    reason is rather simple. I ran Mr. Ruffner's program when it first came
    out (almost 2 years ago) and did not particularly like it at that time.
    After a couple of uses it was discarded. Thus, due to my failing memory
    (hehe), I do not even remember what Richard's program looked like or
    what features it contained. I suppose I could look as I think I still
    have a copy, but by not looking at his program, I can honestly say that
    mine is not a clone of his program.
          In the near future, I hope to release SUBED100 which will correct
    the few remaining bugs in SUBED099 (mainly unexpected aborts due to
    poor programming on my part) and which may improve upon the crude form
    letter situation. I welcome any suggestions that you, the readers, may
    offer.
    =======================================================================


                     ANSI Menu System Preliminary Proposal
                             by Intuition 39@6991

          Designing a menu for a BBS has long been a problem for the
    developers of the BBS software and the SysOps of the BBS's that runs
    the software. Due to both size of the user's screen and modem speed
    restrictions, they are often time-consuming for the expert user who is
    looking for an obscure function, such as "//NET", and complicated for
    the beginning user. Embedded ANSI codes to change the color of certain
    portions of the menus (highlighting key commands) may solve the latter
    problem while compounding the former. Now, with WWIV commands
    constantly changing through the addition of modifications, users find
    themselves constantly checking the menus to find the command to use the
    off-line reader or to see what prefixes are local to them. Is there a
    solution to this frustrating problem?
          Fortunately, yes. This article explains a possible method of
    placing the menus on the remote user's hard drive or RAM that can be
    called up with a simple keystroke and scrolled up and down to view all
    of the commands. Such a menu would be invoked through an ANSI code of
    around 10 bytes, sent from the local (BBS) side of the connection.
    Naturally, such a system is not without its drawbacks.
          The first is a user who does not have ANSI menu capability. This
    can be easily eliminated by sending out an ANSI menu detect code (much
    like WWIV 4.12 sends out an ANSI detect code). If the remote system has
    ANSI menu capability, it will respond with another code containing the
    version number of the ANSI menu driver, so that the BBS can attempt to
    prevent sending codes intended for future releases of ANSI menus.
          Next comes the problem of users who have old versions of a
    certain BBS's menus. For example, a SysOp may add a new command to the
    main menu through a mod that he recently added. Again, this can be
    solved by the BBS sending a code requesting the version of the menus
    the remote side is running off of. If it is an older version, the user
    would receive the new menus through a file transfer that is initiated
    by the BBS, but can be terminated by the user--that is, the ANSI menu
    driver will alert the user that he is about to receive a new packet of
    ANSI menus, and can give the user the choice of receiving the packet or
    aborting the transfer.
          The question of "Where will the time remaining and current
    message sub number and title go?" comes up. The current solution to
    this problem is to place the time remaining along with other statistics
    in a status line on the very top of the screen that will include the
    BBS name, user and node number, time remaining, and editing function
    status (such as insert mode) or percentage into current menu and line
    number (since the menus would scroll up and down to display the entire
    menu). The message sub prompt would go into the bottom line of the
    menu. The menu itself would be between these two status lines or
    "bars."
          Just how much of the screen these menus take up would be left up
    to the user, unless the BBS needs a certain amount of lines to edit
    messages (which would necessitate a code to lock and unlock the size of
    the menu). This would permit an expert to quickly scan through the menu
    looking for a mod command, while permitting a beginner to gradually
    browse through the available commands. Since the size would affect the
    page pauser ("[PAUSE]"), yet another ANSI menu command would be sent by
    the remote system telling the BBS how many lines are available for the
    actual display.
          Clearly, this system is incomplete and very open-ended.
    Technicalities, such as the storage format of the menus, implementation
    into current terminal programs, and differing systems (Amiga, IBM,
    Macintosh, etc.) present problems unaddressed by this article. I
    encourage anyone with suggestions to e-mail me at 39@6991 on WWIVNet.
          A list of the current ANSI menu codes is available (due to space
    constraints, they were not included with this article). If you want a
    copy of these codes, just e-mail me at 39@6991 on WWIVNet. For your
    information, all but two of the codes start out with ^[ (the escape
    character, 0x1B hexadecimal, \033 octal), the "." character, a 1 letter
    command, ! or ? identifying it as the BBS or remote system, and finish
    off with a four-byte hexadecimal value (in ASCII format) or a string
    whose length is determined by another command.
    =======================================================================


                              A Watchdog Council
                           by Creator O'toole 3@2510

          In the 205 area code there was a recent uproar because of a
    single SysOp. There is no way to recount the details of the whole
    ordeal because each story is a little different from each SysOp. The
    end result is that a SysOp got the entire state of Alabama boycotted.
    The SysOp spread misinformation about his removal from WWIVNet and got
    support for a boycott. Something like this should not have been able to
    happen.
          When any group or organization is as large as WWIVNet, someone
    should be there to watch everything that is happening. When someone is
    not watching close enough, events like the 205 boycott take place. Some
    may say that the ACs, GCs, and Random are there to protect the net. The
    ACs and GCs already are there for the processing of the nets and they
    were a much needed addition, but they do not have the time to do
    something like this. Random already takes care of the WWIV software
    updates, network software updates, WWIV support, rules and regulations
    of WWIVNet and his own BBS. It is clear that an AC, GC or Random cannot
    handle the entire network to make sure wrongful things do not occur.
          To take care of this, I believe a Watchdog Council must be
    created. It would consist of members from each region in WWIVnet. Each
    member would have the power to suspend a BBS from the net, and possible
    expulsion based on what Random has to say. A group like this could have
    put a stop to the boycotting of the 205 area code before it took place.
    =======================================================================


                          Space Dynasty v3.03 Review
                           by Creator O'toole 3@2510

          Since the old Atari ST days of BBS'ing, space games have always
    reigned king among games. Hollie Satterfield has taken the space game
    to new heights with his release of Space Dynasty for the WWIV BBS. Many
    space games like Tradewars and Yankee Trader present the new gamer with
    a wealth of commands and choices, most that may take some time getting
    used to. Space Dynasty cuts through this to a simple, yet powerful
    multi-process menu.
          Each turn consists of various actions that can take place. These
    actions usually consist of domestic affairs, then foreign affairs. You
    start off having to worry about your armies and people and help pay to
    feed them. Then as the game progresses you test out your foreign
    diplomacy abilities. You are allowed to make treaties, spy, trade, and
    attack other dynasties. Sp ace Dynasty has made this easier than most
    space games with its simple straight-forward menus. The action in the
    game moves quickly and doesn't bog down at all. There are also other
    events that can befall you, that are sometimes beyond your control. To
    add an entirely new dimension to online games there is now a net
    option.
          Using the net option you can play against other BBS's which
    increases the enjoyment of the game twofold. The net option treats the
    other BBS sort of as another galaxy in which it may actually take a day
    or so for your orders to be carried through. The original version of
    Space Dynasty that had the networking ability unfortunately had a bug.
    However this version of the game has fixed that bug completely. Other
    than its networking ability is the way Space Dynasty will protect new
    dynasties. New players are protected for 20 turns which allows them to
    build themselves up to a decent respectable level. This particular
    protection clause is probably one of the n icest additions to a space
    game that I have seen.
          I have enjoyed playing Space Dynasty more than any other game
    available for WWIV. I wish that Space Dynasty would pay more attention
    to its roots in the Atari ST game Space Empire which has several
    options Space Dynasty does not have. Space Empire's Heavy Cruisers are
    something that the current version of Space Dynasty could really use.
    Also more spying options would be nice to see in Space Dynasty. However
    with the ease of use, ease of setting up, and enjoyment I must say that
    this is the most formidable game on the market.

    [I would like to reader to note that while Netted Space Dynasty works
    over WWIVnet, the net feature IS NOT RECOMMENDED to be used. It DOES
    work, but it uses an awkward method of distributing updates which may
    change at any time in a new release of the WWIVnet software by Wayne
    Bell. The author really should use main_type_external (6) for
    distribution of third-party software updates instead of using
    main_type_pre_post (5) and sub type 0. -Ed.]
    =======================================================================


                                 WOMR Preview
                              by Darkster 1@3114

          Eclipse Software is currently developing an offline reader system
    for WWIV bulletin board systems. Below are some of the features that
    will eventually be built into WOMR:

      Packetizing of messages/mail/system news for download. Subs marked to
      be scanned with the "N" scan option will be included in the packet.
      The reader will eventually be capable of automatically retrieving
      message via the !-@REMOTE@-! hook built into WWIV. Early beta
      releases will only work via a door/chain.

      The reader will also be capable of manually adding packets downloaded
      via another communications package. The final production release will
      allow replys (public) and auto-replies (private) to messages.

      A support/beta test sub has been set up for contribution of ideas and
      bug reports. The sub-type is 3124 hosted at 3114. The final release
      of WOMR will be released as shareware. (Both the sysop module and the
      user module)
    =======================================================================


                         G-Files Once-And-For-All Fix
                             by Agent Steel 1@6556

          Wayne Bell sent mail to all Sysops warning them of this problem
    in WWIV v4.12 which would make their G-Files disappear. So... This
    could be a real pain! He said to move the GFILE.DAT file from the DATA
    directory to the GFILES directory. Jeff Garzik (East Bay Ray - 1@9964),
    the editor of WWIVnews, did come up with a source code fix for part of
    the problem in the January WWIVnews file.
          With both of these fixes, nothing would work after the GFILE.DAT
    file had been edited (with //GFILEEDIT or "G" from the WFC Menu). The
    following fix requires the source code, as well (which will only cost
    $50, so if you're reading this and don't have your BBS registered, then
    ask your users to donate to get it done).
          The fix? The following line can be found in TWO files... XINIT.C
    (in "void init"), and in GFLEDIT.C (in "void gfileedit"). Search for
    the following line:

             sprintf(s,"%sGFILE.DAT",syscfg.datadir);

     Now change the line to read:

             sprintf(s,"%sGFILE.DAT",syscfg.gfilesdir);

          Be absolutely sure that the line is changed both XINIT.C, and
    GFLEDIT.C, or else it won't work right at all. Upon completion, re-
    compile and everything will work perfectly. Try //GFILEEDIT find out!
    =======================================================================


                     One Step Validation for WWIV SysOps;
                     A Tutorial on Form Letters and Macros
                                  by Eric 1@7
                      Copyright (C) 1991 by Eric Newhouse

    Introduction
    ------------
          Most WWIV SysOps validate hundreds of new users per year.
    Unfortunately, the validation process takes an inordinate amount of
    time and effort. The simple process of responding to validation
    feedback requires an incredible amount of time, particularly on a busy
    system with a lot of new users.
          There is an easy solution to this problem, a solution which
    doesn't entail quitting your job or dropping out of school in order to
    find the time to validate new users. To solve our problem, we turn to
    the FORM LETTER and MACRO features of WWIV.

    Form Letters
    ------------
          The first step of this process, and the step that will save you
    the most time, is to create a set of form letters that you will send to
    new users as you validate them.
          For example, on my board I only validate users who I think will
    contribute in one way or another. Therefore, if a new user tells me
    that he intends to post a great deal, I send them a form letter
    thanking him for agreeing to participate in the message bases. If the
    user agrees to upload new files to my board, then I send a form letter
    thanking him for that. All told, I have about half-a-dozen form letters
    for different types of new users.
          WWIV offers a lot of flexibility here. Create only the form
    letters that you think you'll use. You may want to start with only one
    form letters: one which says: "I've validated you." Or, you may decide
    to design form letters for specific user profiles, as I've done. The
    choice is yours.
          Many new WWIV SysOps aren't aware of how the form letter feature
    works in WWIV. Here are five easy steps to sending your own form
    letters:

         1.  Use an ASCII text editor or WWIV's own internal editor to
             write the form letter.

         2.  Save the form letter using the following naming convention:
             FORMxxxx.MSG, where xxxx is the name of the form letter. For
             example, the filename of the form letter that I send to all
             new users who agree to upload is FORMUL.MSG; the name of the
             form letter is "UL".

         3.  Place your form letter in your GFILES subdirectory (ie.
             C:\WWIV\GFILES).

         4.  To send the form letter, type "O" from the "Mail {?} :"
             prompt, and then type the name of the form letter.

             Notice that the form letter name can NOT be longer than four
             letters long (xxxx) due to constraints on DOS filename length;
             this is why the name of my aforementioned form letter is "UL"
             and not "UPLOAD".

         5.  Type in the title of your form letter!

          You do not need to limit yourself to sending form letters at the
    mail prompt. You may also //LOAD them into memory, referring to them
    using their path name (ie. "GFILES\FORMUL.MSG"). If you //LOAD a
    formletter into memory, you may not use the full path name since WWIV
    prefaces your input with C:\[BBSDIR]\.

    Macros
    ------
          Once you have developed a set of form letters, you are ready to
    use macros to completely automate your validation process. As in the
    case of form letters, the macro function in WWIV is extremely flexible.
    Whatever keystrokes you use to validate new users, with the exception
    of Ctrl-Z, may be saved for use again and again.
          If you have created a macro before, you may create macros by
    entering D:efaults, typing "7" to Update Macros, and then "M" for M:ake
    macros. After selecting which macro to create (ie. "A" is <Ctrl-A>,"
    type the exact same keystrokes that you would to validate a user. Thus,
    when entering a carriage return, hit [ENTER] instead of typing "^M" in
    directly.
          Let's look at my board again as an example. Here at @7, validated
    users receive security level 50. Thus, I have created the following
    <Ctrl-A> Macro: "v50^M50^M^M^M^MoUL" Let's take a close look at what
    each part of this macro does:

         v     - Activates validate user routine from the "Mail {?} :"
                 prompt

         50^M  - Sets new user's Security Level to 50.

         50^M  - Sets new user's Download Security Level to 50.

         ^M    - Doesn't change any of default AR's.

         ^M    - Doesn't change any of default DAR's.

         ^M    - Doesn't change any of default Restrictions.

         O     - Activates the form letter function.

         UL    - Types "UL" as default form letter type.

          Clearly any part of this macro may be changed to suit your taste.
    At the end of the macro, WWIV will have just validated the user who
    sent you mail (validation feedback), and it will prompt you to enter
    the name of the form letter to send that user in response.
          A working macro gives you quick, easy, and efficient validation
    from the mail prompt, directly after reading the validation feedback.
    When I consider the thousands of users I have validated in my WWIV
    lifetime, I know that this simple combination of form letters and
    macros has probably saved well over 24 hours of my life.

    Author's Note: All references to gender (ie. "she, his") are
                   GENDER NEUTRAL references; they may refer to
                   either sex.
    =======================================================================


                   TWIT.EXE - Delete Them Thar Dumb Messages
                             by John Wash 1@8403

          TWIT.EXE is a new utility that allows sysops to remove all
    network mail from certain users or certain systems.
          Credit for the TWIT concept goes to Charles Boyer @9962. I stayed
    with Charles during part of my visit to North Carolina last year, and
    he mentioned that he wished that WWIVnet provided some way to delete
    messages from idiot users before they hit the message bases. Charles
    had a few particularly annoying users on his Current Events sub. He
    didn't want the messages to even be posted on Current Events, and
    mentioned to me that I might consider writing a utility that, when
    given a list of users and systems, would delete any message from those
    users or systems. And that's what TWIT is.
          TWIT's name comes from a facility provided by the Hudson-style
    offline reader known as QMX/XRS. XRS allows you to give a list of
    names; when XRS collects the messages, it will ignore any messages
    posted by a person whose name is contained within the list. To do this,
    you specify TWIT <username> in an XRS configuration file. The term
    "TWIT" accurately described the authors of such messages, so I decided
    to adopt it.
          TWIT's usage is very simple. The sysop creates a TWIT.TXT file in
    his main BBS directory, and in it places a list of users and systems.
    The following might be an example TWIT.TXT file:

    ;Comment line
    1@9000        ; Remove all messages from user 1 @9000
    @8888         ; Remove all messages from system @8888
    1501@1        ; Remove all messages from user 1501 @1
    ;EOF

          TWIT works by modifying the P1.NET file before running NETWORK1.
    If it finds a message from a user/system that's specified in the
    TWIT.TXT file, it marks that message as deleted and continues through
    the file until it reaches the end. NETWORK1 will not analyze any
    message that has been marked as deleted; therefore, all of those
    messages are ignored and not placed in the message bases.

          TWIT is available on my system (Xanadu, @8403). My new BBS phone
    number is 804/330-5425. I am also fully SNARFable; SNARF TWIT.ZIP for
    the latest version of the TWIT utility.

    TWIT is (C) 1991 by Data Systems Engineers, Inc.
    =======================================================================


                               The Pending File
                           (Tips, Tricks, and News)
                               by WWIVNEWS Staff

    US Robotics has apparently lowered their sysop's deal price for the
    Dual Standard to $499 ($500 to most folks). No one has commented on
    whether or not this change is permanent, so get one while you can!
    =======================================================================


                             Letters to the Editor


    WWIVNEWS,
          Could we give each new newsletter an incremental number or
    something? Like: NEWS0191.NET or something like that? Make it like
    volumes or something, with the month/year as part of the filename. I'd
    like to keep back/new copies of the newsletter in my G-Files, but as it
    is now, a new one will overwrite last months (I'm lazy, i just want to
    copy NEWS*.NET to my gfiles section in my nightly event...).
                                           Darkster 1@3114

    [John Wash had similar suggestions last month. However, it will stay
    the same way basically because Wayne already put it in the code that
    way, and he is reluctant to change it so quickly after its birth. I do,
    however, provide on my board back issues for anyone not collecting
    them. If you wish to contact Wayne Bell about changing the software,
    you have my blessings. It certainly would be a much better way of
    distribution. -Ed.]
    =======================================================================


                              The Editor's Corner
                            by East Bay Ray 1@9964


          The WWIVNews policy on submission acceptance has been vague up
    until this point, so I would like to clarify it. My policy is to accept
    ALL responsible submissions. I don't care whether I agree with their
    position or not. Some examples of articles I will NOT accept would be
    ones that contain many foul or abusive words, articles that contain
    information that is dated or no longer relevant, or articles that are
    clearly biased against a certain group (whether it be race, color,
    religion, creed, etc.). Finally, I will not accept articles not
    pertaining in some remote way to WWIV or WWIVnet. This will not become
    another FidoNews, with articles on the environment in a [supposedly]
    computer magazine.
          There is a contest going on. If someone can come up with a good,
    conservative and ASCII-ONLY (no extended IBM graphics either) drawing
    for the logo of this newsletter, I would like to put it at the top of
    every succeeding issue. Any ASCII artists out there?
    =======================================================================


                               Acknowledgements

    WWIV (c) 1988 by Wayne Bell.
    All other products mentioned are either registered trademarks or
      copyrighted by their respectives manufacturers.
    =======================================================================


                                    The End

 