
Sunday 20-Dec-92 21:07:25

--500--
While in the editor, when looking for quote-text, a FIND cmd, would
sure make things simplier/quicker.  (Especially in long 100 line msgs.)

> Find#-#, List#-#, Add#-#, Step#-#, Resp#, Quit:

(Ken could most likely use the same FIND function-call used by
the editor itself, just search the quote-buffer instead of the
text-buffer.)

Also, anyway to make "Add#-#," the same as "#-#"?
(ie: "A4" or just "4" would grab a quote from line #4.)
("ADD" is probably the most used cmd here and would be the default, working
with or without the preceding "A".)

--501--
Are there places in BBSTEXT were I can set-up default ctrl-macros
(^E ^F ^G) for all new users?  (Or can this be added?)

(And more than the current 3 macros would sure come in handy at times.)

--502--
1> Delete pfile also [No]?
2> Delete pfile "cnet:pfile/myDir/foo" also [No]?

If you are about to permanently, irreversibly delete 1 or more of your
pfiles, #2 would be a better choice.  (The system knows which file it
is about to delete, it just doesn't tell you.)

--503--
> List#-#, Add#-#, Step#-#, Resp#, Quit:
[S]tep is a very handy way of quoting.  But I'd like to
see it continue where it left off.  You could "walk-through" a
quoted-rely very simply.

You could then "S"tep and "Y"es from quote lines 1-5.
Exit and reply to them.
Then "S" again would automatically restart at line #6.
You could continue like this throughout the msg.
A lone "S" would continue each STEP where you left off last time.
(Of course, you could still "S#" to restart at a specific #, as you can now.)

Currently your 2nd (and future) STEPs always start back at line #1.
You have to remember (or write down) the exact line # you were at
before and then re-enter it each time you STEP.  (S34)

"S S S S S S" is a lot easier to remember/type than "S2 S7 S16 S24 S33 S45".

--504--
I had always hoped that callers with SysOp Maintenance powers
could set a flag for each vote topic:
> Show as NEW? (Yes):

I'd be more than happy to allow anyone to post vote topics
if ALL users, on EVERY call didn't have to get through:
> "You have not voted on 41 Vote topic(s).  Vote now [Yes]?"
(and continue to do so on EVERY call until they
1) Read
2) Vote on
3) And see results
of all 41.)

(and I certainly don't want to remove it entirely as a "solution".)

Or maybe, in keeping with p/n/gfiles, just a simple:
>Days +/- offset to set date   :
If you set the date offset to -999, it wouldn't come up as "new".

--505--
Sure would be handy to [L]ist [J]oined (LJ) users of the current sub.
(For both 'invited-only' and 'open' subs.)

--506--
I had always hoped that the string:
> System event imminent; try again in 10 minutes.
would be:
> System event in %d minutes.  Continue (No) /?0
for 2 reasons.

1)  The actually time is more informative than the word "imminent".
(What if I just need to check something for 15 secs?)
I have no idea what the BBS's definition of "imminent" is.
Within 5 mins?  10?  1?

2)  Let's the user decide whether or not to try anyway.
(The system will still cut him off, as always, when the time comes.)

--507--
Main> MUffle  : Stop OLM's from coming from another port.
Conf> /MUffle : Muffle another user (stop their OLMs).

1) I thought typing "MUFFLE" at the main prompt, would stop OLMs.
2) And "/MUFFLE" while in [J]oin-conference would muffle them only there.
(Working independantly.)

(Actually both "muffles" only state they stop OLMs, nothing else.)

Apparently, #1 stops all of #2 also.

OLM's can be a pain, but when I joined the conference I didn't
understand why I wasn't seeing any responses from anyone (not even
my own).

Like me, would anyone else want #1-2 to work independant of each other?
Allow/prevent OLM independantly from stopping/allowing text in JOINCONF.
(They are vastly different.  Excessive OLM's can be bothersome, but
when I specifically enter the conf only to NOT see anyone's text....)

--508--
> You don't have upload access here.
Is there a way to tell a caller which area to move to (and how) where
he *does* have U/L access?  (Or better yet, just move him there.)

I called a few Cnet systems where I just wander through 10 dirs,
each with 10 areas (100 total) trying to [U]pload SOMEWHERE at random.
I spend a fortune before I hit one.

Maybe something like U=UL D=DL R=READ W=WRITE:
1. (ud)  + CLI/APR/Shells        2. (dr)  + Kstart/Wbench
3. (rw)  + Packers/Copiers       4. (udw) + Disk/HD/Floppy
5. (d)   + Virus Killers, FREE   6. (u)   + Home/Education
7. (DIR) + Business              8. (d)   + Other Utilities

Or course, "udrw" would be in BBSTEXT, you could change it to anything
you wanted, including removing it entirely, if you like the current,
"go and randomly guess/try to find out where you have access".

(The blank space not used on non-(DIR) areas is already available
for this.)

--509--

Actually, I'd like to see Ken's FD be *external* to the BBS itself:
1) For those not running Fidonet at all.
2) For those wishing to buy/wait/install Trapdoor or other 3rd
   party stuff.
