home
***
CD-ROM
|
disk
|
FTP
|
other
***
search
/
Monster Media 1993 #1
/
MONSTER.ISO
/
bbs
/
spitfire
/
whatsnew.33
< prev
Wrap
Text File
|
1993-05-16
|
48KB
|
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 "<P> 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 <U> Uploads SPITFIRE will then prompt:
<N>umber Of Files, <B>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 <P>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 "<P>......... 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,
<P>rinter, <Q>uit? ' otherwise it will display 'Print to <D>isk,
<Q>uit? '. When <P>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 "<P>.... 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 <U>...Upload Batch Queue was
changed to <B>...Begin File Transfer and the <D>...Download Batch
Queue was changed to <B>...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
<B> 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.