BBS Toolkit

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

/ BBS Toolkit / BBS Toolkit.iso / spitfire / whatsnew.33 < prev next >

Wrap

Text File | 1993-05-16 | 47.1 KB | 1,051 lines

ATTENTION BETA TESTERS: Beta testing is NOT merely the opportunity to run the latest software version. As a beta tester you have a RESPONSIBILITY TO TEST EACH NEW FEATURE AND CHANGE that is described in this WHATSNEW.33 file and REPORT YOUR TEST RESULTS to Mike Woltz. This means YOU! The best way in the world to lose your beta test rights is to not test and report! February 4, 1993 I have made a change in the manner in which SPITFIRE initializes the modem which should afford the Sysop greater flexibility. When you first boot this copy of SPITFIRE, the initialization of your modem will most likely fail (I hope it does). When you see the below message when booting this copy of SPITFIRE, answer "Yes"... ■ Your modem is not properly responding. ■ Do you wish to continue? [y/n] Then at the "SPITFIRE ready..." prompt, press your ALT+M keystrokes. You will see a new variable within the ALT+M window. This new variable is referred to as the " Pre-Initialization String" ... Previously SPITFIRE automatically sent an ATZ followed by a carriage return to the modem before sending the configured modem init string. Now SPITFIRE sends the configured "Pre-Init string" to the modem before the configured init string. The reason for making this configurable is that I recently discovered that there are a few (VERY FEW) modem that will choke if the ATZ is followed by a carriage return. Therefore, the ONLY way (that I can think of) around this is to make it configurable (this should cause me not less that about 10000 messages a year). In other words, if your modem needs a carriage return after the ATZ (99% will) then you need configure the "Pre-Initialization String" as ATZ^M ... If your modem is one of those that chokes on the carriage return, then you need to configure the "Pre-Initialization String" as ATZ. In the event the configured "Pre-Initialization String" is not acceptable to your modem, SPITFIRE will display: ■ Pre-Init String Failure Further, SPITFIRE previously automatically sent a carriage return to the modem after sending the configured init string. This has been changed. Now, if you want a carriage return sent after your configured modem init string, you have to end your modem init string with a ^M ... for example if you want a carriage return sent to your modem after your configured init string (99% will want this) then your modem init string will need to look something like this: ATS0=0V1Q0E0H0M0S2=1X1^M otherwise it will need to look something like this: ATS0=0V1Q0E0H0M0S2=1X1 NOTE TO JACQUE SHIPLEY: Jacque, have fun explaining this in the manual. February 2, 1993 I received a call last night around midnight and the call jogged my memory. I have now made a couple of last (very nice in my opinion) additions to SPITFIRE. SPITFIRE now supports 5 'privileged security levels' per File Area and per Message Conference. These 'privileged security levels' supercede the security level and access configuration of each File Area and Message Conference. For example, if the security level of a Message Conference is set at 100 and the privileged security levels are set at 10;15;20;0;0, then any caller with a security level of 10,15,20 and 100 (or greater than 100) will have access to such Message Conference. The purpose of these additions is to solve the problem of a Sysop wanting (for example) callers with security levels of 10, 15 and 25 to access to an area but not callers with a security level of 20. In such case, the security level of the area could be set at 21 and then set privileged security levels to 10 and 15. Clear as mud???? NOTE TO JACQUE SHIPLEY: Jacque, this reminds me that (if we aren't already) we need to explain that the last File Area and last Message Conference of a new caller defaults to File Area #1 and Message Conference #1. Therefore, File Area #1 and Message Conference #1 should always be generic (so to speak). These additions will provide Sysops much more flexibility with File Areas and Message Conferences. Please give this change a complete test and report your findings. Thank you! BTW, I am still waiting for the 'green flag' with I referred to in my January 30, 1993 remarks. January 30, 1993 Folks, as far as I am concerned, SPITFIRE v3.3 is finished. There is still some work to do with LAKOTA which I hope to get finished this weekend. Please test each and every change in SPITFIRE and make a report. In the event there are no unforeseen problems and when each beta tester gives me the green flag, we will then release it. Thank you for all your help. The SPITFIRE.HLP file has been revised to reflect the changes and additions in SPITFIRE v3.3. Please have a look at this file and let me know if you concur with its content. The internal caller database pack feature has been removed and SPITFIRE v3.3 will now shell to SFPCKUSR.COM. Therefore, SFPCKUSR.COM must be placed in the SPITFIRE HOME directory. SFPCKUSR v1.3 or newer MUST be used. Please test this change and report your findings. Thank you! January 24, 1993 When maintaining the SPITFIRE caller database (ALT+A at SPITFIRE ready ... ) or from the Sysop Menu, SPITFIRE now provides the ability to alter the number of KBytes the caller has uploaded or download. When selecting <D> Downloads and/or Uploads SPITFIRE will then prompt: <N>umber Of Files, ytes, <Q>uit? Then, depending upon the selection made, either the number of files or the number of K-Bytes can be altered. NOTE TO JACQUE SHIPLEY: Jacque, please stress in the SPITFIRE manual the byte in this case is K-Bytes. Jacque, also please note the cosmetic changes in the caller database maintanence menu just i case you show the appearance in the manual. Also, when maintaining the SPITFIRE caller database, when selecting "<M> Change Msg Data" SPITFIRE will prompt: <N>umber Of Msgs, <C>onference, <Q>uit? Then, depending upon the selection made, either the caller's last message conference or the amount of messages the caller has entered can be altered. Please completely test these additions to SPITFIRE and report the results of your tests. Thank you! Have you ever noticed that irritable double-space which shows up in messages entered via SPITFIRE? Well, that little irritant has been there since SPITFIRE v1.0 (does anyone besides me remember that version?) but I believe you will find that it is now gone. It will still show up in messages entered previous to the installation of this copy of SPITFIRE but it should be gone in messages entered after you install this copy of SPITFIRE. This is one of those little fixes which seem simple but can have devastating results. Please pay close attempt to this change and report your findings. Thank you! January 22, 1993 I have made an unnoticeable, but major, in SPITFIRE. I will try to explain. Previously, SPITFIRE used the pascal text file routines (line by line processing) to read and display the various display files (WELCOME1 etc). I have changed this for a couple of reasons. 1) SPEED! This change should cause SPITFIRE's display file to be displayed in the fastest manner possible. You should be able to visually see the difference. 2) ANSI display files! I get tired of answering messages about .CLR files not displaying properly because the files were created using THEDRAW with the line length set improperly. This should cure this problem. I would ask (PLEASE - PLEASE) will someone create a .CLR display file (using THEDRAW) with the line length set at 525 (or some crazy number like that) so it will not display properly using SPITFIRE v3.2 (or v3.3 prior to this copy). Make sure that it doesn't display properly and then try it with this copy of v3.3 and let me know your results. Thank you so very much. PLEASE, PLEASE test this change ... this is one of those sleepers that can cause a ton of grief. PLEASE. January 21, 1993 Over the years, SPITFIRE has not supported an ANSI newsletter (SFNWSLTR.CLR). Quite honestly, I think that there is a reason why but I don't remember what it is. So, now maybe we will find out why since I have changed SPITFIRE to support both SFNWSLTR.BBS and SFNWSLTR.CLR. Also, SPITFIRE nows tests to see if the newsletter has been updated since the last time the caller called. In the event it has been updated, SPITFIRE will provide the caller with the below listed prompt: The newsletter has been updated! Would you like to review it? [Y/n] This occurs after the bulletins feature and before the Main Menu. I am not married to this added feature so if you don't like it then please let me know and I will remove it. BTW, it is only fair for me to mention that this suggestion came from a Sysop who just selected SPITFIRE over another BBS software package which supports this feature. Please give this change a complete test and report your findings. Thank you! January 17, 1993 When a message is being into a 'non-mail-system' Message Conference, SPITFIRE tests to be sure the addressee is a caller of the board. Previously when SPITFIRE was unable to match the name, the caller was simply notified that the addressee was not a caller of the board then returned to the Message Menu. Now, the caller is notified that the addressee is not a caller of the board and then prompts the caller 'Try again? [Y/n] '. This is one of those simple changes that can turn to *&)&^^*. Please, (PLEASE) give this change a complete test and report your findings. Thank you! January 15, 1993 I removed the 'efficiency report' (F5 screen) from SPITFIRE. The only purpose it ever served was to cause messages addressed to me asking what it was. January 14, 1993 The <T>...... Text Search feature on the Message Menu has been changed so display the message when the specified text is discovered. Please give this change a complete test and report your findings. Thank you! January 9, 1993 The "<V>...... View A File Archive" on the File Menu has been revised to display the new 'Deflated' compression method used by the new ZIP programs. January 5, 1993 The name of text file created when selecting the rint Caller Database from the Sysop Menu and then select Print to <D>isk has been changed from SFUSERS.TXT to SFUSERS.LST. This was changed to avoid overwritting a file named SFUSERS.TXT created by my SFUSERS utility. January 3, 1993 When selecting <Y>our stuff from the Main Menu, the caller will now find some additional information. This new information is "Messages Entered" which reflects the number of messages the caller has entered. Please give this addition a complete test and report your findings. Thank you! December 31, 1992 I changed the Message Conference configuration portion of SPITFIRE by adding the ability to add/change the conference "Net ID Name". This conference "Net ID Name" is used by BCSUTI and LAKOTA (other programs will most likely use it as well). Also, when the Message Conference description is changed and the "Net ID Name" is null, then SPITFIRE automatically uses the first 13 characters of the Message Conference description for the "Net ID Name". NOTE TO JACQUE SHIPLEY (Jacque, please note the cosmetic change in the Message Conference configure menu just i case you show the appearance in the manual.) Please give this change a complete test and report your findings. Thank you! December 26, 1992 It is becoming apparent that persistance wins my heart (really I just get tired of saying no). SPITFIRE v3.3 now supports the current 'standard' of DOOR.SYS (How can it be a standard if it changes every couple of years?). A reason for this change is it becomes easier to make the change than to say 'no' in a message nearly every day when the 'no' is no accepted. Rather than accepting my 'no', it just becomes a message marathon. For the record, this change added 901 bytes to the SPITFIRE.OVR file and 16 bytes to the SPITFIRE.EXE file and took over 3 hours to code. Does anyone really think it is worth it? A little history for you. The reason that SPITFIRE supports DOOR.SYS to start with is because about 2 or 3 years ago another fellow just wouldn't quite leaving me messages (it becomes easier to give in than to argue about something in the message base for what seems an eternity - everyday a new message about it). I finally gave in and added it to SPITFIRE and within a very short time I was advised of a new format for DOOR.SYS (how can it be a standard if it keeps changing????). Anyway, the changes were made without consulting me for any input. Apparently SPITFIRE is not a big enough fish in the pond to participate in this decision making process. Tell you what I'll do ... I'll bet the next thing will be that someone will want SPITFIRE to read DOOR.SYS upon return from a door. Does anyone want to bet? Please give this change a complete test and report your findings. Thank you! I received word this morning that there are two individuals who are apparently doing their best (as usual) to generate hate, descension and then kind of nonsense. Below (so you will know what I am talking about) is a portion of the message I received. MSG> I know that you don't want to hear all of the negative garbage, MSG> but there has been some discussion in the Spitfire conference MSG> about a reduction of features because the door option was removed MSG> from the file and message menus. You probably already know who MSG> these two individuals are. I think this is an asinine argument. MSG> More important, the users really don't seem to care. I just MSG> wanted to let you know that I like the changes and am confused as MSG> to why these two don't. I suspect that it is just their nature. First, let me make it perfectly clear that there has NOT been a reduction of features. SPITFIRE still supports the same number of doors as it has in the past. Do anyone suspect the TRUTH is again being distorted for personal benefit and gain and to generate hate and descention. It makes me wonder if these individuals will ever grow up and conduct themselves in an adult manner. I cannot understand why this type of conduct is tolerated on a mail system but it surely serves to freshen my memory regarding 1 of the reasons I don't participate in any mail systems. What do you think, folks, should I remove the <S>huffle Files feature and the SPITFIRE .QWK mail door (LAKOTA) and return the door option to the File and Message menu. Do we want to make SPITFIRE progressive or should we allow this type of conduct to prohibit progress? Please let me know your feelings. December 25, 1992 Prior to starting a download, SPITFIRE lists the files to be downloaded. For example: -------------------------- SF32-1.ZIP SF32-2.ZIP -------------------------- 2 File(s) to be sent. This has been changed to show the number of bytes to be sent. For example: -------------------------- SF32-1.ZIP SF32-2.ZIP -------------------------- 2 File(s) to be sent totaling 497,273 bytes. December 24, 1992 I guess persistance wins my heart (really I just get tired of saying no). I have added a new feature to the READ MESSAGE MENU. This new feature is "<-> Previous" (previous message). Quite honestly I have never had a problem with entering the number of the message which I wanted to go back and read but what do I know. I can't help but suspect that this is one of those "other BBS software has it so SPITFIRE must have it too" features. I going to sit and watch my boards for 24 hours straight and see how often this feature is used (smiling - anyone interested in a wager on this one?). Anyway, enough of my sarcasm. This is a feature that will require lots of testing. It seems like a simple addition but it is one of those that can cause more grief than it is worth. Some of the tests to be run is "what happens when the beginning of the conference is reached". What happens if the caller is reading message 123 and does not have access to messages 118-122 (are the messages properly skipped?). Please give this change a complete test and report your findings. Thank you! BTW, some of you are not reporting while others are doing a very good job of reporting. I am serious when I say "The best way in the world to lose your beta test rights is to not test and report!". If you don't want to test and report then please move over and make room for those who want to test. For those of you doing it right, "Thank you!". December 21, 1992 SPITFIRE has been changed to disconnect when a call is received and ATD is the first 3 characters of the first name. For example, SPITFIRE will severe the connection in the event the below is entered at the 'first name' prompt: Enter your first name: ATDT1-515-225-8496 I believe that I have found the source of a problem which has existed for a number of years now. The problem has been reported that the SPITFIRE message base scan does not always report all of a caller's messages. I have discovered that there is a program written to be used in conjunction with SPITFIRE which will allow a caller's name to be entered differently than SPITFIRE allows. For example, SPITFIRE uses Don Mcwhirter while this program will allow Don McWhirter (looks pretty). When SPITFIRE scans for a caller's messages, it compares the CRC in the .IDX file against the CRC of the caller's name and does not scan the caller's name. So, the CRC of Don McWhirter is different than the CRC of Don Mcwhirter which will cause messages to be skipped. To avoid this problem, I have changed SPITFIRE to convert Don McWhirter to Don Mcwhirter when the caller logs on. I assume my decision to allow functional to override cosmetics this will upset some. December 8, 1992 Due to popular demand (smiling), SPITFIRE now records the second password attempts in CALLERS.LOG when the caller enters a wrong birth date as a second password. Please give this change a complete test and report your findings. Thank you! Beta tester Paul Croteau reports that the new <S>huffle Files feature doesn't work as he feels it should. He claims that if the file to be moved already exists in the target File Area then SPITFIRE will move the file description from the source SFFILES to the destination SFFILES and then overwrite the existing file. He is, in part, correct. In such case, SPITFIRE would move the file description for the source SFFILES to the destination SFFILES but the file itself would not be overwritten. Anyway, I have changed this and now SPITFIRE tests to see if the file to be moved exists in the target File Area and if it exists then the operation is aborted with a message. Please give this change a complete test and report your findings. Thank you! December 6, 1992 A new switch has been added to SPITFIRE. Using the ALT+T keystrokes at the "SPITFIRE ready for use.." prompt, you will find a new switch entitled '<S> Search CD Rom Area SFFILES'. This switch will only have an affect on File Areas which are toggled as 'CD Rom Area'. When this switch is set to 'Yes', then SPITFIRE will search the SFFILES.<x> for the file, otherwise, SPITFIRE will search the CD Rom drive for the file. The purpose of this switch is to allow the Sysop the opportunity to configure SPITFIRE work with a CD Rom in the most efficient manner. In other words, if it is faster to search the CD Rom drive, then the switch should be set to 'No'. When it is faster to search the SFFILES.<x>, then the switch should be set to 'Yes'. I think most times 'Yes' will be the proper setting. Please give this change a complete test and report your findings. Thank you! December 4, 1992 AS YOU SHOULD be aware, SPITFIRE does not search File Areas marked as CD-Rom areas when searching for <N>ew Files. This is because there should never be any new files in such File Areas. SPITFIRE v3.2 prompts: Skipping File Area #2 - "File Area Description" when a CD-Rom File Area is discovered during a <N>ew File search. The purpose of this prompt was for informational purposes ONLY. I have removed this prompt because Sysops were confusing it with the normal Searching File Area #2 - "File Area Description" and they ended up leaving me messages erroneously informing me that SPITFIRE is searching CD-Rom File Areas. Therefore, I have removed the 'Skipping' prompt in an attempt to avoid this confusion. I assume now that I will get messages telling me all about the bugs because SPITFIRE isn't searching all the File Areas. God grant me the serenity to accept the things I cannot change. Please give this change a complete test and report your findings. Thank you! AS YOU SHOULD be aware, SPITFIRE v3.2 displays the normal 'pause prompt' MORE: <S>top, <N>onstop, < ENTER > to continue? rather than the 'tag prompt' when searching for files/text and when no files were found to tag. The <N>onstop feature of this prompt did not work during such operation because (quite frankly) I think it is stupid to go into nonstop mode when the file tagging ability is available. No everyone agrees with me and for whatever reason (unknown to me) they think the nonstop feature should work. Therefore, I have made a change in the <T>ext Search, <N>ew File Search and <F>ind A File Search. Now, when a file(s) have not been found to tag, SPITFIRE will not display the normal 'pause prompt', rather, it will simply continue to scroll since there is no need for the screen to pause. Please give this change a complete test and report your findings. Thank you! November 29, 1992 A change has been made in SPITFIRE which may be somewhat meaningless in some cases. The SPITFIRE hot key has been expanded. I will try to explain. SPITFIRE has always supported a true hot key feature when the default SPITFIRE menus were used (non display file menus). In other words, SPITFIRE would discontinue the display of a default menu and execute the command entered when a caller would press a key. This feature has now been expanded to work when display files are being used as menus. The reason I say this may be somewhat meaningless in some cases is because the feature will not work if the display file menu is designed to disallow the caller to break out of the display. Additionally, most high speed modems have buffer. This means the menu could already be sent to the modem by the time the caller presses a key. In such case, the modem will send the data to the caller (the caller will see the entire menu). Please give this change a complete test and report your findings. Thank you! November 28, 1992 ----------------- The CD-Rom support in SPITFIRE has been changed. When a caller selects <D>ownload, <V>iew, <R>ead and <F>ind from the File Menu, SPITFIRE now searches SFFILES.<x> in File Areas instead of the CD-Rom when the File Area is marked as a CD-Rom area. When the file is found in a SFFILES.<x>, then SPITFIRE searches the appropriate directory on the CD-Rom to be sure the file actually exists. This is supposed to increase the search speeds tremendously. Thus far, there have been 4 systems test these changes against previous copies of SPITFIRE. 3 of the 4 report speed increases of 5 to 8 times faster searches while 1 of 4 reports the change makes searches about twice as slow. (Have you got that one figured out???? I don't). Please give this change a complete test and report your findings. I would like accurate information on the difference of speeds from your tests. Thank you! November 27, 1992 ----------------- Some cleanup changes have been made to the 'send private file' feature within SPITFIRE (in conjunction with SFSENDIT.COM). Previously, if a private file was flagged for a caller to download and SPITFIRE was unable to find such file, then SPITFIRE would proceed with the download and would give erroneous information about the file size etc. This has been changed. SPITFIRE now checks to be sure the file exists before proceeding with the file transfer. SPITFIRE now shows the caller the size of the private file. Please give this change a complete test and report your findings. Thank you! November 22, 1992 ----------------- I have made the last change (I hope) in regard to the bi-directional file transfer support. Previous to the compilation, when entering a blank file name on the upload side of feature, SPITFIRE would then ask "Start transfer now" (or whatever it is). In the event the caller answered "no" to the question, then SPITFIRE would take the caller to the Batch Upload Menu. SPITFIRE now shells directly to the appropriate external file transfer batch file rather than asking the "Start transfer now" question. The reason is that going to the Upload Batch Menu was confusing to the caller. For example, if the caller selected <V>iew Queue (or whatever it is), SPITFIRE would properly show the caller names of the files queued for upload (if any) while the caller was expecting to see the names of the files queued for download. I hope you see what I am trying to explain. In an attempt to avoid this confusion it just seems best to go right to the batch file. Please give this change a complete test and report your findings. Thank you! A nice change, I hope. When replying to a message, the "Public Message [y/n]" prompt now defaults to how the original message is set. For example, if the original message (message being replied to) is a public message, then SPITFIRE defaults to public when prompting the public/non-public question. Please give this change a complete test and report your findings. Thank you! Whoopeeeeeeeeeeeee, another display file. When a caller attempts to perform a file transfer and when SPITFIRE discovers that there is not enough disk space is available (per the Sysop's configuration), SPITFIRE will display NOSPACE.BBS/CLR if found. In the event the file is not found, then SPITFIRE provides this default message "Joe, disk space currently prohibits uploads.". Please give this addition a complete test and report your findings. Thank you! November 20, 1992 ----------------- I fixed what I believe was an oversite in SPITFIRE v3.2. When a caller uploads a file that SPITFIRE didn't know was going to be uploaded, then at the conclusion of the upload when the file is found, SPITFIRE tests to be sure that the file doesn't already exist. When the file is not found, then SPITFIRE asks the caller for a description of the file. The oversite was SPITFIRE ignored the "Search File Area" toggle when searching for a file in the above senario. In other words, SPITFIRE searched the File Area even if the "Search File Area" was turned off. Please give this change a complete test and report your findings. Thank you! November 18, 1992 ----------------- At the conclusion of an upload, SPITFIRE determines the length of time that passed during the upload and then time compensates the caller accordingly. This procedure will not work properly with a bi-directional file transfer because there is no way for SPITFIRE to know how much time was actually used uploading. In other words, it is possible that 18 minutes passed while shelled to the batch file but only 5 minutes of that time was used for uploading. SPITFIRE now, at the conclusion of a bi-directional file transfer, checks the size of the files uploaded (if any) and calculates the approximate time spend uploading the file(s) and then compensates the caller accordingly. Please give this change a complete test and report your findings. Thank you! November 17, 1992 ----------------- The bi-directional file transfer support has been changed. Previous to this copy of SPITFIRE, a caller could load a download batch queue and then when control was passed to the upload side, the operation would be aborted if SPITFIRE discovered that there was not sufficient disk space for uploads. This has been changed. Now, when a bi-directional file transfer protocol is selected SPITFIRE immediately tests the disk space. Now when the disk space is not sufficient for uploads, the operation is aborted immediately (before download queue is loaded). The message provided to the caller in such case has been changed. SPITFIRE now provides this message "Joe, disk space currently prohibits uploads.". Please give this change a complete test and report your findings. Thank you! November 15, 1992 ----------------- The "......... Print Users File" feature on the Sysop Menu has been changed. Previously, this feature simply would send a list of the board's callers to a printer. Now, it will send the list to a printer (if the printer is turned on and ready for use) or to a text file. In the event the printer is turned on and ready for use then SPITFIRE display 'Print to <D>isk, rinter, <Q>uit? ' otherwise it will display 'Print to <D>isk, <Q>uit? '. When rinter is selected then SPITFIRE will send a list of the board's callers to a printer. When <D>isk is selected, then SPITFIRE will create a text file named SFUSERS.TXT in the WORK directory and will send a list of the board's callers to such file. We should also change the Sysop Menu feature's title to ".... Print Caller Database". Please give this change a complete test and report your findings. Thank you! November 7, 1992 ---------------- A couple of years ago there was a request for SPITFIRE to some way display whether the current log on was being performed with a 'error correction' type connection. I agreed with the suggestion but could not find space to display the information (in the top of the screen caller data). Well, Jeremy Brown suggested the method to perform the task. SPITFIRE has been altered to add "/EC" to the BPS of the caller (in the top screen banner) when the connection is "error correction" type. November 1, 1992 ---------------- When opting to View Log Files either from the "Ready..." prompt or from the Sysop Menu, you now have the option of reading replies to the questionnaire files. The >>> VIEW LOG FILES <<< has an option <O>...SFORDER<x>.REP. When this option is selected you are prompted to enter the letter to the corresponding questionnaire file [A..Z]. Next, you are prompted whether to begin reading the file at Today's Date, Beginning of the File, Specify A Date or Quit. If the corresponding log file is not found, SPITFIRE will report this and return to the "Ready..." prompt or to the Sysop Menu. There have been reports that some of the newer modems send different result messages when an error correction connection occurs. SPITFIRE is now hardcoded to search for ARQ, MNP and REL result codes to indicate an error correction connection has been made. In addition to these, the SPITFIRE will search for the error correction control message the Sysop has configured using the ALT+M configuration window. The <M>...Erase SFMSG*.$?? has been removed from the File Removal Menu since it is no longer needed. SFPCKMSG does not make backups of the message conference files. October 24, 1992 ---------------- With the addition of bi-direction file transfers, the batch menu options were changed slightly. The ...Upload Batch Queue was changed to ...Begin File Transfer and the <D>...Download Batch Queue was changed to ...Begin File Transfer. October 23, 1992 ---------------- SPITFIRE now supports bi-directional file transfers. This is somewhat rough but will continue to be updated during the development of SPITFIRE v3.3. The SFEXTDN.BBS file in the SPITFIRE display path should be modified to include the name of your bi-directional transfer protocol. The title of transfer protocol (which will display to the callers) should be followed by a comma and the term "bi-directional" (without the quotes). As an example, your SFEXTDN.BBS might look like this: <A> Zmodem Single File,UseFile Zmodem Batch,Batch,UseFile <C> Jmodem <D> Lynx Batch,Batch <E> Puma Batch,Batch,UseFile <F> HS-Link v1.12 Bi-Directional,Bi-Directional When the ",bi-directional" is found SPITFIRE will automatically assume a batch mode and a usefile mode. In other words, you are not required to include a ",batch" or ",usefile" on the menu line. (For information on this refer to the SPITFIRE documentation.) A new batch file will be called to initiate the file transfer process. SFEXTBI<x>.BAT should exist in your SPITFIRE external protocol directory. <x> should match the character by which your caller selects the associated file transfer protocol. In other words, if the bi-directional transfer protocol is option <A> from the menu (SFEXTDN.BBS) the batch file would be named SFEXTBIA.BAT, if the bi-directional transfer protocol is option <E> from the menu (SFEXTDN.BBS) the batch file would be named SFEXTBIE.BAT, etc. In our example above, the file would be named SFEXTBIF.BAT. The contents of our sample SFEXTBIF.BAT file might look like this: @Echo Off HSLINK -P%2 @C:\SF\EXT\SFEXTRAN.LST When a caller selects a bi-directional file transfer, the caller is first prompted to enter the name of the file(s) they wish to download. This follows existing download procedure, i.e., use of file tagging, etc. SF will continue to prompt the caller until no file name is entered. When no file name is entered, the file names selected for download will be displayed to the caller. The caller is next prompted to enter the file name and description of the file(s) to upload. When prompted for a file to upload and none is entered, SPITFIRE then shells to the appropriate SFEXTBI<x>.BAT batch file so that the bi-directional file transfer can begin. ***NOTE*** In this beta copy of SPITFIRE, selecting D from the file menu will allow the download option to work locally. This is done for testing purposes so that the Sysop can see how the bi-directional file transfer process works. (Your bi-directional transfer protocol will not work locally. This only allows you to view and test the bi-directional file transfer process.) October 11, 1992 ---------------- A new option has been added to the Message Conference Record. You can now toggle a message conference as Read Only. This is done by pressing ALT+R. Pressing the asterick key "*" toggles this from Yes to No. If toggled to No, callers can read and enter messages. If toggled to No, messages may be read but no messages can be entered in this conference. Beta testers should verify that this is set properly for each message conference after installing this copy of SPITFIRE. When opting to view the caller's records, either from the Sysop Menu or by pressing ALT+A at the 'Ready...' prompt, the caller's passwords are no longer visible. Four astericks appear in place of the caller's password. This is a security feature. By selecting 'P' from the menu, a submenu appears which provides the options to <V>iew, <C>hange, or <Q>uit. Viewing a password, simply displays the passward, Change provides the opportunity to modify the password and Quit returns you to the previous menu. The change regarding the display of SF1STM.BBS/CLR and SF1STF.BBS/CLR has been removed. These display files now work as they have in previous versions of SPITFIRE. September 20, 1992 ------------------ In previous versions of SPITFIRE, if operating a multi-node system and one caller on one node was reading a message conference and another caller on another node was saving a message in that same conference, there was a 10 second or so delay in the message being saved. This has been fixed. A new option is available from the ALT+Z configuration window. This option is Upload Available Disk Space. The Sysop will use this option to configure how much disk space must be available before a caller will be allowed to perform an upload. The default is 100k. The display of SF1STF.BBS/CLR and SF1STM.BBS/CLR has been modified somewhat in relation to displaying after a caller returns from the door section of SPITFIRE. Previously, if a caller entered the file section or the message section after returning from a door, these files would be displayed if available. These were displayed even though the caller may have already been shown them prior to entering doors. Because of complaints, this has been modified so that a caller returning from the door section and entering the file or message section of SPITFIRE will not have SF1STF.BBS/CLR and SF1STM.BBS/CLR displayed to them. These will not display even though the caller enters the file or message section of SPITFIRE for the first time upon returning from a door. The SPITFIRE Door option has been removed from the Message Menu. It has been replaced with SPITFIRE Mail System. This option will allow the caller to extract messages for download and to upload replies. This feature uses the .QWK mail format. As is customary with Buffalo Creek Software this feature does not provide alot of bells and whistles options. After the beta testing is completed, if you choose not to use this option, simply set the security high enough so no one may access it. However, during the beta testing, you have an obligation to make this feature available and to test it thoroughly. When a caller selects the SPITFIRE Mail System, SPITFIRE will shell to LAKOTA.COM. LAKOTA.COM must reside in your SPITFIRE home directory. It is written in assembler and will handle your .QWK mail transfers. The mail packet, generated when downloading with this option, should work with any .QWK mail reader. The shareware version previously allowed for a 30 day or 500 caller trial before the unauthorized copy message would appear. This has been changed to a 30 day trial period only. September 13, 1992 ------------------ SPITFIRE's internal message packing routines have been modified. The Turbo Pascal code that was used to pack the message base has been removed from SPITFIRE. SPITFIRE now shells to SFPCKMSG.COM when packing the message either as Event M or from the Sysop menu. SFPCKMSG.COM must reside in the SPITFIRE home directory! In relation with this change, the option Backup Files has been removed when configuring SPITFIRE's Message Conference Records. It has been replaced with Purge Unreceived Messages. If this is set to Yes, when packing the message base any messages older than that configured via the Purge Msgs Older Than option will be purged even if they have not yet been received. If set to No, unreceived messages will not be purged. The Routing feature, recently added to SPITFIRE, will now work with carbon copy messages. So it is now possible to send the same message to 10 different people, routing it to 10 different locations. The Tag Files For Download has been changed to Tag Files For Use. This clarifies phrasing for local log ons where the files can be tagged for copying or moving. SPITFIRE's netmail tagline has been shortened. September 7, 1992 ----------------- The option to select SPITFIRE Doors from the File Menu has been removed. It has been replaced with a new option, Shuffle Files. BE SURE TO SET THE SECURITY FEATURE OF THIS OPTION HIGH ENOUGH SO THAT IS NOT AVAILABLE TO YOUR NORMAL CALLERS! What this feature does is allow files to be moved from one file area to another. When the file is moved, the file name, file size, file date and file description from the original SFFILES.BBS is appended the the SFFILES.BBS of the File Area to which the file is being moved. Files can now be tagged when logged on to the BBS locally. Files may be tagged for erasing or for shuffling from one file area to another. If no files have been tagged and you select either the erase or shuffle option, you will be asked to enter the file name. When you are erasing, you are prompted to verify that you wish to erase the file before it is erased. If you are moving files you will be asked which area to move the file to. You are also given the opportunity to list the file areas or to quit. If you have tagged files and you select to either erase or shuffle the files, the file name you have tagged defaults into the prompt requesting the file name and proceeds the same as if you were entering the file name manually. In other words, if you are erasing tagged files, first you are asked if you wish to erase the tagged files. If you reply with a yes, you are asked to enter the filename but the tagged file name defaults automatically. You are then asked if you are sure you want to erase this file. This continues until all tagged files are processed. If you are shuffling tagged files, when you select S, the enter name of file to move prompt appears but the file name from your tagged files defaults in automatically. You then are asked to enter the file area you wish to move the file to. Pressing Enter will list the file areas or you may quit. This continues until all tagged files are processed. A new feature has been added to the Message Conference Records. This is "Allow Message Routing y/N?". This feature is only applicable to message conferences that have been configured as netmail conferences. When entering a message in a netmail conference, you are prompted as to whether to send the message via netmail, whether it should be purged when sent and now asked "Would you like to route this message? y/N" The default is No. If you respond with a Y, you are next prompted to enter the routing number or name. If you are using BCSUTI ßv1.0, revision 2.8 or greater, the message will automatically be routed for you. If you are using Bob Browne's UTI or earlier version of the BCSUTI you will need to route your messages in the normal fashion. Hopefully Bob Browne will upgrade his UTI to take advantage of this feature. If a netmail message is being entered in a netmail conference which has been configured to not allow callers to delete messages, when entering a netmail message the prompt which asks if the message should be purged when sent is not displayed. September 6, 1992 ----------------- SPITFIRE's message option to copy a message never included the option to mark the message as a netmail message when being copied to a netmail conference area. This has been added. Now if a message is copied to a conference which has been configured as a netmail conference, the caller is prompted the same as if the message was being entered directly into the netmail conference (i.e., whether the message should be marked as a netmail message and if so, whether the message should be purged when sent). SPITFIRE has been changed in regard to the 'Purge message after it is sent? [y/N] ' question when a message is marked to be sent out on a mail network. Previously, SPITFIRE asked this question each time a message was marked to be sent. Now, SPITFIRE will not ask this question if 'Caller Message Deletion' is not allowed in the Message Conference. As usual, this does NOT apply to callers with Sysop Security. September 5, 1992 ----------------- Significant changes have been made to the questionnaire files in SPITFIRE. SPITFIRE can now handle 24 questionnaire files. Previous versions only allowed 9. The questionnaire files have been renamed. They are now called SFORDER<x>.QUE and SFORDER<x>.REP. <x> represents an alpha character from A to Z with the exception of G and Q which are reserved for Goodbye and Quit. Examples would be: SFORDERA.QUE SFORDERA.REP SFORDERB.QUE SFORDERB.REP SFORDERC.QUE SFORDERC.REP SFNEWU.QUE SFNEWU.REP and so on... As before, the QUE represents the questionnaire file and the REP is the file where the answers to the questions are stored. The format of SFORDER.MNU has been modified as well. SFORDER.MNU now uses the following format: <Title of the Questionnaire>,SEC>=x,ONETIME,PRINT The title of the questionnaire can be up to 25 characters and should appear first on the SFORDER.MNU line. The questionnaire title should be followed by a comma. Next the security required to access the questionnaire is defined with SEC<=x or SEC>=x or SEC=x. x represents a numerical value that should coincide with the framework of security levels you apply on your BBS. For this example, let's assume x = 10. SEC<=10 would allow callers with a security less than or equal to 10 to access the questionnaire. SEC>=10 would allow callers with a security greater than or equal to 10 to access the questionnaire. SEC=10 would only allow callers with a security of 10 to access the questionnaire. (Any caller with Sysop security may access a questionnaire regardless of how SEC is defined.) ONETIME variable will only allow the caller to answer the questionnaire one time. If ONETIME does not appear, the questionnaire can be answered multiple times. PRINT will send the answers to the questionnaire to the printer. If PRINT is not included on the line, no attempt is made to send the questionnaire answers to the printer. An example of a Questionnaire might look like this: SPITFIRE Orders,SEC>=10,ONETIME Callers with a security of 10 or greater could respond to the questionnaire SPITFIRE Orders one time only. Their responses would not be sent to the printer. And so begins the metamorphis of what we will come to know as SPITFIRE V3.3 Enhancements Prior To September 5, 1992 --------------------------------------- NOISE FILTER ------------ A noise filter is included which prevents garbage characters from being accepted when a caller enters their name during the log on process. When any of these 'garbage characters' in the name, then SPITFIRE just asks for the name again. This is designed to prevent a new caller named l!Y\&1xzQj2,'54BUP18oT.DYAHYEa/#LR-<.7i~5U3M from logging on. JOKER.DAT CHANGE ---------------- A change has been made to JOKER.DAT. If any line in JOKER.DAT is preceded with @ followed by text, no one with that portion of the text in any part of their name will be allowed to log on to the BBS. This is primarily intended for profane words but for example I will use: @screw The above would deny access to the BBS by anyone with the name of Screw You, Screw It, Screw Up, Screw This Board, etc. This new feature is to be used with caution because it would be extremely easy to unintentionally deny someone access. For example, the above (@screw) would deny someone named Ben Thumbscrew access. NEW DISPLAY FILE ---------------- A new display file has been added, SFONFAIL.BBS/CLR. This is displayed when a caller logs on the BBS and fails to enter the correct password. An example of how this display file might be used would be to inform the caller that perhaps another caller by the same name is already a user of the BBS and that they might want to log on using a nickname or using their middle initial. ADDITIONAL BAUD RATES --------------------- SPITFIRE will now open the comm port at 115200 or 57600.