3) So Ken can charge an extra few $ for his time/work.

LH> If it doesn't connect with every front end then why even start it, not to
LH> mention the flack you get from the powers that be in Fido if your frontend
Does EVERY front door currently connect with EVERY frontdoor?
Not by a LONG shot.  Does that mean all those authors should have never
even started writing code?

LH> BA> Remember, even if you make it compatible with 2-3 protocols, and
LH> BA> even if that's only 25% of the nodes, that's still >3800 nodes.
LH> Not good enough!
Then those users are welcome to wait/pay/setup Trapdoor.
Everybody is happy.

LH> There is a third, that being Xenolink... having run Xenolink as I know
LH> Bill B has tested it as well, perhaps he can tell us if it has all the
LH> connection to other frontends bugs out of it yet? I know it didn't work up
LH> to as late as 1 month ago. Of course this is after over 2 years of work on
LH> it... granted that isn't the only thing that the author Jonathan Forbes
LH> has been working on, and perhaps he is or isn't the equal of Ken, but that
LH> is *2 years* of work on the front end and it *still doesn't work 100%.
I doubt if that was all "*2 years* of work on the front end" alone.
And yes it still has bugs, some authors just aren't as fast/good about
killing them.

LH> Maybe that will give you people some idea of how much work this is... Oh
LH> yes, Paragon is not now nor has it ever been able to connect to 99% of the
LH> systems out there, nor can Starnet at this time....
I'd say it is more like 'can't connect with 30%" of them.
A good point though.  A buggy, "can't connect with 30%", "missing-tons-
of-features", frontdoor BBS has still out-sold (purchased copies) Cnet.
Why do you think that is?

LH> and finish all the things that Ken has started and still aren't 100%
LH> yet... Like maybe for a start... Netmail?

Which would be easier for Ken to add/fix?
1)  Netmail for a FD that he didn't write, doesn't specifically support
    Cnet's custom features, and that he doesn't even run.
2)  Netmail for a FD that he DID write, specifically for Cnet and Cnet
    alone, and most probably will be running 24hrs/day.

If you were an author, which would you fix first, if you heard:
1)  Cnet's netmail doesn't work with Cnet's frontdoor.
2)  Cnet's netmail doesn't work with this frontdoor some guy wrote for
    generic BBSes and sold to me.

Getting Ken to write a frontdoor has benefits beyond all that we
currently imagine.  (i.e. New features will be added to Cnet, and bugs
fixed FASTER, because Ken knows HIS frontdoor supports/needs them.)

I don't think Ken will ever run (or even be interested in
supporting fully) Fidonet until HE writes a FD.

1) "He authored the BBS."
2) "He authored the frontdoor that the BBS needs, too."
I just don't see those 2 things as such an unusual, bizarre concept.
They going together.

When Cnet SysOps/users were asked, they liked the idea of Cnet's
own custom Fidonet front door.
> 1:AWESOME!                                :   252: 83.1 %
> 2:I'd still run TrapDoor                  :    23:  7.5 %
And that's only with 33% of the votes in.

If that trend continues, it'll be more than 756 in favor of it.
So SOMEBODY wants to see this happen.  Not just me.

(One SysOp states that these #s don't mean anything.)

--510--
Ken> If you have mistakes (lines too long) in BBSTEXT...

Which would you prefer Cnet do:
1) Report: "Warn code 11 now set; please notify sysop!"
2) Safely read/use only the 1st x chars from each line of BBSTEXT.
3) Report: "Line 1291 in Cnet:bbsText is x chars too long."
4) Do 1, 2 or 3 and crash.
5) Do 1, 2 or 3 and attempt to run.
6) Do 1, 2 or 3 and exit safely.

It's all possible, very simply.

It currently does #1.  (I don't know if it crashes, runs or exits afterwards.)
I vote for #3 and "exit safely."

You'll know the exact, fullpath filename that is causing the problem.
The exact line # within that file.
And even the exact # of chars you need to remove.

--511--
New feature proposal...
> EP
> 11) Message bundling  : LF, .TXT     12) Your UUCP id      : 1
> 13) Edit SIGNATURES                  14) Edit "WHO" BANNER
> 15) Edit MACROS                      16) OLM Setup

#16 off of EP (Edit Preferences) would permit a user to allow/stop
certain OLMs that the system currently (or could) send him.

