| TIP: Click on subject to list as thread! | ANSI |
| echo: | |
|---|---|
| to: | |
| from: | |
| date: | |
| subject: | Beta 3/6 |
Telegard Bulletin Board Software, v3.03
Revision History Documentation
Copyright (C) 1997 by Tim Strike
All Rights Reserved.
3.03 Beta 3 - February 23, 1997
NOTES
I had intended on getting this beta to you late Friday, but
after spending much of the day in front of the computer, I just
couldn't finish the work I had started (and I wanted to finish
it before I sent you a version -- which worked -- but was not
at a level where I could afford to leave it for a few days and
remember where I was).
You see, the source code was a mess to begin with, and all the
new routines, the improved routines, etc. were in various
source files mixed in with the original 3.0 code, and the 2.98
series code, and even some of the 2.80 series of code where I
added JAM & Squish. Subsequently, I wanted to clean up *all*
the code, give function names common names (like chat_request,
or misc_lastcallers, etc). While doing that, I also wanted to
remove all the library cross-dependencies and layer the source
code such that each layer uses only those layers lower than it
-- this is a structured method to design, and once accomplished
does make things infinitely easier. I just didn't think it
would take *this* long. I've got a flow chart of what library
uses what other libraries, etc. and I've been layering from
that information that I've been gathering all day.
At any rate, Telegard is presently 48076 lines of source code
(C/C++, ASM and support utilities not included), spread over
74 source files. I managed to get through 51 of the source
files in a little over 10 hours (mind you, I was also adding
and optimizing much of the code I came across), and that is
the time I had alloted to do this *and* the rest of the changes
I promised (and need to complete) for this beta.
Needless to say, I'm exhausted. And since this really has no
use other than to delay my sleep (imagine that, procrastinating
from the very thing that I desire), and couple that with the
worst cross-dependancies still to come, the file & message
sections, I'm going to end this note here at 6am.
INSTALLATION NOTES
Please leave yourself an or two hour to complete the installation
and do minor tests. I suggest doing this upgrade at a time when
you'll be around to monitor your system (i.e. not before you head
off to work or go to bed) -- or in-at-least after several other
gungho sites have upgraded and say it's working okay, and even then
the changes for *your* particular system could be extensive.
This beta works here (as you can see since I've been using it to
post messages for 2 weeks now) -- HOWEVER -- this beta has *not*
been tested online, and the file section changes were *not* tested
either (I can't from here). Thus, while I have done as much alpha
testing as I possibly can at this stage, this beta still deserves
some special treatment in-that a lot of the stuff here is
experimental and a drastic change from what we're used to (this
beta is definately not PnP yet).
1. Make a backup of your data & language files (including *.MSI
and *.FSI files -- not neccessarily your entire message
section)
2. Read WHATSNEW.303 for beta-03 -- there are *many* important
changes, most notably:
i. DOOR.SYS file format was changed to represent the TRUE
format of the file. Your doors will not likely work
unless you edit your users' door records, or use the
OLDDOORS.SCR file. YOU HAVE BEEN WARNED!
ii. NEWUSERV, MSGREAD, WFCQFILE and WFCQMSG menus are all
in place -- make *sure* you install these menus on
your system! FILETAGP was *not* implemented (see
FILES section).
iii. Scan records have been changed to the new format
iv. File, message & menu systems all took some heavy
coding and need to be well tested!
v. Logging format was changed
3. Copy TELEGARD.EXE and TELEGARD.OVR over your current
executables (sorry there is no .DIF this week, but the DIFF
program blows up when there are too many changes--as in
this beta). Install __UPDATE.ZIP as usual. Update your
language files as usual.
4. Run UPDATE with the beta-02 as your option-this will update
your scan records (hopefully correctly), and adjust a few
other __NECESSARY__ datafields. The only potential
short coming is a byproduct of the all *.MSI/*.FSI storage
format--I've taken care to avoid problems, hopefully all
will work well.
NOTE: A disk cache will be helpful for this function. It
may take some time -- I can't even predict how long it will
take on any given system. On my system with 48 file areas
and 16 message areas (the test system), and 6 active users
it takes ~1 second. HOWEVER, the update must go through
every filebase and every message base once for every user.
So a disk cache will help tonnes . . .
5. Please report the space savings reported by UPDATE for both
your file section, and your message section.
6. Report any obscurities
7. If you have problems, restore your *.FSI/*.MSI files
and downgrade to 3.03.b2. Beta 3.03.b3 has substantial
changes, and while I've been running it on my local system
for almost 3 weeks now, there may be problems related to
things that I don't use, haven't tried, etc.
8. Remember to change your I##-#### ACS strings to I####, and
if you call doors by passing the USER-ID as an option,
you will need to pad the entry by using 00-~UU instead of
~UU (since the old doors will expect the leading 0's and -
which are no longer part of the userID). And no, they will
always be zeros, unless you have more than 1.6 million
users. See notes under OTHER.
TO BE DONE
1) MSGREAD and NEWUSERV menus 3.03.b03
Bonus: WFCQFILE & WFCQMSG
1a) FILETAGP menus Outstanding
2) New scan indexing 3.03.b03
2a) INDEX LIMITS RESIZE command Outstanding
3) File section update Started b01
4) Lightbar menus Outstanding
5) Script compiler Started b01
6) Script interpretter Outstanding
7) User-ID to 4 characters 3.03.b03
8) FrontDoor style logs 3.03.b03
9) Text fields to MM/DD/YYYY format Outstanding
10) Further multinode support (node-node chat?) Thinking
11) Language swapping (>64K languages) Thinking
PRIORITIES
2a) INDEX LIMITS RESIZE 3.03.b04
3) File section update 3.03.b04
1a) FILETAGP menu ?
5) Script compiler 3.03.b05
6) Script interpretter ?
4) Lightbars 3.03.b07
*) ...
LANGUAGES
+ MAKELANG upgraded to v1.15 - This version should report
duplicate text lines with both the text ID, and the first two
duplicate line #'s (if there are others, subsequent passes
will find them!). In addition, this version should report
the net space usage for the new language (i.e. does it take
up more or less space than the previous version -- and how
much!)
* See LANGUAGE.B03 for the language updates for Beta-03 (there
were lots corresponding to the new menus).
AREAS
+ The scan records are now stored in files FSCAN.DAT and
MSCAN.DAT instead of a separate file for each area. This
makes things infinitely faster in terms of file/message area
scanning (especially when many areas are not in the users
scan). It's also faster for toggling areas--and I think in
general the speed increase is a pleasant change.
The files should also be smaller than the *.FSI/*.MSI files
--instead of 3 bytes per area, per user, the algorithm now
looks something like
(round(msgareas/8) + round(fileareas/8)) * # users
plus whatever extra space you have (couple of bytes per
user), all stored in two files only. Imagine 50 file areas,
100 message areas and 300 users. The optimum space usage
under the old system compared with the new system is:
Message+File New
2048 BLK 204800 + 102400 ~10000
4096 BLK 409600 + 204800 ~10000
8192 BLK 819200 + 409600 ~16000
The new system has several disadvantages as well:
1) special routines to insert and delete from the users'
selection tables.
2) insert/delete/position can no longer be done with
other active nodes since the selection tables are
stored in memory instead of on disk for those nodes.
I have provided solutions that should work for 99.9% of the
systems and purposes with respect to these two issues.
1) my routines are in BITPLANE.PAS for modifying the
bitplanes. I haven't provided too much detail, if
you want help . . . ask.
2) see notes below
IMPORTANT NOTE (#1):
In order to ensure that nodes won't be actively reading and
misusings flags that aren't updated yet, I made it so that
the system recognizes the file TGLOCK.* in the /semaphore/
path as a lockout file. If node 1 created the lockout file,
it will be called TGLOCK.1, if node 2 created it, TGLOCK.2,
etc. If Telegard sees these lock files (either when
attempting to logon to the system, or when attempting to
enter the WFC quick-access menus), then access will be denied
and the message TGLOCK.TXT will be sent (note extension).
Telegard will delete lock files that are older than 4 hours
old -- thus, if a node for whatever reason does not remove
the lock file after it's done -- the system will detect that
after 4 hours and remove the file.
To either add (copy), delete or resposition file or message
areas the node will need to ensure the file TGLOCK.n exists.
If it does, then that node can modify the data files. If it
does not, and no other TGLOCK.* files exist, the lock file
can be created and the node can continue.
I'll put this bluntly. It is *not* elegant. Infact, it's
downright crude. But I *think* it'll work and avoid all of
the problems with this new scan format. If someone can think
of a better way of handling this, then by all means please
tell me. Other systems get around this by making the area
numbers static -- i.e. you can add areas to the end, or if
you delete an area, it stays there (you can replace it or
leave it 'deleted'). I like the simplicity of programming
that type of setup, I'm just not sure I like using it. So
please, if you have comments or suggestions, talk to me. I
don't know everything (although I admit to this being the one
problem that has held this release back--I've thought of many
things and many ways and this was the method that caused the
least problems thus far).
IMPORTANT NOTE (#2):
The UPDATE utility will give you up to 128 extra areas. If
you add that many areas in the next week or so, you will have
to wait until I can update the INDEX utility to include the
LIMITS RESIZE command, which I did not have the mind to
finish for this beta.
INFORMATION NOTE (#3):
I have decided to merge the QWK and online message area
selections for various reasons. While I realize this is not
ideal for some systems, it is ideal for most (since most use
QWK functions from TGWave, which is more functional than the
internal QWK (and faster!)--or don't use QWK at all).
*.FSI and *.MSI files can be removed once you are satisfied
with 3.03.b03 (they are in the backup you made--right?). I
don't **think** other utilities use this information
(Bluewave *might*, TGWave has an option not to-USE IT!)--if
other utilities need this information, just keep your old
*.?SI files kicking around (the information will not be
up-to-date, but I won't be writing a backwards conversion in
this case).
* Quick-access area switching now accepts a backspace to
correct any mistakes . See note below (i.e. it's all
common code now!) . . . okay, so this has nothing to do with
anything important, except that BEFORE I added the code
mentioned below, I did fix the original input prompts too. :(
+ Both the File & Message Quick-Access menus are now powered by
the menu kernel. Thus, the two new menus WFCQFILE and
WFCQMSG have been included. The menus work properly as they
are currently defined, and just use the commands which were
previously automatically called by the quick-access menus.
Other menu items & commands *might* work. The only reminder
is that commands which expect an online user fill find user
id #1 online (record 0). Since the default items on both
these menus were previously used, they are well tested--other
menu commands are not, and using them may or may not cause
system problems. You can call other menus from these menus,
but the same caveat remainds (I got lost in my main menu at
one point because there was no menu stack).
Play and enjoy -- hopefully that (a) makes things more
configurable, and (b) makes things easier on me. It
saved 3K+ of code overhead (woo-hoo). Anyone else notice the
.OVR has been slowly shrinking over the last few betas, even
though we've got more and more new features?
The menu command needed to quit these menus are any of the
hangup routines (although I'm *not* sure what else that will
cause on the system), or the new command -Z which is used to
quit from the WFC menus or to save the new user information
from the NEWUSERV menu (see later).
MESSAGES
+ Major modifications to the message areas. The changes were
to integrate the MSGREAD.MNU -- while it touches *none* of
the low-level code (i.e. message saving, message loading,
etc. is still the same), it does touch all the mid-level code
which is the reading & scanning code.
The MSGREAD.MNU has been fully integrated. It is called
wherever the old reading prompt would have been called. A
default menu has been included which closely mimics the
previous reading prompt. The commands for use on this menu
are the new R? series of commands--in addition, other menu
commands should be safe on this menu, but *please* be aware
that the more you imbed menus, the more potential problems
can occur. The only way to exit the menu is via the Ignore
Remaining or Quit commands, or by using Message Next passed
the last message. *HOWEVER*, with that said, please *safely*
experiment to your hearts desire, the new commands and the
MSGREAD menu provides a lot of power to your system.
PLEASE REPORT ANY AND ALL PROBLEMS AND ANOMOLIES YOU
ENCOUNTER!
Some side effects of all these changes:
(1) Title scanning is available in all reading modes,
including toUser/fromUser/personal/subject/text modes.
(2) Jumping around to non-scanned messages (i.e. those
which don't match the scan criteria) is now allowed in
all modes except waiting/emailscan.
(3) toUser and fromUser scans now also accept an optional
name to scan for -- (blank for users personal mail
will match either the users alias or realname). It
should be a helpful feature.
+ Message header editing was completed. It's available for all
Message SubOps or SysOps (depending on how you do the
access). NOTE: If the user does *not* meet SubOp or SysOp
access, the option will *not* come up even if the menu item
is selected (safety feature). The new option on the MSGREAD
menu is "*", and is powered by the R* menu command.
+ New toggle for message received status. The new option on
the MSGREAD menu is "$", and is powered by the R$ menu
command. NOTE: If you are the recipient of the message, the
bit will toggle OFF--however, if you re-read the message
(i.e. using "A"gain, or return to the message latter, the
received status will be set again). Once set, it is not
unset (except by this toggle).
+ New anonymous toggle: Realname or Handle, allowing the choice
at the time of posting for the user. NOTE: This method uses
the 'None' tracking mode so that ^aREALNAME and (an####) tags
are not created -- the Handle/Realname are both unique on the
originating system, and thus, it really *isn't* needed. This
toggle is even available on Netmail areas (where other
anonymous toggles are not permitted).
* Anonymous names should now work properly for Echomail &
Netmail areas (the items were previously not properly saved
for non-local areas).
* Repaired some JAM code which would sometimes lead to MBUTIL
reporting invalid JAM msg-id's (this resulted when changing
the size of the subfields, and improperly resaving the OLD
index--which while not used, would cause said warning).
* Copying/forwarding/moving a message should dynamically pack
the current area as well as the area the message was copied
to (for Squish areas only, obviously!).
* Forwarding a message should now check for write acs for the
particular message area the message is being forwarded to.
* Crossposting a message should now check for write acs for the
particular message area the message is being crossposted to.
* Forwarding/moving/copying will now (a) update the write logs,
(b) create the neccessary semaphores, and (c) write the
information to the SysOp logs.
* Deleting a message to a user will properly mark the userCRC
in the *.JDX files as zero -- this will effectively uncouple
the messages relation with the user (thus, things like the
MW;P or MW;L option will not count those deleted messages).
Undeleting a message will restore the userCRC field to the
CRC-32 of the lowercased destinee (which should restore the
original value).
NOTE: This is only useful if other JAM utilities do this --
it is how RemoteAccess handles deleting a message, so I
presume this is how it was meant to be (although, not
documented!).
* Fixed up file attaches such that the parameters passed to the
protocol use the proper format (no filename for batch
protocols, which is often why attaches via Zmodem, etc. would
report errors when used with DSZ/GSZ).
+ Message threading was added for reply chains. I don't
pretend to fully understand how the chains are linked for
messages from remote systems (some is done by MSGID, others
on subject, etc.) -- Telegard simply follows the Reply1st and
ReplyTo fields that any message has. The two new commands on
the MSGREAD menu are [,] and are powered by the menu commands
R[ and R].
[,] follow the chain -- the next regular message movement
(previous, next message, continuous, etc.) will start with
the message where you entered the thread. (i.e. reading 1648,
thread previous replies to 1245, then hit enter for next
message -- you will get 1649). The one exception is jumping
to a message #, in which case the threading is terminated and
you goto the message you requested.
* CTRL-P, T will now use /T: instead of the erroneous /C: as
the feature indicator in the line editor.
FILES
> I tried to code the FILETAGP menus, and ran into some
problems with both file tagging and file viewing, as well
as what to do while the menus are in progress -- i.e. reload
the FILETAGP menu *every* prompt (potentially slow) or just
use the menu in memory (potentially dangerous). Since many
of these problems are associated with the way I coded the
reentrant file_engine routines, I'm going to have to rethink
my strategy for this particular menu. I *think* the coding
changes I make to finish the file section changes will make
it easier to implement, and thus I've deferred the FILETAGP
menu implementation until I've completed those other changes.
* I recoded some of the core file section routines to improve
on overall system speed -- the following items have been
affected by these changes:
(1) All *.FA/*.FAD files are kept open while the user is
actively listing files. The files are only closed
when neccessary -- this reduces file open/close time
(which makes the system feel *real* sluggish). I
don't think it'll cause problems unless files are
deleted while the file is open -- to prevent this,
packing utilities must be able to open the file in
fmReadWrite+fmDenyAll mode -- if they can not (the
file is presently open), then the utility must wait
before deleting the file.
(2) Upload queues are no longer used. Uploading will
start the protocols immediately, after the upload,
the file_id.diz will be checked, and if missing a
description prompted for. No filenames or
descriptions will be entered before the transfer
starts. Bidirectional uploads use the file area
precedence of current -> UploadArea -> SysOpULArea
(latter both as setup in SystemConfig.FileSection).
The only exception to this rule is single file
transfer protocols, which require a filename before
transfer -- these will be input as required.
(3) Download queue was resized to 50 files. This should
be more adequate with today's transfer speeds (it's
2 1/2 times the previous limit).
Because of this recoding, I'm very interested in certain
things-- (a) is the file system noticably faster? (b) what
run-time errors are occuring -- and especially, are the file
tagging run-time errors still occuring? I was *never* able
to replicate these on my system!
* The validate files maintenance option is now powered by the
same update engine as most of the other maintenance items.
Please let me know of any problems.
* 'Next Area' should now work properly -- i.e. it will skip the
rest of the file being displayed and will avoid any further
pausing for the skipped area. The big problem was when the
'Pause After List' option was enabled (Next Area was not
cancelling this forced pausing prompt -- it does now!)
* Offline files will no longer receive a duplicate file tagging
number (offline files should receive NO file tagging number
at all).
* GraphicSpecification importation should now work again- when
I was optimizating a section of code, I accidentally caused
it to never run (some optimization technique!).
* Graphic Specification (GifSpec=NNNxNNN,NNNc,type) is now
represented as (xSpec=NNNxNNN,NNNc,type) instead.
DOORS
* The DOOR.SYS file (Menu DG) has been updated to reflect the
*correct* format of the DOOR.SYS file created by GAP. This
means that the REAL NAME of the user is *always* sent instead
of the realname/alias toggle we previously used, and in
addition, the handle is sent later in the DOOR.SYS file.
If you use doors which use the DOOR.SYS and also keep user
information, the new format will cause those doors not to
recognize the users as active players/etc. If this is the
case you have two options--update the 'player name' id
entries in your DOOR.SYS to use the real name instead of the
handle, or use the OLDDOORS.SCR file to create an old
DOOR.SYS compatible drop file. I honestly suggest a slow
progression to the new, and proper, drop file format.
SysOps who use R; (real name force) in their DOOR.SYS drop
file commands should have no problems--the file is of
compatible format.
* A proper DOORFILE.SCR was included which has the new REAL
NAME line for the DOORFILE.SR generation. This is used for
duplicate checking for the Solar Realm games, and certain
somebodies may not like if you put this new script in . . .
(infact, I'm honestly not sure what effect it will have).
OTHER
* Major overhaul to the internal menu routines -- this was done
not only for optimization purposes, but also to support the
many new & specialized menus that I'm going to be introducing
over the next little while -- the first of which is outlined
in the MESSAGES section, and the second is outlined below.
The main menu handler was *heavily* modified to make room for
these changes -- this is the core of the entire BBS, so test
it very well!!
Please let me know if you have problems with *any* of your
menus. If they're new problems that didn't previously exist,
send me the .MNU file so I can check it out . . .
+ The New User Information Verification code is now handled via
a menu called NEWUSERV.MNU. This menu just makes calls to
the OP menu commands to update the user information. A new
menu command, -Z, will exit from this menu loop, save the
user information and continue with the new user process (dupe
phone # checks, etc...). Several things should be noted:
* The OP menu commands operate in 'NewUser' mode -- i.e.
the same as the old methods. Thus, if you toggle items
ON/OFF via SystemConfig.NewUser, then those items will
work as expected (off, forced value, etc). This works
for all OP commands 1-25, & 80. Thus, if you disable
the date of birth field, even if you call OP 9 the
date of birth will not be prompted for.
* Menu changes, sub menus, etc. should work just *fine*.
Just remember that the user has *not* been saved yet,
and calls to other menu functions that expect the user
has been saved may, or may not, work. This is most esp.
true for door calls, file transfers, message reading,
etc. which expect the user is a valid, logged on user.
There is an alternative -- to automatically save the
user and assign a user-ID, and then load the menu.
However, if the user does an ALT-H at this point, their
account has already been saved, and they will avoid all
of the duplicate number checking, and the newuser
script. I did not take this alternative -- if people
have comments, suggestions, etc., please let me know!
* Hangup commands will function as normal (log the user
off) -- the records will *not* be saved. The only way
to exit this menu set, and save the user record is to
use the -Z command.
I have included the menu template NEWUSERV.MSG, which is
displayed by the ~menu~ instead of the generic menus. You
can use generic menus for this display, but the display file
provides easier manipulation of the fields.
While I don't insist you stick with the default NEWUSERV.MNU
that comes with Telegard, I do urge that you heavily test any
changes that you make.
* User-ID *text* was changed from ##-#### to #### format
(leaving off the leading two zero's since it is unlikely any
system will ever have more than 1.6 million users). The
userid is *still* a longint, and all your users *still* have
the same userid. The only thing that has changed is the way
that the numeric number is represented as text. Thus, things
to note:
(1) I##-#### ACS is now I#### -- change your menus
or the ACS will always fail (even for | (OR)
alternatives since the string is the wrong size).
(2) If you use doors that use the old ##-####, or
if you pass the MCI code to batch files for
semaphore files amung other things, you should put
a leading "00-" infront of the ~UU MCI code. This
will mean all your old doors will work. I suggest
switching semaphore files etc. to the newer format.
(3) Separate SysOp Logs are now SLOG####.LOG instead of
##-####.LOG as they were previously. This is
better I think (matches the CHAT#### and TRAP####
logs better too).
+ New menu command OK which adjusts user statistics; it is
a compound command, which handles the adjustment of:
Timebank, Netmail Debits, Netmail Credits, Filepoints and
online Time. See the MENUS.REF file for more information
on the command. Some examples:
+B25 ; adjust timebank by 25 minutes
-B5+T5 ; adjust timebank by -5 minutes, add
5 minutes to online time
+P250 ; adjust filepoints by +250
-P250 ; adjust filepoints by -250
=D0=C1000 ; set netmail debits to zero, set netmail
credits to 1000
+C500 ; adjust credits by +500
I guess this is also a good time to mention how Telegard
handles netmail crediting and debiting. Essentially a user
is given NN Netmail *Credits* to start off with. The user is
allowed to continue sending netmail until the users Netmail
*Debits* exceeds the NN Netmail Credits. At this point, you
can do one of two things -- Increase the available Netmail
Credits (and the user can use netmail until their debits >=
credits again), or you can set the Debits back to zero.
* Telegard allowed *OFF* in the extended menu filename to
disable extended menus (allowing only expert and normal).
Due to my oversight, the filename input routine would not
allow the * character -- even though *OFF* was expected.
The new designation is &OFF -- please update any menus you
may have had left over from previous versions of TG (which
could be used, but not changed).
* MCI codes are translated for file display (-F through -I)
commands. This is useful for displaying node dependent,
area dependent, etc. information.
+ Two new default menu handling help levels have been defined
for menu input. The help levels work as follows:
User Settings } Starts at Expert or Normal level
(depending on the user eXpert setting)
?:Help goes to the next level.
Forced Expert
Forced Normal } ?:Help does nothing, always forced
Forced Extended
Default Expert
Defaults Normal } Override user settings for this menu,
but still allow ?:Help to goto next
help level.
The help level progression is Expert -> Normal -> Extended.
Thus, with the forced levels, the user will always be at that
help level for that menu. With the default levels, the users
will act like their setting has been temporarily overridden,
but the ?:Help key still progresses to the next level.
NOTE: Default Normal with Extended Help = &OFF is like being
in Forced Normal mode (the user can't go to Expert, and can't
go to Extended either).
+ Frontdoor style logging was implemented -- it's a little
easier to read than a mismash of lines which were not always
aligned on the leftside. The logging also provides timing
critical information, and indicators of what was going on.
I tried to keep the same indicator for like-messages, but
since it's nearly 4:30a as I write this, I'm not sure that I
succesfully accomplished that task. Comments and suggestions
are, as usual, welcomed.
* The TRASHPHN.TXT file will now be used to deny BBS list
numbers as well. I thought of using a separate listing, but
if you don't want the numbers in your user list, you don't
want them in your BBS list, and vice versa.
* The TRASHPHN.TXT file which Telegard parsers to deny phone
numbers now accepts ? as well as * as wildcards. ? will
allow any character only in that position, while * indicates
the rest of the phone number. I.e. 111-* means deny anything
that starts with "111", while 1??-* means deny anything the
starts with "1". In the latter example, it is important to
note that 1* would not be appropriate, as this would cancel
international numbers, etc. Putting in at least one
formatting code is a good idea (in this case "-").
+ Added Duplicate Phone Number 'Email-To-SysOp' option. The
option SystemConfig.NewUser.DuplicatePhoneScan now has three
levels - No, Log Only, and Email SysOp. If the latter is
chosen, an email will be sent to the sysop with DUPTEL.TXT
as the header (from your default text path, NOT the language
text path) and a list of all the users (handle & realname)
which duplicate the new user's telephone numbers.
+ Added ACS XZ, which is TRUE for users w/ CoSysOp ACS and
FALSE otherwise (this was needed for the new MSGREAD menu!)
* Fixed up internode messages so that long messages with lots
of colour codes in the pre-text (1931/1932) are still sent
intact. Additionally, added support for {at}/$filename from
the 1931/1932 prompts (they are sent separately -- without
a CR -- that is the only thing to note).
* Fixed up some event code which would cause any of the
following symptoms:
(a) Slow event display at WFC screen
(b) System instability at WFC / logon process
(esp. under multitasking systems -- Jeff, this *could*
have been what caused your other windows to close down
when you shut down Telegard -- unlikely, but *could*)
(c) Nothing at all (it was erratic!)
* The vote mangling from deleted users was definately Telegard
-- although I don't quite understand why. The code was all
correct, so who knows. When Telegard deletes users, it no
longer touches the voting data. Since Telegard keeps a tally
with each question, the questions now have the effect of
keeping a running total (for active & deleted users) until
the next vote reset. I think this is appropriate anyway.
* Deleting a user will now only open the message base if it
is Squish format -- JAM does not need the lastread pointers
updated, so it's not done (and thus will be faster).
* Field input should not be so sluggish if not checking for
any pre-formatting (i.e. not formatting phone numbers, postal
codes, dates and times).
* IEMSI phone numbers should parse a little more cleanly (i.e.
(905) 820-7273 -> 905-820-7273
(905) 820 7273 -> 905-820-7273
905 820 7273 -> 905-820-7273 ...etc...)
~ I took a look at the IEMSI code in relation to carrier drops;
there is no easy way to get Telegard to recognize the dropped
carrier during the IEMSI sequence -- Telegard will timeout
after 15 or 20 seconds, and at that point Telegard will
check. Unfortunately, at this time that's the best the code
is going to get.
* Fixed a number of cosmetic errors (override delete,
colour for deletion prompts, too many nl before errors, etc).
Please let me know if you find/see other 'funny' things.
* File I/O routines trap RT 5 as a file-sharing error now as
well (instead of just 162). I also repaired some of the I/O
error handling -- file sharing/locking should be more
reliable. User side output will strip the file path (which
never should have been sent), and additional information is
now sent to the local screen only.
* Date input was using the time separator rather than the date
separator. Fixed.
3.03 Beta 2 - January 12, 1997
BUG REPORTS
* Have the RT 100/101 errors with the file section gone away?
Are there any lingering bugs in the file section that the
TELEGARD.DI2 did *not* fix?
* Message base code was not changed in b01--if there are bugs
in these areas, it is possible they are co-incidental. If
they continue with b02, please let me know.
* I have received your other bug reports (I had to borrow a
modem since BOTH my modems here (14.4 HST & 14.4 V32) have
died on me. I will only be calling in once a week
unfortunately . . . till I can get them somewhat repaired.
At any rate, the bugs that I have fixed are the ones I had
before last weekend--otherwise I just got the rest now, and
since it's important to me to update the betas on a weekly
schedule here on in, you get a working version--with only
a handful of the more recent bug reports fixed.
AREAS
+ Quick Message & Area prompts now accept numeric entries for
quick area changes (typing a valid area number will switch
immediately to that area). The QWK access commands from
the Quick Message Menu, formerly options 1,2 & 3, were
updated respectively to D,U & T.
MESSAGES
* Message start number input will accept up to 999,999 as the
valid input now. If you have more messages than this--TOUGH!
(renumber them! . . . I thought 32,000 was enough ).
* Squish areas should not skip the 'next' message when posting
a message forces dynamic packing--I thought this would be an
elaborate fix which is why it wasn't done for 3.01/3.02--
However, it appears I outsmarted myself and added the code
when I first added Squish--I just used the wrong variable
name when I later called the MsgSave() routine! Fixed.
* Version 7 nodelist searching has been completed. Version 7
nodelist browsing has not been completed yet (it will have
to wait until after the other features are finished).
* New message areas now use the default address properly--
Echomail & Newsgroup toggles were previous changing the
default address to the first address. Netmail & Internet
Email bases will continue to switch to AKA matching for
intuitive reasons.
* SysOp logs contain the From: name for posted messages if the
base allows anonymous types (even if the message is not
anonymous). This is for tracking purposes.
+ Local messages now also get MSGID fields (using default
netmail address (address 1)). These can be used for reply
linking in local areas.
+ Added extra MCI codes for lines 1119 and 1120 (see
LANGUAGE.B02 for the information). Version 7 nodelists use
uppercase only--if you use Version 7, and want proper cased
entries, you'll have to use the ~En formatting codes.
FILES
* New prompt for file group change (so that the main group
is not listed ). Otherwise command OQ works (if you
have file groups defined AND have moved the new MENUS.DAT
from the beta1 __UPDATE.ZIP file to /data/--remember that!).
* File Passwords will not be prompted if the user has failed
any of the download ACS criteria. The file password will
still be prompted for valid ACS users, before time & byte
checks are done. Reported by Wes Spadola.
* Description importing will remove empty (or blanked) trailing
lines from the descriptions.
+ Added secondary sort option (for options other than Filename
sort--which allows only one file of identical name in any
given area anyways)--the secondary sort is used when the
primary sort criteria for two files is equal (i.e. upload
dates are the same, then sort by filename).
+ Added configurable sort criteria--defined for each file area--
used for area sorting (unless overridden with a different
sort criteria). This adds much more flexibility to the
internal TG file databases (honest). Check the settings for
your file areas--the values should be 'None' to start off
with, but it depends on how other utilities handle the 'null
space' in the Telegard records.
+ Added command line file sorting. The command line is -FS
and it invokes a global sort based on the sort criteria for
each area (i.e. you can not select the criteria). Areas with
out a primary criteria are not sorted.
+ Option to remove high-bit from imported descriptions (toggle
from Systemconfig.Filesystem.(H)8-bit_FILE_ID).
OTHER
* Menu command NW will no longer run on single node systems
(no errors this way either).
* Fixed internal YY/MM/DD conversion problem that WOULD under
certain circumstances crash the system (reseting last
read pointers with this date format, for instance).
* Fixed OP53 toggle (it would increment well past the limit
of 3 date fields--creating unknown formats for the dates
(Telegard would at least translate to MM/DD/YY in this case)).
* Fixed AM/PM bug (the correct order of your language lines,
just in case you changed them for Beta-2 is:)
078 am
079 pm
080 a
081 p
* Date separator will now be used for all date input and
other date fields displays (date format for instance).
DEVELOPERS NOTE: All internal date fields (string) use
'/' as the separator, and MM/DD/YY as the format.
* The time separator will now be used throughout the system
(only the date separator was previously used in beta-01).
Of note, the time & date separators (and the thousands
and decimals separators) are single characters only (i.e.
NO COLOUR CODES--SORRY!).
* Fixed Dx ACS parsing (should now work).
3.03 Beta 1 - January 4, 1997
Release Notes:
This is the first beta that some of the newer sites have received.
My sincere apologies for taking so long to release a beta following
the 3.02 release, but there are honestly two reasons for not doing
so--
1. School caught up to me bigtime in September, and took
most of my free time for various projects. For those
who want to be 'in the know', I'm a third year CS/Math
major (I've also finished a year of Commerce, and a year
of Elec. Eng.). I intend on graduating a 1/2 year early
from my program.
2. I was near burnt out. After finishing 3.00 of Telegard,
including all four gamma releases in a little less than
a year of really concentrated work, I just had no more
juice -- especially in the summer when I was working
50+ hour weeks.
That said . . . I think I'm rejuvenated, in at least enough to get
some work done . . .
This release marks the new file section. I honestly admit that
it has not been as well tested as it should be, but that is what
you folks are for. The file section lists files, and it adds files
without a problem. What else works, what else doesn't? Test it
heavily--although I suspect your users will do so as well.
Keep a backup of your 3.02 system (you can revert if you have
too many problems).
The file structures have been included for this 3.03 release.
Please note that these structures are *not* final, but should be
enough for everyone to work with for now--especially those amungst
us who wish to update their utilities for the new file section .
OF NOTE: The new scan records have not been implemented yet--they
will be shortly (and I'll include sample code on how to access
the scan records, for both the file & message areas).
Installation Notes:
As with previous beta distributions, this package is based on the
3.02 public release-- you must have 3.02 installed in order to
patch your files.
As always, keep a backup of your previous installation!
For old sites, it works as normal. For new sites, it works as
follows-- The TELEGARD.DIF file is applied with the command
BUPDATE -i TELEGARD.DIF
while in your /telegard/ main directory. The __UPDATE.ZIP file
contains updated files (text/language/etc) that were changed since
the previous version (as samples), update your own files as
neccessary.
Data structure updates are completed with UPDATE.EXE utility.
Language updates are kept in LANGUAGE.B01 as normal, listed with
changes in reverse chronilogical order (latest=first).
Release Notes:
LANGUAGES
* Review LANGUAGE.B01 for the minor changes to this version.
AREAS
+ A second group set has been added (so you can now keep your
file/msg groups separate if you so desire). The group sets are
now governed as follows:
Set 1 - Main Groups Set 2 - File Groups
File GROUPx File FGROUPx
MCI ~CC (desc), MCI ~CH (desc),
~CG (tag) ~CK (tag)
ACS Cx ACS Dx
Change OR Change OQ
Setup *G Setup *G
Note that some utilities will produce FALSE if you use the
Dx ACS--so separate your groups only if your utilities will
still work. The naming convention Msg/File is completely
ambiguous (Telegard does *not* care what you limit in each
group--internally they are Set 1 and Set 2--the naming
convention is just for convenience!).
** Your old group configuration will work without change **
MESSAGES
+ Added toggle for appending "Re:" to the reply subjects.
* Squish bases with unlimited messages were marked with max
messages == 65535 rather than the Squish standard == 0.
* Processing messages > 32K should _not_ have worked because of
some filtering variables if either mbfilter or mbstripcolour
was turned on. It did infact work on occasion, but it
shouldn't have. Fixed--hopefully this fixes importation of
large files (.ANS/etc) over 32K.
+ Anonymous messages have a new tracking mode. Previously,
all 'anonymous' message types were posted with a ^aREALNAME
kludge (even in echomail areas). However, three new tracking
methods are now available-- Name, UserID, and None. The three
modes operate as follows:
Storage of Export
From field Original User Name Restore
Name Anonymous types ^aREALNAME kludge YES*1 YES
UserID Anonymous types #### in from NO*2 NO*3
+ (an####) field is userID
None Anonymous types NONE*4 NO NO
*1: The ^aREALNAME kludge is exported. Ideally, other
systems will not show kludge lines to general users,
but this is not always the case.
*2: UserID is exported, which is unique to the local system,
and only visible by the current user (from info
screens) or from the user editor (SysOps/etc).
If you have utilities which print the private
UserID of a user for public consumption, this
method is not anonymous either!
*3: Since UserID's can change (user is deleted, new user
logs on), the original name of the poster will not
be restored.
*4: Logs will contain message posting information; which is
only available for as long as the logs are kept.
FILES
+ New file section--the description files are now 'flat access'
which means that to get the file description, you seek to the
description offset, read the description ID (should be the
matching filename--13 bytes in length), then the description
of fbrec.desclength size. No more pointers to maintain
besides the offset = easier to use/maintain file section.
The new structure use NEW files (i.e. utilities which use
the old filenames will not load the new structure and crash).
External utilities have been included for support with other
utilities which make use of the old structures.
For utilities which only _read_ the file areas (file listers,
etc.) or utilities which update things which may not be too
important during this beta stage (download counters, whatever):
FA2FB /* generates old files from current
structure files */
...utilities here...
For utilities which update the file areas:
FA2FB /* generate old files... */
...utilities here...
FB2FA /* convert old files back to new
FA files */
I have included several switches with the utilities so that
you can obtain optimum performance with these conversions:
-NOCD /* do not process CD-ROM areas */
-DATE /* only process if dates on files are
different */
Assuming that the utilities, when they change the file, also
change the files date, the -DATE option will ensure that you
only update files which have _indeed_ been changed (which will
save going through all your file areas = faster update). In
addition, since utilities like ALLFIX do not update CD-ROM
areas, the -NOCD switch does not process those areas either.
The new files are slightly smaller than the previous files; it
is more noticable on the first coversion because the file
descriptions are packed and wasted space is removed--thus, the
following results were obtained:
Old files (w/wasted space) 810,843
Old files (w/o wasted space) 309,950
New files (w/o wasted space) 226,462
The new files are easier to pack and remove the wasted space,
so I'll write a packer shortly (actually, I'll build it into
the INDEX utility).
* The search engine for the file section has been updated to
reflect the new structure--it's using the QuickSearch now
instead of the much slower POS(), and was noticably faster
on my machine (perhaps not on yours . . . )
* FILES.1 file listing & description file (for downloads) was
missing the second line of the description. Fixed.
+ Preliminary support for PNG (Portable Network Graphics) format
added.
* Uploader names > 36 characters were truncated to 20 characters
during editing; names longer than 20 characters after input
would crash the system. Fixed.
OTHER
* Original bet will be adjusted if maximum bet < 5.
+ If deleting a protected user and the online user has SysOp
ACS, an override protection prompt is now used.
--- Fringe BBS
* Origin: The Fringe BBS - Only the best >TG< - 904-733-1721 (1:112/91)SEEN-BY: 633/267 270 5030/786 @PATH: 112/91 123/500 379/1 633/267 |
|
| SOURCE: echomail via fidonet.ozzmosis.com | |
Email questions or comments to sysop@ipingthereforeiam.com
All parts of this website painstakingly hand-crafted in the U.S.A.!
IPTIA BBS/MUD/Terminal/Game Server List, © 2025 IPTIA Consulting™.