Saturday 14-Nov-92 20:43:21

--451--

NS> BA> Everything in SysText:* root dir, help/*, menu/*, and new/* subdirs
NS> BA> are all text files.
NS> BA> But all SysText:VDE/* files are data, not text.
NS> BA> SysData:VDE/* would have been a better place for them.

NS> I think you are getting a bit too nit-pickey here, Bill. Have you seen how
NS> many people were confused by the movement of the sys.passwords file? Many
NS> many! Anyways... by your logic, "SYSDATA:LOG/*" belongs in SYSTEXT: and so
NS> does BBSTEXT, BBSMENU, etc .....

I think I'm ALREADY far too nit-pickey.
Do you want it "OK", or "100% correct"?

I don't doubt users & things can get confusing, but which is really
causing it?
1)  ALL text files are in a text dir (or proper subdirs within it).
    ALL data files are in a data dir (or proper subdirs within it).
2)  We following #1, EXCEPT a few data files go in the text dirs instead.
    And a few text files go in the data dirs.
I think #2 *is* causing the confusion.

>many people were confused by the movement of ...
I guess the real question is why weren't things placed in the proper
dirs from day #1 or AS THEY WERE ADDED TO CNET?  No 'movement' would
have ever been necessary.

If you don't do it complete now (and continuous as things grow) Ken
will just have ANOTHER big 'file movement' 1-2 years down the road.
(And every 1-2 years after that.)

--452--
All of my future responses pertain to v2.41 or better...

Any DOS file executed online in shell or pfile that contains
code like:
> fprintf(stderr, "\nTo stderr\n");
Is never displayed.

(This can be some pretty important error-text, at times.)

Can Cnet be made to pipe all stderr to stdout?
(Can I assume it is currently going to "nil:" instead?)

--453--
Are there lines in BBStext that get displayed if any of the
6 setpass-passwords fail?  Failed attempts (especially new-user
passwords) just loop right back to log-in without any info.
I'd like to explain policy, etc.

Also, we could drop arexx scripts inside these strings to trigger
certain alarms, logs, doors, drop-carrier, etc.

--454--
v2.41 events...
>      all    1     all    1   -oa    0 pfiles:bbs/amaint
>      all 2250     all 2250     -   15 0
>      all  715     all  715     -   15 1
>    25-12    1   26-12    1     -    5 1
>      all    3     all    5   -ha    3 Cnet:s/HouseKeeping
>                                    ^^
Ken, any reason to switch from verbose CMD strings to #s?
It's all point/click/no-typing in CONFIG, either way.
Just more readable when looking at the text file itself.
Heck, even the -o/h/a options could be verbose strings.

>      all    1     all    1   CLEAR_LINE  NO_ANS  RUNC    pfiles:bbs/amaint
>      all 2250     all 2250   NO_OPT      ANS     SYSOPIN 0
>      all  715     all  715   NO_OPT      ANS     SYSOPIN 1
>    25-12    1   26-12    1   NO_OPT      ANS     CHARGE  1
>      all    3     all    5   AFTER_CALL  NO_ANS  DOS_CMD Cnet:s/HouseKeep

--455--
Is there anyway to make answering the any/all new-user questions (nq/
sq) 'mandatory' instead of its current 'all optional'?  (What's the
point if any user can just skip them all anyway?)

Maybe have the 1st line of each question-file reserved for the min-max
allowed length of the user's response and # of tries.

NQ> 5-10 7  (User must enter 5-10 char reply.  And gets 7 tries to do so.)
NQ> /q1 What type of computer equipment do you use? /c7

Kills 5 birds with 1 stone.
1)  Allows optional-responses.  (0-80)
2)  Allows mandatory-responses. (5-80)
3)  Allows sysop to limit lenghty answers. (0-10)
4)  Allows sysops to prevent short 1-word answers. (60-200)
5)  User's only get x chances (instead of infinite) to answer correctly.
    If you can't figure out your own address in 10 tries, Cnet should
    drop carrier, and let in the 100 other people that might be trying
    to call.

In fact, all questions could be in 2 big files (nq and sq) instead
of loading/displaying a dozen (or more) little ones.
> 5-10 4
> /q1 What type of computer equipment do you use? /c7
> 40-200 7
> /q1 What are some of your other interests? /c7
> 0-60 3
> /q1 How did you find out about our system? /c7

Maybe Ken will add an arexx cmd that will allow us to have our own
unlimited addition # of custom Q&A files, too.

AREXX> 'Questions' sysText:new/myQ
All answers would automatically be stored in their matching
"Mail:users/#/_plan_myQ" files.

--456--
I'll continue my list of ideas/comments about Cnet (v2.41 or better) here.

Thought #456...

> Item is no longer on-line.
Would anyone like an option in amaint that would/wouldn't purge msgs
that had been carbon-copied and not read by the receiver yet?
Avoid that "you *HAD* 7 msgs, but they've all been deleted".
(You wouldn't have to use this feature if you didn't want to.)

--457--

It is, of course, up to Ken, on whether or not to code an internal/
external or no front door at all.  I wonder how much of the existing
Cnet code could already be used.  He's already written the answer-
calls, hangup-calls, all the serial I/O routines, all the Fido
parameters Cnet already has, network variables, etc, as part of Cnet.
I don't see what more needs to be added other than the support for the
actual fidonet handshaking.  Zmodem and other protocals are already in
place.  Import/export to/from Cnet/Fido msg format.

When Ken himself sees what a pain it is to pay, wait 6 weeks to
register a 3rd party program, set-up tons of screens, read 100 pages
of docs, etc...  Then he'll see why Cnet needs it's own custom front
door.  One that's NOT as large and complex as some entire BBSes
themselves.  One that does NOT have FAX support.  Nor full point
support, nor 15 support executables, nor full arexx support, nor
105,000 byte executables, nor loading/unloading itself for EVERY call
received (Fidonet or not), nor loading/unloading Cnet for EVERY call
received (Fidonet or not), nor generic all-BBS support (Ken's could be
very Cnet-specific, supporting its massive features), and on and on.

Cnet just needs to get/make calls, send/receive mail packets.
If you want the other goodies, use a 3rd party prg.
Cnet will then be able to call itself, true, Fidonet
capable, right out of the box.

Paragon/Starnet/MEbbs/Xenolink and other much less BBSes all
have there own front doors.  SysOps currently running those
would flock to Cnet then.

I don't see this as "duplicating efforts" or "re-inventing the wheel".
Anymore than it is to say, "MANY of the features of other BBSes are
also in Cnet.  Therefore, Ken 're-invented the wheel' and 'duplicated
his efforts' there too."

I guess what it all comes down to is this:
Will adding a frontdoor to Cnet take time away from Ken's improvment
of Cnet.  I'm saying, "Writing a frontdoor *IS* improving Cnet, and
in a big, big way."

--458--
 S> After all, that is the ONE and ONLY advantage that DLG has over CNET; it
 S> is completely modular and operates simular to DOS. Everything is a program
 S> that is loaded only when needed.
 I wouldn't want to see Cnet divided up into *20-40* executables.
 But maybe 5 major blocks:
 1)  Vote
 2)  BBSLIST
 3)  Base/UDbase
 4)  G/N/Pfile
 5)  ET/EP/EA/etc
 Then all the rest in 'bbs'.

 But remember, users are going to have to wait for each of these to
 load/unload.  And if you are going to make them all resident anyway, then
 what's the difference if you just make the current 1-piece 'bbs'
 resident instead?
 (And I can't imagine #1-5 really making 'bbs' that much smaller.)
 And if they contain common code that could be shared between them,
 you're actually 'wasting' memory instead of saving it.

--459--
AD> Speaking of UUCP, what is ken planning with that Bill?
 I have no idea.
 I love UUCP.  And consider it a necessary part of any top-notch BBS.
 And I hear its front-door is even simpler to write than a fidonet 1.
 Excelsor already has it built-in.

 I wonder where Fidonet/Usenet would be today if a little more
 foresight was used since day 1.  Have it set-up where NO special
 handshaking protocol is even needed.

 To exchange mail packets, just have 1 BBS call another, and enter
 its phone # (no nodelists needed) at the 'name' prompt.  And a
 pre-arranged password at the 'password' prompt.  Those accounts
 would have flags set as 'machine' instead of 'human caller'.  And
 would just start a simple auto-start zmodem file transfer.

 Nearly every term and bbs has a 'name prompt' and 'password
 prompt' (I should hope), and 'zmodem', too.

--460--
1) Point systems.
2) Offline readers.
I've never used or supported either (yet).
Is (or has) #1 being pushed out by #2?
Do they both accomplish similar tasks by different means.
Which would you prefer (as SysOp and/or caller's viewpoint), and why?

--461--

 J> I have some users gets upset when the messages in editor was lost due
 J> to idle timer expire
 Does the idle timer expire while you are in the msg editor?
 I thought it was 'on hold'.

 I had always hoped Cnet would just give the user x more mins if
 his time runs out while in the msg edit, NOT infinite time.
 (Now I'm not even sure which 1 it's doing:
 1)  infinite time
 2)  x more mins
 3)  times out and drops carrier.

 I see the probably.
 I'm confusing 'idle-out timer' with 'out of time' timer.
 NOT the same.

 But I too call several giant UNIX BBSes and I too would like a
 lengthy post 'saved' instead of 'lost' for whatever reasons.
 (Although the UNIX standard 'userdir/dead.letter' name would be
 more accurately served as 'userdir/oldBuffer.txt' or something.)

 Maybe automatically delete it after the user calls 1-2 more times
 and doesn't do anything with it.

--462--
I hope Ken goes Fidonet (for obvious reasons/benefits).
I hope he runs TrapDoor.
I hope he does NOT have someone send him a pre-setup ready-to-run
config.
I hope HE has to go through everything step-by-step like every one
else does.
Then he'll see what I mean.
(I imagine he'd start work on Cnet's custom frontdoor ASAP.)

Trapdoor is a bear to wrestle with.
And I've set-up (as well as coded myself) countless program's
config files since buying my 1st Amiga in Aug 1985.

--463--
DS> The Event scedular could be improved a LOT.  I love TPTCron and the
DS> flexability you can have.
Last time I played with TPTCron was ages ago.  (A very old release.)
I thought Cnet's scheduler had it beat by miles.

List a few things TPTCron does that Cnet can't.

--464--
I haven't noticed that.  I'll have to check it out.
(Ken, while you are in that part of the code, could you squeeze Cnet's
version # into the title bars some place?  For users that mess up
the installation of an update and don't even notice they are trying
to run old/conflicting releases.)
-thanks

--465--

 BA> You mean from the control panel?
 BA> Like hitting 0-9 would pull up those nodes.
 BA> SHIFT 0-9 would get 10-19.

> No. Using commodities calls, from anywhere in your system, typing ALT-1
> will bring up port 1 ... one does not necessarily have to click on the
> Control Panel --- power!

Now that Cnet is WB2.0 only, things like this (and much more) can
be worked on.

--466--
Is there currently (or 1 planned) a way to read a particular response
quickly/directly?  "r43.371" Read Item 43, jumping directly to
response #371.

--467--
BA> Maybe I'll start posting 3-5 things per response.

> Please! Last time I sent up a QWK packet (with 370+ responses to this
> particular thread) it took over 10 minutes (no joke) to process the packet.
> It would have been faster for me to upload capture-buffer. :)

What is causing this delay?  Cnet?  Your offline reading?
Isn't either one just jumping right to 'new responses only'?

--468--
Can VOTE be changed:
>Users voting:  24.1 %
into
>Users voting:  24.1% (234 users)

24% of a 2600 userbase, is quite different than 24% of a 350 userbase.

--469--
KK>         That's assuming that the BBS would even know who is the actual
KK>         person trying to hack your password...  Untrue.  I see no reason
KK>         why the BBS shouldn't send mail to the person saying what
KK>         passwords were being tried.  It would let them know if the
KK>         attempt was even close to being successful....
I too thought it was a great idea at first.
Then some one pointed out that user #111 might accidentally
enter #11 as his account #.  Then try to use his real password to
get in.  After it failed, he'd realize his mistake and enter his
correct acct #/password.  But now the REAL #111 would get mailed user's
#11 real password.  So I thought this feature wasn't a very good
idea.

But now, upon further investigation 2 things came up:
1)  User's logging in with an ID # (a correct 1 or incorrect 1) get
their name shown and have to answer Y/N as to whether or not that
is their acct.
2)  This password email would just say "these words were tried/failed".
But you wouldn't really know that (in our example) it was user #11
that had tried (and now you have his password).

But I guess:
1)  A confused user might not see #1.
2)  Someone really wanting to break into an acct could just try
the 'failed emailed password' on ALL accts until they got through.

I really don't see a need to EVER display anyone's password EVER
(failed or success) unless a user has sysop-powers.

KK>         why the BBS shouldn't send mail to the person saying what
KK>         passwords were being tried.  It would let them know if the
KK>         attempt was even close to being successful....
If I see "10 (or even 1-3) failed attempts", I'm changing my
password immediately.  Regardless of "are they close or not?".

My master.h imaginary perfect BBS even has a 'force password
change flag'.  You could even force a user to change his password
if x failed attempts are ever made.  (The sysop can use/skip this
configurable feature.)

--470--
DS> You going about this all wrong!  The GUI interface is ony improving CNet.
DS> Why not ask Ken to PLEASE convert the BBSConfig3 to a ASCII format.  It's
DS> not
DS> the GUI interface that's your complaint.  He did this with BBSEvent by
DS> popular demand.

I like this idea.
Edit config with:
1) Cnet's GUI offline locally.
2) Cnet's editor online locally.
3) Cnet's editor online remotely.
4) My favorite word processor offline locally.
Make everybody happy.

DS> The only thing when or if Ken does this is that if you edit the BBSConfig3
DS> files out of the Config program it will not use the new settings untill
DS> you
DS> reboot.  To bad CNet wasn't like TPTCron and detected changes in the
DS> config
DS> file then reloaded when it found a change.
How does TPTCron do this?  Re-checking the config file every x secs
24hrs/day?  I'd be against that.

Also, Cnet would be picking up your changes regardless of whether or
not you were ready for them yet.  (ie. Effecting user's currently
online, I just saved my 'work-in-progress' changes, etc.)

I'd be happy to write a pfile (if Ken will tell me how).  Executing
that pfile (from DOS or online, local or remote) would then activate
the new config changes.  (When *I* wanted them activated, not
automatically.)

--471--
HM>  Actually, if he's going to add it, I'd say go the whole hog and have it
HM> as a variable on each sub.  It need not be a "LONG", mind you, but maybe a
You'll have to sit here and toggle it on/off 1-by-1 for 200+ subs.
Do you really need to grant pre-transform-sizes for some subs
and post-transform-sizes for certain other subs?  I'd think a sysop
would either do 1 or the other globally.

HM> boolean (BOOL) variable, or even a BIT in a LONG that some other
HM> unnecessary long and int variables in the subboard structure could also be
HM> added to.  The subboards are taking up too much RAM now.  The structure
HM> size needs to be cut down somehow.  Going to the bit format on some of the
HM> variables would certainly save some memory.  Especially if you have 200+
HM> subboards!

200 subs, 32 flags each, 6400 bytes.  Could be 800 instead.
2500 users, 64 flags each, 160000 bytes.  Could be 20k instead.
Item header flags, event flags, config flags, room flags, port
flags, Vote flags, BBSLIST flags, g/p/nfile flags, it starts to
add up.

Use BITS instead of BYTES and save an instant 88% on flags used.
Memory and disk space, load/save times, multinets, multilines, etc.

If Ken is going to change them, I'd make each flag 2 bits.
Dual-state, tri-state, and it could even go quad-state without any
further expansion of the structures.  And still at a 75% savings.

"Quad-state" for those times when you need to do things like:
1)  Choice A
2)  Choice B
3)  Both
4)  Neither

--472--
HM> BA> Paragon/Starnet/MEbbs/Xenolink and other much less BBSes all
HM> BA> have there own front doors.  SysOps currently running those
HM> BA> would flock to Cnet then.

HM>  ...and from what I hear, Excelsior is starting to get into the Fido thing
HM> and their own built-in front-door..  Not that <<I>> need once since Crap
HM> (uhhh, TRAP) Door works great on my system.
This could be a big threat to Cnet.  Excelsior is by far the nearest
thing to Cnet in power.  Ray (or anyone) if you hear how long
it takes Excelsior's author it write a front door, I'd be interested
in knowing.  Doesn't he claim to have written the entire BBS in
under 6 months?

--473--
Cnet's own front door?  Or TrapDoor?
>1:AWESOME!                                :   143: 79.8 %
>2:I'd still run TrapDoor                  :    17:  9.4 %
It's not looking good for our hero, TD.

I'd gladly even pay additional $$$ for a Cnet front door.
Even if only 400 sysops paid $25 each, an extra $10,000.00 for
Ken, is nothing to sneeze at.

--474--
You mean each user's 'sysop comment'?
It's currently something like 33 char max.

What size would everyone find 'usable'?
I'd like about 80.
Make it too small and it's useless.
Make it too big and it wastes disk space.
200 chars each, for 2000 accounts, is 400,000 bytes.
(And that's even if you don't use 95% of them.)

S> Actually, the sysop should have the option to use the editor to make it as
S> detailed as they like. Saving it in a file call _comment in the users
S> directory.
I assume that's a proposal and not currently part of Cnet?

I think most of these sysop-comments will be short.
It would be a shame to have 500-1000 tiny little 40-80 byte _comment
files around.  Each one using 2 full blocks of diskspace regardless of
its size.  (1000-2000 blocks)

This can be done currently with a small arexx script.
Ask for the user's name (and change it into his ID #) and read/write
to mail:users/#/_comment files.  But when it's a part of cnet's
standard data structures it becomes a part of VDE, status window,
it could be put in the WHO line for sysops, etc.

And it's already part of cnet's standard data structures.
It's just kind of small/limiting at 33 chars.  (If that's what it is.)

--475--
DM> Ken, you know maybe they are right.. Maybe you should just drop any and
DM> all improvements to C-net
I don't see any of the 600+ Cnet Sysops making this suggestion.
(Other than 1.)

DM> Well let's see.. The authors of Trapdoor, just released an update to their
DM> program and it only took the two of them 1 year to get that update out the
DM> door..
If Excelsior's author has already started working on a frontdoor
(I have NO proof that he has), I bet it's done long before Nov 1993.

I sure wish Ken would join in on these discussions.  Who knows, maybe
he's saying "I'll never do a frontdoor, no matter what.  Ever."
Or maybe, "I'm interested."  Or maybe, "I've already started."
Or maybe, "I'm already 70% done."  Who knows.  I know he's 1 busy
young man, but how long does it take to type a 1-line statement?

Jim, have you heard anything?  I hate to be wasting everyone's time
if it's already been decided long ago, "I'll never do a frontdoor, no matter
what.  Ever."

--476--
DM> I find that most echo moderators, and sysops take care of the problem of
DM> over quoting rather quickly and rather efficiently.   I import close to
How is this done?  Monitoring it continually, manually?  Let the
BBS do the work.

Giving warning notices?  2nd and 3rd 'chances' to offending parties?
Dropping that user's Fidonet access?  Have the NEC warning YOU?  Have
the NEC drop your access to that echo?

Let the BBS do the work.
And no one will ever have to worry about it again.

--477--
Jim would it be possible to do 1 (or both):
 1)  Include a "dir opt a" with each update.
     (Or something showing where things belong.)
 2)  Use LHA's full-path option when packing the update to
     preserve file-paths.

 Pete, can you post a v2.42 Readme so we know what's going on?

--478--
> Voting (Topic#, L:ist, N:ew, Q:uit)  NEW
Great new feature, Ken!
No need to 1[RETURN] 2[RETURN] 3[RETURN] 4[RETURN] 5[RETURN]
6[RETURN]... ever again.

> You have already voted on all topics.
How about showing us all voting RESULTS, then.
Instead of 1[RETURN] 2[RETURN] 3[RETURN] 4[RETURN] 5[RETURN]
6[RETURN]...

--479--
Does anyone know how Excelsior BBS achieves things like:
> Our internal 'C' interface was designed as a standard, so the programs
> you write today, will be 100% compatible in the future, no matter how
> many changes the BBS goes through.
Sure would be nice to break as few pfiles as possible as Cnet expands.

--480--
RR> BA> List a few things TPTCron does that Cnet can't.
RR> Ok, how about crashmail?  You can't get cnet to call out any more often
RR> than
RR> once every hour without setting up hundreds of BBSEVENTs to run during the
RR> day (or at least you COULDN'T -- has this changed?)
I see.  Maybe we need each event to have a 'repeat mins' variable.
"Run this event during this time period and repeat it every x mins."
Would that work?

--481--
I had always hoped Ken would have added an extra cmd to the editor
that would allow us to re-answer all the expire/private/urgent/etc
flag questions.  Mainly to allow the original poster a '2nd chance'
at setting them without having to start the whole msg over again.

This would also solve your problem too.  If this 're-answer flags'
cmd could to used by anyone with sysop maint privs.
You'd just change 'expire days' to 'never' and your important mail
wouldn't be deleted.

--482--
For line # x, mine always seems to go to R:pportX.cap.

I'm not sure where Cnet is getting the "r:" path from.
I don't see it listed as configurable under CONFIG/PATHS.

And ALL capture text from ALL users on each line, all goes to the
same file.  Seems like we'd want user #47's capture file to go to a
separate 'mail:users/47/capture.txt' file instead.

After 20 different users call, the current R:pportX.cap file
is just useless.  You can't tell who did what.

--483--
JK>         Yeah, and also be able to edit the title and who you are sending
JK> it to, possibly.
Yes.  This proposed new editor cmd would just re-ask you ALL the
same questions that you were asked when you 1st [P]osted or [R]eplied.

In fact, I might use BBSTEXT to remove the asking of all (or
some) of those questions initially.  Just go with the defaults unless
the user hits the 're-edit flags' cmd once within the editor.

> Anonymous
> Private item
> Use alias
> Adress to
> Also attach a file to this msg
> Return a receipt if no reply
> Return original message also
> Urgent mail (shown at logon)
> Enter a subject for your message.
> # of days before auto-expiration

And as Cnet expands, users will have to wade through more and more
prompts just to even get to the editor.  (And removing these features from
Cnet is NEVER the solution.  Just 'move' them to a more convenient spot.

--484--
Or Ken could modify the KILL cmd slightly.
Instead of the current:
> KILL 23
> Are you sure [Yes]?
> Subtract credits [Yes]?
> Delete file also  [No]?
And currently, if you answer NO to #1, you don't even get asked
the remaining (sometimes desirable) questions.

It could be:
A> Remove post      [Yes]?
B> Delete file      [No]?
C> Subtract credits [Yes]?
And have *ALL 3* asked, regardless of your answers.

It would allow all 8 combos of remove/delete/subtract to be done.
1) Remove post, delete file, subtract credits.
2) Remove, don't delete, don't subtract.
3) Don't remove post, delete file, subtract credits.
4) Don't remove post, don't delete, don't subtract.
5) Don't remove post, don't delete, subtract credits.
6) Remove, delete, don't subtract.
7) Remove, don't delete, subtract.
8) Don't remove post, delete file, don't subtract.
(I think that lists them all.)

Your request for #3 or #8 would then be possible.
I often need #5 for 'semi-good' uploads.

This new feature really shouldn't add any real complexity/size
to the code.  All 3 questions (A-C) are already a part of Cnet.  It
would just be changing things to NOT skip 'B-C' based on your
Y/N answer to 'A', as it does now.

--485--
Which of these things do you think a great BBS should be able
to automatically do?
1)  Delete an item/file after x days passes without anyone D/Ling it.
2)  Delete an item/file after x days online.
3)  Delete an item/file after x days without anyone responding to it.
4)  A combination of 1-3.
5)  Don't remove item/file if someone has it marked for D/L.
6)  Don't remove item/file if someone has marked it for D/L in the
    last x days.
7)  Don't remove item/file if >x users have it marked for D/L.
8)  Delete this item/file after all users who currently have
    it marked for D/L,  have done so.
9)  A combination of #5-8.
10) Delete an item/file after it has been D/Led x times.
11) Do any of the above but just remove the item (not the attached file).
12) Do any of the above but just remove the file (not the attached item).
13) Should the U/Ler himself (with the proper access flags set) be able to
    set the above things?  Only at U/L time?  Re-edit them afterwards also?
    Or just the SysOp?  Or both?

So many BBS authors concentrate on supporting auto-delete features for
MESSAGE bases only, when so many of the same principles could be applied
to FILE bases, too.  (And with 100 msgs @ 2K each being 200K.  And
100 files @ 100K each being 10,000K, it's actually MORE important to
fully support these things in FILE bases.)

I am very glad Cnet handles most (but not all) of the above very well
for FILE bases as well as MESSAGE bases.

But "AT" definitely needs to allow MUCH more than the changing of
5 things regarding a file:
(Title, free, protected, no-responses, favorite).

Things like:
PostDate, Response-date, ByID, ToID, Size, Download-Count, UsedDate,
Partition, file-credits, byte-credits, file-ratio, byte-ratio,
Private, Killed, PleaseKill, Frozen, Validated, Finished, Described,
Transformed, MissingPost, MissingFile, Integrity, ByAccount, Expire-
Date, offline-flag, etc.

Preferably by a VDE editor method.  But even the ability to edit all
of the above AT ALL, would be beneficial.

--486--

SysText:Display.1 Display.2 Display.3 ... Display.nTH.
Txt displayed to callers on their nTH call to the system.

SysText:Mail.1 SysText:Mail.2 SysText:Mail.3 ... SysText:Mail.nTH.
Text is mailed to users on their nTH call.

You could tell new users about certain things on their 1-4th calls.
More experienced callers on their 5th-10th calls.
Display/mail congratulations to callers on their 100th calls, etc...

--487--
1)  Real name forced
2)  Real name optional
3)  Handle forced
4)  Handle optional
5)  Anonymous forced
6)  Anonymous optional
And just prompt the user once with something like:
> Post under your [R]ealname, [H]andle, [A]nonymous:
(Or whichever are allowed/disallowed.  And, of course, just hitting
RETURN would get you the sub-default.)

Don't bury the user in 3-6 'which name' prompts, and 1-5 additional
prompts, but still allow all the options.

--488--
> P# User Name            Logon  Spd From                       Where
> == ==================== ====== === ========================== ================
>  4 King Phillip          2:28a 144 San Pablo, CA          USA Downloading
>    (User is muffled)               Club CAL 7 lines 510-724-5755, 660 megs!!

Are the log-in times shown by WHO local to the BBS?
If so, port 4 has been online 6.5 hrs.
(Or is the modem hung?)

--489--
One thing that I always hoped Cnet's FINGER could do?  Namely, at the
"Respond or Pass " prompt have just a "FI" alone give you info on the
person that posted that current response.  (No need to scroll-back,
find, and enter his name.)

--490--
Ken, are you running SAS v6.0?  A v6.1 patch has been released for
public distribution.  100+ enhancements and bug fixes.  Even for
commonly used calls to the read(), scan(), fork(), open() families.
Some might be effecting the Cnet executable(s).  I'll U/L the patch if
I hear you need it.  (~376k)

--491--
Is there any README info on changes/fixes to v2.42b/c/d/e?
(The v2.42e README only goes to v2.42a.)

--492--
Ken, I love the new powerful "ANY" (xany2lha) possibilities for
transformation scripts.  Could something similar be done for "viewing
inside archives"?

If 1 of the designated file extensions isn't found, as define in
CONFIG, then the parameters for the ".ANY" extension definition would
be used instead.  User's could then [E]xamine any file online and 1 of
those PD file-type identifiers could be called to determine the file-
type and other info.

CFX by Bob Rye is my favorite.  It correctly IDs dozens of picture
formats, compression types, libs, devs, executables, handlers, fonts,
etc...

--493--
I would love it if the system could automatically generate email to
the U/Ler whenever I had to do certain file editing/moving:

> Regarding your U/L "FooFoo.LHA" on 13-Dec-92...
>
> File had to be renamed from "FooFoo.LHA" to "FooFooV1.4.ZOO".
> File had to be moved from base "#3 Graphics" to "#6 Sounds".
> Filenote was changed from:
>    "A really, really good program" to
>    "Plays MOD files v1.4 by John Doe 10Nov91"

This is basically what I mail users now, but I enter it all
by hand 100s of times.

Maybe a single global flag affecting all areas and all users:
>  Notify U/Ler after editing:  YES/NO

And the appropriate 4 lines in BBSTEXT:
> Regarding your U/L "%s" on %s...
> File had to be renamed from "%s" to "%s".
> File had to be moved from base "%s" to "%s".
> Filenote was changed from: /n1 "%s" to /n1 "%s".

It would save me TONS of work on a DAILY basis.  As well as notifing
U/Lers what I desire in filenotes, correct names, correct area
placement, etc.

--494--
> #include <stdio.h>
> main()
> {
>    getch();
> }

DOS cmds with this code has always locked-up Cnet when used online in
pfiles or called via MCI in text files.

Works fine from the CLI or via Cnet's online CLI shell, though.

These are just standard calls to SAS's v6.0 getch() function, so
I don't know where the problem lies.

If you try to run any DOS doors or cmds that get hotkeyed responses
from the user, be ready for a lockup.

I sure hope Ken gets this working.  Cnet is just too powerful to
say "you can never run anything that uses hotkeyed getch() calls".

--495--

Ken> Cnet ghosts the term's U/L D/L menus if for some reason the
Ken> OpenLibrary( "asl.library" ) fails.

Does Cnet also display the correct "Can't open libs:asl.library" msg?
This is per CBM themselves.

User's would never sit around wondering what has happened.
They'd never need to call the support BBS long distance and post msgs
and wait for responses.

--496--
I assume when CONFIG'ing the LOG that "NetVote" should be reading "NewVote"?

--497--
No mention in the v2.42e README about anything being changed in
regards to Cnet opening a PUBLICSCREEN.  But I now see, for the first
time, PSX IS reporting Cnet is running as CNETSCREEN0.

>NEWSHELL "CON:0/0/600/60/WindowName/CLOSE/SCREENCNETSCREEN0"
STILL doesn't work.

I can open other CLIs on other publicscreen with that same NEWSHELL cmd.
Anyone get it working?

--498--
> EP;15
> Use the character ` to represent a "RETURN" or ENTER.
> 1) Logon MACRO : WHO`

During log-in will get you:
> Unknown command "WHO`" ... enter ? for a list of commands.

1) Cnet should strip "`" or truly use it as RETURN.
2) "enter ? for a list of commands." should read
   "Error in your log-in macro" so user's can find their error quickly.

--499--
> What exactly is the "Use previous term parameters" for?
I'd love to see how many callers answer YES instead of NO at this prompt.
I'd guess it's 95%.
Is it really worth asking EVERY user on EVERY call on EVERY CnetBBS
this question then?  (It was 1 of the 1st things I removed from BBSTEXT.)

Now, if I could just remove that:
"Terminal A=ANSI, C=CBM, I=IBM, S=Sky, [NONE]:" prompt, too.
You can't.
(Even if you are like MOST BBSes that don't have separate
ANSI, CBM, IBM, Sky menus anyway.)

Talk about non-configuratable.

-Bill "Mr. BBS" Beogelein, 313-473-2020, 2-line HST 14.4k USR DS, 1:2410/207