(Working similar to the way UM (User Monitor) sends/stops OLMs when a
user logs on/off a certain port.)

> EP;16
> Send OLMs when:  (* denotes "ON" setting)
>  1)  New U/Ls occurs.
>  2)* New msgs are posted.
>  3)  New private email has arrived.
>  4)  Private email just read by recipient.
>  5)  Public, msg just posted address to you.
>  6)  Public, addressed msg just read by recipient.
>  7)* JoinLink session has started or an addition system just added.
>  8)  New users join current JoinLink session.
>  9)  Local conference (J) session has started.
> 10)  New users join local conference (J).
> 11)  New news/gfiles/pfiles/vote topics are added.
> 12)* Your access level has been changed.
> 13)  Someone has FIngered you.
> 14)  New user just added to userbase.
> 15)  You were just charged x cents for using that cmd.
> 16)* Incoming Fidonet/Usenet msgs.
> 17)  Incoming Fidonet/Usenet files.  (ADS, SAN, etc)
> 18)  ZG finished.
> 19)  YANK finished.
> 20)* Send OLMs when idle at prompt.
> 21)  Send OLMs immediately.
> 22)  Send OLMs w/ANSI to position at top of screen.
> 23)  Hold OLMs until you execute "RO" ([R]ead [O]LMs).
> 24)  Send OLMs in separate window (local nodes only).
> 25)  Hold OLMs while in Pfiles.
> Which: 1,3,5,7,9-13

A lot can be happening when 8-24 other users are online with you.
I'd like to know about some of it.
(As well as, specifically NOT know about some of it.)

Currently, I guess, 1-16 are always OFF (not available).
And 3,18-19 are available, but are always ON.

(All of the above can be saved to a user's preference file
using just 3 bytes of disk space.)

If it's TOO much to add ALL of the above, maybe just a few of
the more important ones.  (1,3,5,7,8,11,18-21)

Or maybe like-flags could be grouped together and offered as one flag.
(3&4 5&6 1&16&17 etc.)

--512--
Hey, when was that "CALLER-ID" string added to CONFIG v2.42e?
I just noticed it.  (I'm always the last to know.)
Is this for FUTURE (not CURRENT) usage?

--513--
I'm trying to talk to Cnet via an Arexx script executed from the
CLI (NOT from online).

Can you think of any reason why this works fine:
Arexx> address CNETREXX0

But this gives "Host environment not found":
Arexx> outportname="CNETREXX0"
Arexx> address outportname

I thought they'd be interchangable.  (I need to address different
ports at different times, so I need to do so with a variable.)

I'm sure the solution is staring me right in the face.

--514--
1> Last visit was Sun 27-Dec-1992  8:35p
2> :   85 posts
3> :  936 responses (   1 new-response item)
4> :    1 new message is addressed to you
Is line #4 producing accurate results?

When I enter "RN", it shows 2 new-responses.
Neither is addressed *TO* me, like it is noted above.
(Coincidentally, both are FROM me, though.)

--515--
When setting the flags on a base:
1)  Anonymous: Y/N
2)  Force Anonymous: Y/N
1)  Private: Y/N
2)  Force Private: Y/N

Couldn't these both be made tri-state:
1)  Private: Y/N/Force
2)  Anonymous: Y/N/Force

Making 4 flags into 2.  (Same possibilities, thought.)

Or am I misunderstanding the usage of these flags?

--516--
Ken, there's a bug in v2.50 quoting.
I tried to quote from R2 and got the above text.
It's from a different item entirely.

--517--
> Long time bug that ignores the 'min allowed U/L' space variable.

So how SHOULD this work then?

Check the size of ALL partitions, compare each to your 'min allowed'
setting, and check the U/Lers file size.
Where should it decide to place the file?
1)  On the 1st "it fits" partition it comes to?
2)  On the 1 with the most space?
3)  On the 1 with the least space?
(In each case, it would 1st check that it fits.)

I say #3.  You could get all your partitions closer to 99% full
before moving onto the next 1.

--518--
>List#-#, Add#-#, Step#-#, Resp#, Quit:
Is there a way to add [R] support to quoting replies in private email also?

It would have work a little differently.
The # following Rx would take its quote from your mail #x.

I often need to do things like:  Send person A and direct quote
from person B, with my comments tacked on, too.

> "Well, John Doe said .... on the subject."

As it stands now, this isn't possible.
(And users will still try and use the [R] cmd which is still shown
in the prompt, but apparently does nothing.  Or does it?)

The same QUOTE subroutines already in Cnet should be able to be used.
Very little added code, very little added work.

--519--
I didn't see anything mentioned by Ken anywhere that stated "only
current, full-time Cnet SysOps could ever make suggestions".
Thank God.
I've made 100s and already have had a ton of them added to the
version of Cnet that you are running right now.

