I've got GT 20 working properly over here on the telnet side, but am
using VADV-PHP as website interface, since GT doesn't have one at present...plus, I liked the way VADV-PHP looks. But, since its telnet
server kept crashing, I was glad to go back to GT.

I still have a couple of issues...one has been worked around, but the
other still hasn't been resolved.

1) I could not get GT to correctly process REP packets with the QK (GT
QWK Mail utility). However, since I had registered PDQWK long ago (not
sure if that is still registerable or not), I run it in "pre-pack mode" (because it otherwise exits, since it can't find "carrier" (dial-up), to
handle QWK Mail downloads and REP Packet uploads. So far, I'm the only
one on the BBS using it, but I can set up separate directories if other
users decide they want to use that option. The QWK Packet is sent to
their MB)Personal Mailbox, then they U)pload the REP packet to the
specified directory.

2) The problem that is NOT resolved is the way GT handles passing of the
data in GTUSER.BBS for each node. Obviously, with a single node system,
that's not an issue. But, if a user is already logged onto the BBS on
node 1, and a new user logs onto the BBS on node 2, the default user
name is the one on node 2. This causes PROBLEMS in 3 ways, because of
this "Default User" setup.

A) Entering a new message
B) Playing a doorgame
C) Uploading a file

In short, the WRONG USER information is sent, if the ORIGINAL user
tries one of the above options.

I have been "brainstorming", trying to figure out a batchfile routine
to do that, with each individual GTDOR###.BAT (door batchfile) in each
node directory, as well as a copy of DOORC (the door converter). From
what I understand, once the door data is written to a directory, the
door grabs that information, and doesn't need it again, unless the door
is opened by another user...although I have FLG statements set up for
doors that allow only one user at a time, where they're told "the door
is in use on another node, and to try again later".

Basically, the batchfile would copy the GTUSER.BBS from that node into
C:\GT (the GTPATH and LANPATH statement variable) when the user enters
the door, and then doing likewise when the door exits...and I would
think that would solve the problem. I would have to edit a whole slew of batchfiles with copy and paste statements, and while not difficult, it
would be tedious.

However, while I can write a batchfile for the BBS, my programming
ENDS at setting the clock on the microwave oven...if that happens, I may
starve to death. <G>

Unfortunately, the documentation for GT Power, on whatever version I
was running (since I ran it for 13 years under dial-up) was, in my
opinion, WOEFULLY INADEQUATE, on the explanation of how to set up a
multi-node GT Power system...although I understood the rest of the documentation fine. Even GT's original author, Paul Meiners, lamented
that "writing good documentation is the authors responsibility...but, I
write terrible documentation".

So far, in each node directory, I have:

1) GT.CNF - the configuration for GT Power

2) GT.EXE - GT Power 20

3) GT.KEY - the macro setup for GT

4) GT.WIN - the GUI help interface

5) GTDOOR.DAT - door information

6) NETFOSS.DLL - the data link library for NetFoss, which is also in C:\WINDOWS\SYSTEM32 -- I had similar problems with Virtual Advanced
(VADV32) if NETFOSS.DLL wasn't also in that directory, and if that
directory wasn't in the sytsem path...NetFoss would crash, and wouldn't
let any caller logon via telnet.


(Continued to next message)
---
* OLX 1.53 * 350 cubic inch V8?? That's one big can of vegetable juice

* PDQWK 2.53 #5
--- BgNet 1.0a12 - 035/005 The Thunderbolt BBS wx1der.dyndns.org Little Rock, AR