*Suggestions* never hurt anything.  It's always been upto Ken
to add/disregard them.

And I always think it's better to suggestion what you think
SHOULD be added.  Not shoot down other's ideas.  If you specifically
DON'T want something added, just state your case, list a handful of
logic reasons why, and leave it at that.  (The keywords being
"HANDFUL" "LOGIC" and "REASONS".)  It's all upto Ken after that point.

Don, John, Mike, Pete, Brian, etc...
Let's hear 50-500 things you think Cnet NEEDS added or fixed.
(Not 50-500 things you think it DOESN'T need added or fixed.)
Or 20, or 5, or is Cnet "fully done", in your eyes?

If you think it is, just stick with the current release and never
upgrade.  You'll be all set for life.  The rest of us will continue to
move forward.

If it isn't "done", let's hear from you.

John, I'll run Cnet full-time on the 1st possible day I can.
We all have requirements.  Things that a BBS just MUST have before
we run it.  Everyone is allowed their MUST-HAVEs.  I have mine also.

--520--
Ken, you'll never know ((or maybe you do)) how great it is to
see:
1)  A bug mentioned.
2)  Read by the software's author.
3)  Fixed.
4)  Acknowledged.
all within a FEW HOURS.   (4 in this case)

Other BBS software (no names please), it has been taking:
Between 2 weeks to never, for step #2.
Between 6 weeks to never, for step #3.
Between 10 weeks to never, for step #4.

--521--
R>    Ok well I can not unlock the system... It is asking for passwords and
R> when I tried the passwords from setpass forward and reverse it still wont
R> let me...

SETPASS isn't as clear as it should be.
What SETPASS calls "Logon password", CNET calls "System password".
Terms like this should ALWAYS use the same phrasing.

I wish I could be of more help.

--522--
TB  Cnet already puts files on the partition with the most space, or appears
TB  to.
Do you think this is the best way to do it?

Here's a 3 partition example.

Have partitions fill-up like:  (Most space 1st)
0%-0%-0% 10%-10%-10% 40%-40%-40% 60%-60%-60% 90%-90%-90%.

Or:  (Least space 1st)
0%-0%-0% 10%-0%-0% 40%-0%-0% 60%-0%-0% 90%-0%-0% 100%-0%-0%.
100%-0%-0% 100%-10%-0% 100%-40%-0% 100%-60%-0% 100%-90%-0% 100%-100%-0%.
100%-100%-0% 100%-100%-10% 100%-100%-40% 100%-100%-60% 100%-100%-90%.

If it does the latter, you could fill, back-up, lock, a partition
and not have to worry about backing it up again and again.
(Until you clear off some space and start filling it again, that is.)

--523--

I think Ken's FD could out-do all other FDs on EVERY level:
1) Design
2) Price
3) Bugfixes, updates issued (speed and frequence)
4) Shipping time
5) Size
6) Easy of setup

And it "HAS TO" top all others in areas like:
 7)  Familiarity with the inner workings of the source code
 8)  Copyrights
 9)  Compatibilty with features SPECIFICALLY designed for Cnet
10)  Guaranteed to exist for the lifetime of Cnet
11)  Guaranteed to be compatible w/Cnet throughout its lifetime of changes
12)  No need to add support/complexity for non-Cnet FD features
13)  Contact with the author in USA
14)  Earned profits in FD sales (to new and existing users)
15)  Earned profits in more sales of Cnet BBS itself
16)  Easy of availability
17)  Which features are added/removed/changed

Side benefits like:
18) Ken might actually run a Fidonet system himself.
(I haven't heard ANYBODY against that idea.)

I'll admit 1-6 can be argued.  (And are just my opinion.)

But how many will dispute 7-17?  When you ARE the author you have
ultimate control.  Ken wouldn't really have to do much out of the
ordinary to beat the competition in 7-17.  Just DOING a CNet specific FD
gets him all those.

The real question is:
19) Does Ken have the time and desire?

--524--
TB>  UUCP is only a set of utilities that dial out, accept calls, process
TB>  things..
TB>  All you have to do is use UUCICO to call out, but with trapdoor up, unless
TB>  you can tell it to get off the serial line (or it uses
TB>  'owndevunit.library') or take it down...
Does anyone know if it would be possible to have a single FD do
both in and out Fidonet and UUCP packets?

If so, has anyone done it yet?
Sure would be a nice "Cnet First" (again).

--525--
S>  You really ought to read the instructions before you get all upset.
S>  Everything you need to know is included with the C-Net program. It's in
S>  the "programming" directory on disk 2 of C-Net Amiga.
This is *everything*?
"empty.c" "ins.c" "cnet.h" "cnetfuncs.h"
That's the complete "programming" directory.

(And the majority of lines in the header files don't even have simple
comments as to what the variables are/do.  You just have to guess.)

The printed manual has even less.

--526--
> 20)  Send OLMs when idle at prompt.
> 21)  Send OLMs immediately.

I've added 2 more suggestions on how OLMs could be offered:
> 22)  Send OLMs w/ANSI to position at top of screen.
> 23)  Hold OLMs until you execute "RO" ([R]ead [O]LMs).

#22 Would do the 'partial screen scrolling', so your OLMs would
    be able for reading at the top of the screen, as the rest of your
    session scrolled-up in the screen below.

#23 You could specify that your OLMs be held until *YOU*
    are ready to view them.
    (Not "the system is sending them to you *now*".)

And if 23 separate flags are too many, maybe "like-flags" could be
grouped together and offered as one.  (3&4 5&6 1&16&17 etc.)

--527--

RR> Now (correct me if I am wrong, Bill), Bill has stated that Cnet bundled
RR> with
RR> TrapDoor along with some DECENT documentation on how to get it all set up
RR> --
RR> CNET SPECIFIC documentation, not that generic stuff that comes with
RR> TrapDoor
RR> -- would be acceptable to him.  We all know that we own the best BBS out

I still think the majority of users just don't need send/receive FAX
support and about 100 other things that the big beast known as
TrapDoor, comes with.

If so many are saying its hard enough just setting up Fido, why make
it 10x more complex with all the little-used extras?

I'd like to see a mini-minimum-bare-bones FD, external, written by
Ken, 100% customized for Cnet only.  If you don't need it, don't buy
it, buy Trapdoor instead.

I don't know what kind of contract agreement Ken would have to sign
with TD's author, and what commitments would have to be made.

But here's a few things to keep in mind...

Do you think Ken would have waited 13 months to fix the dozens of bugs
that are listed in TrapDoors's v1.83 readme file?
Can you imagine?
Get an update in Dec 1992 and the bugs fixed in next one in Jan 1994?

Everyone starts climbing the walls now, if a Cnet update is just
1-2 WEEKS late.  Imagine a *60* week wait?  And Ken couldn't do
a darn thing about it.  We'd all just sit on our hands.

TrapDoor (regardless of its state) would be the official, bundled
Cnet BBS frontdoor.  If it crashes your whole system, what will people
think of Cnet the BBS?

I don't think the 10000s of people that call Cnet BBSs regularly
worldwide, would really want to hear the sysop's details as to
WHY Cnet keeps crashing, they'd just associate it with Cnet.

Remember, every call has to successfully get through your front door
flawlessly.  And your FD will most likely be answering things 24hrs
per day, 365 days/yr.  This won't be a "seldom used program that's OK
to have a handful of bugs in it".

--528--
Lines in Cnet's header file like:
> #define PASSWRD_FILE "SYSDATA:passwords"
prevents things like this from ever occurring.

(And all pfile authors could use all these #defines too, and instantly
pickup any changes Ken has made.)

--529--
> Arexx...
> 'version'
> 'sendString' RESULT

Shouldn't this display "CNet v2.42e".
It is currently displaying "$VER: CNet v2.42e".

(If sss is a pointer to this string, make it display sss+6 instead of
sss.)

--530--
S> I still think an icon on workbench would be best... Like the way DirOpus
S> iconifies itself... I leave DirOpus running on my system 24 hours a day,
S> and one of my favorite things about it is that I can just have it iconify
S> itself to a nice little icon on the workbench window. It's totally out of
S> the way, yet still easily accessable.
Which version of OPUS do you run?
Mine iconifies into a WINDOW complete w/dragbar, and back/front/close
gadgets.

I'd like to see the icon-mode stay exactly as is, but w/2 exceptions:
1)  Smaller (or remove) the "BIG C" part.
2)  Hot-key (user selectable) as a commodity.
And you don't lose ANY of its current features.
(Moving backwards, in order to move forward, isn't a favorite of mine.)

I'll explain a little more about my publicscreen (PS) idea:
1)  You run 1 (but just 1) of your nodes in a screen (not window).
2)  You then open the control panel (iconed or not) onto this PS.
3)  You run your other 2-24 nodes as WINDOWS (not screens) onto #1 also.

All nodes, control panel (iconed or not), now "RIDE" on this 1 screen.
A single back/front gadget click pops the whole ball of wax in or out
More[Y,n,c]           of the way.

Question:
How do you 'find' this WB icon under all your other CLIs, Cnet windows,
and all the other stuff going on?  (Resize them all?  Move them all?)
(Unless Ken goes with the hot-key idea.)

--531--
Would anyone be in favor of the INVITE cmd supporting ranging, instead
of having to move into each sub, then invite each user?

>INVITE 47                    (Just this 1 user)
>INVITE 47-58                 (Invite all these users)
>INVITE 47 4                  (Invite him to sub 4 (w/o having to move to it.)
>INVITE 47 1-12               (Invite him to subs 1-12)
>INVITE 47-58 1-12            (Invite these users to these subs)

(As well as making Cnet 1 step closer to "if it supports a #, it also
supports a range".)

--532--
Ken writing his own frontdoor would be like a film-maker acting as
writer/direct/star.  *A LOT* of hard work.  You have to be *VERY
TALENTED* to pull it off.  But when the smoke clears, you'll have
ultimate control of everything from opening credits to closing
credits, from FrontDoor log-on to log-off.

--534--
P> What Cnet really needs in the fido area is a CNet-toss. Even if ken
P> does write a mailer, you would QUICKLY find out how badly this is
P> needed. One because you must pay for Foozle, TrapToss, or use some
P> other method of tossing before Ifido/Xfido are even useful. And then
P> this method we have now is SLOW, like twice as slow atleast as it
I AGREE, big time.
Do you think this 2-step method would have ever been installed at all
if Ken was doing a "start-to-finish" BBS?
Frontdoor/packer/tosser/BBS/etc.
(Like Paragon/Starnet/MEBBS/XenoLink and the others already have.)

P> crashes for months while the bugs are worked out. Your feeds
P> get tired of you, you get banned from your network. you get
P> pissed at ken because now that this HUGE project has been
P> taken on, CNet bbs has'nt seen a new release in 4+ months.
P> and then when Cnetmailer is done, you will find out how badly
Do you still think this would be a HUGE project even though Ken
already has finished all the code that answers the call, serial I/O,
fidonet support, transfer protocols via existing libraries, etc?

I was thinking more like:
Other than the fidonet handshaking, all the elements are already
coded.  No?

Remember what MY (not yours, or anyone elses) suggest was:
1) Keep it bare-bones.
2) Simple to setup and run.
3) Keep it external.
4) Don't prevent anyone needing more power from buying/using trapdoor.
5) Very bug free.

A few people are replying to that with:
"Do you know how hard it would be to write something as big and
complex as Trapdoor?"

That's EXACTLY what I DON'T want Ken to do.  To clone TrapDoor.
More is less.

Is there already a FD that does 1-5?
Even something smaller, like Foozle, is still far too much power for
the avg user.

--535--
> 1.       + CLI/APR/Shells        2.       + Kstart/Wbench
> 3.       + Packers/Copiers       4. (DIR) + Disk/HD/Floppy
> 5.       + Virus Killers, FREE   6.       + Home/Education
> 7. (DIR) + Business              8.       + Other Utilities

If I "close a sub" didn't a "(DWN)" (or something) used to appear next
to the name?

I've been online systems where the SysOp had no idea that 1 of
his dirs (and it's 10-100 areas within) had been closed and forgotten.
(And he's probably wondering why there's 0 activity there.)

It would be informative to callers and SysOps alike.

--536--
Would anyone be more/less encouraged to use the "Autovalidate files"
flag on more of their users if it was broken into 2 separate flags?

1> Auto-credit U/Ls
2> Auto-validate U/Ls

1) You could give users instant credit for U/Ls, but still take
   a look at files before others could D/L them.
   (To check for pirated software, viruses, inappropriate files.)

2) Or you could instantly allow others to D/L files, but the U/Ler
   still wouldn't get ratio credit until you looked at them.
   (To stop callers that U/L junk, just to get instant credits.)

Or do both.

Or do neither.

Without this independant control, I'd have to make 95% of my
users NON "autovalidate files" just to be 'safe' on both counts.

Or maybe just keep the existing 1-flag and make it multi-state.
1>  Auto-U/Ls: Credits/Validate/Both/No

--537--
R  ESPECIALLY if you run them with a frontdoor.  When I ran just CNET it used
R  to say "144" as the baud rate in the WHO display. Now with TrapDoor, it
R  just
R  says 96"... I can live with it. (PLEASE don't turn this into a "See I told
R  ya trapdoor was junk" thread!!!!)
TD is DEFINITELY NOT junk.
But if it has problems like this can't we all know and talk about
them?  (As we would ANYTHING else with a problem?)

Do you think TD's author will jump and fix this just
for Cnet users?  Or should Ken change his code to work
specifically with TD?

Just asking.

--538--
All that Ken would need to change would be to make Cnet run
an arexx script to get the user's filenote.  You could have it
check for min length, max length, specifically ask for version #s,
dates, author names, Fred Fish #s, check (and even automatically
correct) for correct upper/lower case usage, etc, etc.  Make your file
catalog's short-descriptions as simple and free form as you like.  Or
as strictly regimented and formatted as possible.

This arexx script by default would just get a string of any 0-84 chars
from the user, as Cnet does now.  (But I think many sysops would modify
it and put this feature to GREAT use.)

--539--
R>          GETKEY; ans=result
R>          IF hash(ans)=27 THEN          they hit ESC...
R>  Whats harder is to trap the CURSOR KEYS, as they send THREE codes "at
R>  once",
R>  {ESC}, {"["}, and either {A, B, C, or D}, depending if ya hit UP, DN,
R>  LEFT,
R>  or RIGHT..
Perhaps we could get Ken to add a new GETRAWKEY arexx cmd.
Would that do it?

--540--
BB>  Where do you think would be a good place to store the index file?
BB>  SYSDATA: or UDBASE0: ?
I'd say something like "SysData:bbs.fdata" for file-data.
Nice companion to their "bbs.udata bbs.sdata bbs.adata bbs.idata"
counterparts.

BB>  ALSO!  I have increased the short file decsription space to 210
BB>  characters, enough for 5 lines of the current length.
Ken, are you thinking of putting a configuratable min-max limit on
this?  Wouldn't need to be 'per-base'.  Just a global from setting
in CONFIG/LIMITS.

10,000 210-char notes (not that everyone is going to use the full 210),
can produce some VERY different file sizes over 10,000 50-char notes.
(2,100,000 VS 500,000 bytes)

--541--
I'm not sure how I did it, but I've marked a dir for D/L.
> (1) Suggestions for the future>  ss
>
>  1. UDBase0:arexx/            24588
>
> Bytes: 25K  Time: 1:53
>
> Enter RANGE of items to de-select or press ENTER to continue.

--542--
Did a recent Cnet update (v2.59 perhaps) reset everyone's "ORder of
items" back to type #0?  Is there a quick way for me to set 50 bases
back to type #2?  (On 60 different BBSes.  50x60=3,000 bases.)

--543--
You really find that seeing things like this on 1000s of your downloads:
 1> PSX.LHA         10993     A public screen manager!!!!!!!!!
 1>                           */\/\/\/\/\/\/\/\/\/\/\/\/\/\/\*
 1>                           *|+|-=-=-=-=-=-=-=-=-=-=-=-=|+|*
 1>                           *|+|# # # # # # # # # # # # |+|*
 1>                           *|+|                        |+|*
 1>                           *|+| ThIs FILe wAs uPlOaDeD |+|*
 1>                           *|+| bY ThE GrEaT AnD aLL   |+|*
 1>                           *|+| PoWeRFuL wIZarD oF oZ! |+|*
 1>                           *|+|                        |+|*
 1>                           *|+|# # # # # # # # # # # # |+|*
 1>                           *|+|-=-=-=-=-=-=-=-=-=-=-=-=|+|*
 1>                           */\/\/\/\/\/\/\/\/\/\/\/\/\/\/\*

Are more valuable than great, informative file descriptions:
 2> FileName.LHA 45K ARexxArp.library v2.52 by W.Langeveld released 16Oct90
 2> FileName.LHA 12K Hot-key window shuffle v1.07 for WB2.0 released 01Jan92
 2> FileName.LHA 34K Change WB2.0 cut/paste keys v1.0 released 14Feb92
 2> FileName.LHA 67K Amiga's Ultimate Shell v1.42 by D.Gounelle released 06Jul92
 2> FileName.LHA 87K WB2.0 pulls/holds down menus w/keybrd v1.0 released 01May92
 2> FileName.LHA 43K Menus always popUp @ mousePointer v1.0 released 30Aug92
 2> FileName.LHA 56K WB2 commodity list/select screens v1.0 released 07Sep92
 2> FileName.LHA 69K Handy screen Manager v1.13c for public WB2.0 scrns FF692
 2> FileName.LHA 90K Move full windows, not just outlines v1.2 released 10Oct91
 2> FileName.LHA 35K Arexxmath.library v1.3 by W.Langeveld released 20May89

When I'm trying to decide which files to D/L (at $$$$ phone rates),
I'd much rather see #2, instead of #1.

I'm not trying to be a problem.  I REALLY want to understand your
needs/reasonings behind this desire.  I think I'm missing the point,
or something.  #1 is better than #2???

But, to each his own.  You'll be able to use Cnet's new, longer
filenotes any way you wish.  (But without any kind of SysOp control
over things, I sure hope user's don't start abusing this new power.)

I like BROWSE'ing 15 titles per screen, instead of 3, due to overuse of #1.

(Actually, I always hoped BROWSE would obey my current screen-height
setting, instead of '15 titles' regardless of whether my screen is 20-
24-48 high.)

--544--
I often seem to get just enough line-noise during long screen
displays, so that each "More (Y,n,c):" prompt assumes that I had hit
'Y' and the screen just scans forever.

Would it be possible to have Cnet flush the input-buffer just before
each "More (Y,n,c):"?  (Everything would still work as it does now for
those users not affected by this problem.)

Another solution would be to have Cnet use Y=YES N=NO C=CONTINUOUS
RETURN=YES and ignore all other characters.

--545--
I'd love to tell users, "write a better description to your U/L
and I'll give you file credits".  Saves me the work of doing so
myself.  But when they try:
>W47
>This item already has a description!

I'd like to see, "If the user U/Led it, he can edit the description
he wrote with the 'W' cmd."

And this would be WITHOUT giving him full 'edit' capabilities.
(I initially thought that was 1 of the reasons why there was a
separate "W-write description only" cmd.  But no such luck.)

--546--
Ken, would it be worth expanding the VDEentry structure to include any/all
of these new elements:
1)  Color (0-15) used for foreground displaying of text.
2)  Color used for background.
3)  Color of text when highlighted.
4)  Color of background when highlighted.
    It would help greatly in 2-color screens, Cnet doesn't highlight
    or invert the text correctly at the cursor position.
    Also, we could make "important" flags red, "often-used" flags blue,
    tri-state flags in yellow, etc.
    (Maybe just combined all 4 (respectively) into a single "7B3C"
    color hex value.)

5)  The character used as the current cursor position.
    (Or just default it to ">", again, for better 2-color screen use.)
    But settable for each entry in the structure would allow things
    like:
       a) Use ">" for editable items.
       b) Use "<" for exit items.
       c) Use "." for submenu branch items.
       d) Use "#" for items that expect a number entry.
       e) Use "%" for items that expect a percent entry.
          (I'd really only need/use A-B.)
   If it's not worth making this settable on a per-VDEentry basis,
   then A-B would be an excellent new default.

6)  A pointer to an array of strings.
    Each gadget-click would flip through this list of strings.
    So we could toggle between our own "Yes" "No" "Sub" "Both" "Cfg"
    "In" "On" "Off" "Out"...  tri-state (or more) flags.

--547--
1> 100 5-Jan  10 FileName      LHA 123K xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
1>                                      xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
1>                                      xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
1>                                      xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
1>                                      xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
1>                                      xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx

2> xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx 100 5-Jan  10 FileName      LHA 123K
2> xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
2> xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
2> xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
2> xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
2> xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx

For 100 files listed as #1, you'd have to wait until about 48,000 chars
were displayed.

The same list for #2 would be about 30,000 chars.

But would you like this rather odd format?

--548--
D  My only qualm with the new format is that it seems like a waste of space
The thing I don't care about the new format is you now have to hunt
thru the long filenotes just to see the filesize and even the archive
method used.  These really used to 'stick-out' in the previous format.
(Being 'outside' the columned filenote area.)

Some BBS software (no names please) allows each user to pick between
5 different short-scan and long-scan, files and msgs,  display formats.

(Still not as good as doing it with MCI codes, which would allow 1000s
of different display formats, but still better than the current "only
1" choice.)

--549--
What commands can we execute while in CHAT?

Any of these would sure be handy:

 1) /Send     (Show user a text file off your HD.)
 2) /Upload   (Send file to user via preferenced-protocol.)
 3) /Download (Receive file from user via preferenced-protocol.)
 4) /? or /H  (Help screen, including info on how to exit CHAT.)
 5) /WHo      (See who's online.)
 6) /!xxxx    (Execute global Cnet cmd xxxx.)
 7) /$xxxx    (Execute global Cnet cmd xxxx, sending output to user, also.)
 8) />xxxx    (Execute DOS cmd xxxx.)
 9) /<xxxx    (Execute DOS cmd xxxx, sending output to user, also.)
10) /X or /Q  (Exit chat.)
              (Do ALL computers, all terms, generate successful ^Xs?)
11) /=        (Make a noise.)
12) /Time     (Stop the user's system clock.)
13) /Window   (Pop open a window for separate input VS output typing.)
14) /Nowrap   (Turn off word-wrapping.)
15) /Muffle   (Forbid user to type while you are typing.)
16) /Buffer   (Only send text to user after you've hit RETURN.)
              (#14-16 would be in effect through this chat or until
              toggled-off by executing the same cmd a 2nd time.)

Some are User<-->SysOp (on local node) only.
Some are User<-->User  (on remote node) only.

Especially handy would be 1, 7, 9, 13, 15.

--EOF Monday 11-Jan-93 21:30:53 --

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