
Tuesday 16-Feb-93 17:26:15

--700--
I *REALLY* miss CNet's ability to have different colors for each screen.
Flipping through them, I could quickly tell which was which just by
color-coding them.

White  = local 0
Red    = node 1
Green  = node 2
Blue   = node 3
Gray   = 2nd local 4

Anybody else miss this feature?
Ken, any plans on bringing that back?

--701--

 BB> You need a SPACE in there ... {% 01-01-99} ... I believe this goes for
 BB> ALL MCI commands that have a "string" argument.
 Ken, I can't even find these mentioned AT ALL in the new MCI docs.
> {%} {&} {%} {+} and others
 Have they been changed, or removed, or forgotten?

--702--
LH> figure out how to set it up and install it on your CNet BBS. I still don't
LH> see why you think this is so important... important enough to run
LH> something that is by your own admission buggy! You have changed your
LH> origin in the FidoNet echoes to say, "Loves 97% of CNet!" or something
LH> very close to that, why not give in a little bit? Why give up that much
LH> power????!!!!

But that 3% are things that I can't possibly live without.
It's like saying "This BBS Software does 1000 things.  But no DL'ing.
That's only 1 missing feature.  So why don't you run it anyway?"

Yes, I consider Fidonet as important as file transfers themself.
It's just ***MY*** personal preference.  Fidonet, all included, I'll
pay ANY price, but I don't want to deal with shareware or public domain
programs in order to do it.

I'll allow you to have your "personal preferences", if you'll allow
me to have mine.  (And with the 1000s of sysops NOT running TD, or
even CNet, I'm not alone on this.  It's VERY important to MANY of us.)

--703--
If you really want power beyond even that, please consider doing something
like this:
1) The MCI string in BBSTEXT is the default for all callers.
2) It can be overridden with the MCI text in files Mail:Users/#/_fheader
   or _mheader, if those files exist.
3) These can be edited via EP "17) Edit custom file/msg headers"

I'll write a simple arexx script that will allow each caller to view
(or take) the 100s of other caller's _fheader or _mheader file configs.

--704--
Ken, sometimes when I send text into the editor too quickly, or even
do a ".MCI read" or "^Preview" or "^Verify", random noise characters
appear in CNet's prompt afterwards.  Would it be possible to clear
CNet's input buffer to get rid of these stray characters?

Another very nice feature would be to have "character pacing".
That is, CNet doesn't send the next character until the previous character
has been echoed back successfully from the remote system.  Screen
displays are slower, as characters are displayed 1-by-1, but random
noise should be MUCH lower (near 0).  (Due to the slight slow-down,
maybe this would have to be a per-user flag.)

--705--
Regarding extracting files from the update...
BB> I seem to have forgotten to say where all of these files go ...

Ken, please consider compressing with the "-x a" option.
It preserves full-path names.
We can uncompress them right into their correct dirs.
(Users not wanting this feature could just extract with "x" instead
of "-x x".)
Thanks

(And don't think we didn't notice that this update is 1 day EARLY!!!!)

--706--
TB> Simply keeping usbable data at the BEGINNING of structures and adding on
TB> only
TB> to the end will solve that.. but as a programmer, I like to keep things
TB> clean
TB> by keeping related data next to each other, so always adding to the bottom
TB> of
TB> a structure can be a hard thing to do (for me).

I can't recommended keeping things 'clean' at the cost of major breakage
of 100% of the existing pfiles.

If you MUST keep things 'clean', add padding into the structures at
various points.

Your idea of 'expand only from the bottom' should be used 99% of the time.

--707--
About the only unfortunate thing about the new MCI changes, is that
they weren't made ages ago.  Breaking 1 year's worth of stuff, is
better than breaking 3 years worth.  And it's certainly better
than waiting even longer.

Ken should have made this change AS SOON as he saw the old MCI
shortcomings and limitations.  Which I imagine was long, long ago.
It can be very hard to try and look into the future and ask yourself,
1)  "What might I want this to do 2-5 years from now?"
2)  Even if I can't guess, and don't want to add the features themselves,
    should I at least leave things "open" enough for future expansion?

I can't blame Ken for NOT being a fortune teller, and NOT doing #1.
But he IS (very) smart enough to do #2, but didn't in this case.
So we get the major MCI breakage, instead.

Sorry, I call'em like I see'em.

--708--
Ken, here on FW, I hit .HELP in the line editor.
I answered NO at each prompt, but it displayed the text anyway.
Want to see more [No]? No
Read range (*) selection info [No]? No
Read "justify" options [No]? No
Read control character information [No]? No

Still got shown all those help-screens

--709--
If I have a block of text in the editor, that has a variety of mis-
placed linefeeds in it, many lines ranging from 40-60 chars long, and
I want to reformat that block, removing the LFs, and reformat to 80
columns, how do I do it?  (In the line editor or full-screen editor?)
Move to the end of each line, 1-by-1 and remove those LFs?  Or is
there a better/faster way?

Ken, any plans on expanding "^Region" to include:
>REGION: [C]opy [K]ill [M]ark [P]aste [R]eformat

--710--
Any way to allow me to ERASE a block WITHOUT putting it into the
cut/paste buffer, thus destroying what I already had in there?
>REGION: [C]opy [K]ill [M]ark [P]aste [E]rase

So we'll have the complete set of 3:
1)  Put into buffer and don't erase from screen. (COPY)
2)  Put into buffer and erase from text. (KILL)
3)  Don't put into buffer, just erase. (ERASE)
(Actually the words "KILL" and "ERASE" would be better switched around.)

Most editors I've worked with had all 3.  And the rare ones that had
one missing, would leave out #2.  (It can be simulated by doing #1 and
then #3.)  But I've not seen too many editors that leave out #3.
(When you do, we're stuck.  It can't be simulated by any other means.)

I think #3 would definitely help cut down on "over-quoting".  The
easier/quicker people can remove blocks of text, the more likely they
will.

--711--
R> Sounds like a 'bug' in the UP250 conversion prg. It happened to me.
R> I had to manually re-set my 20 or so files bases. I believe newly
R> created subs will have the default at '1', only the converted subs
R> got the '100' setting... mines all fixed now, no biggie.
Do 1000 SysOps have more "converted subs" or more "totally new subs"?

R> Any bug that
R> i can workaround doesn't really bother me, its the ones i can't that
R> i hate! :)

1) What about the 1s that require you to manually change 300+ subs?
2) What about the 1s that you don't even know if they are bugs are not,
   because nobody officially comments on them?
(This bug does both.)
I could handle #2, but not both 1&2.
No biggie?  No bother?  300 subs?

Sorry Ken, but I hope you don't want *ME* to start lying and saying
"No biggie?  No bother?", when I really feel otherwise.  It won't
benefit either of us.  I hope you'll allow me to "Call'em like I
see'em.  No holds barred."  It IS appreciated.

Did this 'bug' get official mentioned as such, as soon as it was found?
Did UP250 get fixed?
Does v2.61 come with its own UP261?

PB> Its not that big a deal..

Pete, you really don't consider 100s of SysOps eaach changing dozens of
subs 1-by-1 as any big-deal?  (500x30=15,000 subs)

Or each of 1000s of callers DLing 3 files and losing *300* file credits?
Yikes!  And afterwards, SysOps trying to remember which callers need to
get repaid their lost 297 file credits?

Since NO official, big announcement/warning has yet to be issued,
callers are STILL losing *100x* their file credits on many CNets all
over the world.

(Including Ken's.  Thank God I have unlimited DLs here.  But I pity the
many users that don't.)

--712--
>Regarding the v2.61 LHA update.

To everyone that unpacked this OK:
What CLI options did you use for the unpacker?
(And which unpacker did you use?)

I kept getting:
LHA> *** Error on file 'amaint' : Unable to open output file
LHA> *** Error on file 'bbslist' : Unable to open output file
LHA> Extracting: (       0/   19232)  bbs/bmaint
LHA> *** Error on file 'bmaint' : Unable to open output file
LHA> Extracting: (       0/   31080)  bbs/join
LHA> *** Error on file 'join' : Unable to open output file
LHA> Extracting: (       0/   16148)  bbs/lmaint
LHA> *** Error on file 'lmaint' : Unable to open output file
LHA> Extracting: (       0/   12436)  bbs/load
LHA> *** Error on file 'load' : Unable to open output file
LHA> Extracting: (       0/   12684)  bbs/mverify
LHA> *** Error on file 'mverify' : Unable to open output file
LHA> Extracting: (       0/   13200)  bbs/ulist
LHA> *** Error on file 'ulist' : Unable to open output file
LHA> Extracting: (       0/   17688)  bbs/vote
LHA> *** Error on file 'vote' : Unable to open output file
LHA> 23 files extracted, 9 files failed.
LHA>
LHA> Operation not entirely successful.

Once it unpacked BBS (a file), it can't create BBS (a dir) to
place these files in.

Ken, which packer and which options did you use to compress this?

Please consider packing with either FULL-PATHS or NO-PATHS, but
not 'partial paths', like this.

(Also, this archive contains many files that had NOT been changed
at all between v2.60/R2 and v2.61.  Please consider NOT include files
we already have DLed before.  Thanks.)


 R> You have 2 options, easiest is to do a simple extract to ram disk,
 R> ie. "LHA x 261.lha", then copy things where they belong manually.
 The above still fails.

 R> What I did was extract it twice to ram disk. First, do:
 R> "LHA x -x 261.lha", and let it fail, then copy the stuff to thier propper
 R> dirs. Next kill everything from ram, and make a DIR called BBS then un-lha
 R> it again with full pathnames, and then bbs executable will fail, but the
 R> files in the bbs dir will be ok. Copy these to pfiles:bbs/ and you're
 R> done!
 The above DOES work.  (As well as several other methods.)
 But why is all this mess necessary at all?
 I've packed and extracted a bazillion files over the years, simple
 as pie.  Why the trouble with this one?

PB> Simple..  in the past one of two things happened
PB> 1: the directory BBS was created INSIDE of the subdirectory PFILES:

Pete, do you agree with me that Ken (and everyone creating any archives for
distribution) should either pack with NO-PATHS or FULL-PATHS?
(Pfiles/bbs/amaint)

But NEVER partial-paths?
(bbs)
(bbs/amaint)

--713--
DM> BB> This is the only subboard that NON CNet sysops have access to.
DM> Ken would you consider placing a ** or something in the title of this
DM> subboards name to remind those of us that call and do a lot of bullsh*ting
DM> that we should not discuss C-Net in this area to the same extent that we
DM> discuss it in others...

Good idea.  But will everyone (SysOps and non-SysOps) instantly know
what that "**" means over the next few years?  I'd like to see Ken
mark them with something a little more informative:
>11.       + CNet Q&A (PUB)
OR
>11.       + CNet Q&A (Public)

--714--
Is there a way for me to allow users to 'MOve' their own ULs from 1 sub
to another?
I would need to:
1)  Allow/disallow on a per-user basis.
2)  NOT give the user any other maint/subop/sysop powers.  (Just 'MOve')
3)  Each user could move just their own ULs.

I'd much rather allow THEM to do all the work, instead of 1 lone SysOp.

(I'd just not give them credits until the U/L was in its correct sub.)

This is 1 of many reason why I'd like to see ALL BBSMENU cmds available to
ALL users, by default.  SysOps could then allow/disallow specific things
ourselves.  NOT force what is hardcoded into CNet.

> VOTE `10-23     (Only callers with access 10-23 can VOTE.)

1) @5-8 (Only callers with these msg-flags turned on, can execute.
2) #4-9 (Only callers with these file-flags turned on, can execute.)
3) $2-5 (Only callers with these g/pfile-flags turned on, can execute.)
4) +    (Only callers with SysOp-flag turned on, can execute.)
5) -    (Only callers with SubOp-flag turned on (for the current sub),
         can execute.)
6) *    (Only callers with maint-flag ON, can execute.)
7) ^4   (Only 4 callers can run this cmd at the same time (like UL or DL).)
8) &    (This cmd can also be executed remotely via JOINLINKs.)
9) =    (This cmd can't be executed during call-back sessions.)

--715--
If you want CNet v2.61 (or better) to display the # of DLs, instead of
# of replies, during [S]cans, edit BBSTEXT:

> Jump to line #422
> Change the "83" there into "85".

That's it.

KEN, THANKS FOR THIS NEW MCI POWER!!!!

--716--

> I am experiencing problems with upload having errors.  This occurs during the 
> access of my Tahitti 1 gig Magneto Optical Drive. The utility to copy the file
> to ram for download is GREAT! but would it be possible to do it the other     
> way??  I need to upload to RAD: or RAM: and then move the files to the HD     
> partition between transfers.  This would save tremendous time on uploads due  
> the th 35ms access time on the Optical Drive. This problem vanishes when      
> writing to a FAST hd or to ram:/rad: (The controller is a GVP for reference). 
> I have 16 Meg of ram so it would be nice to upload to ram.

2.61> 190. Better support for CD ROM drives has begun.  From the CONFIG
2.61> program, you may specify a temporary directory to use for
2.61> CD-ROM downloads.
2.61>
2.61> From each subboard's EL screen, you may toggle a flag to specify
2.61> whether or not CNet will copy files to this temp directory as they
2.61> are downloaded.

Ken, please consider a 'tmp-path' for non-CD-ROM UPLOADS, too.
(Many more people UL, than use CD-ROMs.)

CONFIG would need an UPLOAD-PATH string.
If it had a string in it, it would be used.
If it was NULL, then CNet would work as it does now.  (UL directly to disk.)
(You would NOT need to add a 'per-sub flag', or 'per-sub path' for this.)

All uploads would be directed to this tmp-directory first.  After the
UL was finished, the file would then be (background) copied to the
correct HD dir.

It would have the following benefits:
1)  Crashes or GURUs during ULs to ram:/rad: will NOT trash
    our HDs.  (Sometime unrecoverable.)
2)  Ram:/rad: drives can be MANY times faster than HDs.
    Improved CPS rates, lower CPU loads, etc.
3)  Those with limited ram:disks could even create a small tmp/junk HD
    partition for this purpose.
4)  Even "non-size-send protocols" could check for diskspace before a
    partition is filled up.
5)  Fewer HD writes, head moves, etc.
    (6 callers uploading at the same time, each writing 100 small
    blocks directly to different parts of 1 HD.)
6)  Those with multiple HDs (more and more common these days),
    could specify their faster HD as the tmp-UL-path, and their
    larger, slower one as the UL's final home.
If, I'm not mistaken, NONE of the above is currently available (or
even possible) without doing 'tmp-upload-paths'.  (#1 is a BIGGIE!)

If you are willing to add a specific 'tmp-path' for the relatively few
(5%) CD-ROM systems, (I'm all in favor of it!), hopefully you'll
consider adding something, like this idea, which has the potential of
bettering 90-100% of the systems.

AK> If you want to UPLOAD to RAM, just increase your BUFFER in Z-Modem. That
AK> should SOLVE your problem.
Personally, I'm not having a problem.  But are all 68000 users getting
16.8 to work perfectly?
(But that's just 1 out of MANY good reasons for a tmp-UL path.)

AK> just increase your BUFFER in Z-Modem.
Not everyone uses Zmodem.  It is my favorite, and great.
Who has the full docs for what each of these means:  "TN,OR,B2,F0,AN,
DN,KY,SN,RN,P"?

I've seen unusually large and unusually small protocol buffer
sizes BOTH create problems.
Too small: Too many tiny writes to disk, slow CPS rates.
Too big  : Too large a delay while a giant block is written to disk, the
           protocol times out.

This brings up another benefit that I will add onto my eariler 6.
7) I've seen MANY reports from users (SysOps, as well as just terminal
users) that have trouble with certain older, and/or slower HD
controllers during file transfers directly to/from their HDs.  Slower
CPS rates, and VERY often they can't do over 9600 directly to HD, AT
ALL, no matter what they try.  But DO get things working fine when
they can UL and DL directly to a ram-drive.

I don't think it would exactly hurt CNet to add (onto its already
impressive list of features) a mention of the possibility of allowing
high-speed file transfers to users that couldn't do so in the past
when using non-CNet software.

I'm sure there are still 1000s of these older/slower HD controllers in
use.  If all it takes is a simple, tmp-upload feature to increase the
potential sales market to also include these 1000s of users, I say
it's well worth it.

I think anyone in the market for new BBS software would definitely
consider the one that did NOT require moving from a 68000 to 68020
machine, or replacing their HD controller, or buying a high-speed ser
port card, etc.

Ken mentions it in the manual.  (The very large CPU load that is placed
on the Amiga during hi-speed ser I/O.  It's NOT CNet's fault, or Ken's.)

--717--
Is anyone else getting this 'error' (not 'warning') msg from SAS v6.2 when
compiling Ken's EMPTY.C?
SAS> "conflict with previous declaration"

Cnetfuncs.h defines it as:
> long GetFree( char *where, UBYTE quiet );

Empty.c defines it is:
> int GetFree( char *s, UBYTE q )

Ken, please consider using "long" when you mean "long" and "short"
when you mean "short" in all code.  It avoids ALL ambiguities between
different machines, different compilers, different versions of
compilers, different default int sizes, different optional int sizes,
etc.

(Also, descriptive variables like "where" and "quiet" and much better
than "s" and "q".)  Prototypes would practically document themselves.

--718--
From the v2.61 ReadMe...
> CNet C pfiles may now (in general) take arguments.  This will
> open up opportunites for more control of a-maint and other
> pfiles--not previously possible.

Ken, is this part of v2.61?  I'm still trying (without success)
to do things like:
CNet> Main> MyPfile FOO THIS
CNet> Main> MyPfile 45
CNet> Main> M45
And have my pfiles receive "FOO THIS" or "45" via argv[] (or some means).

Custom Pfiles could work just like other CNet online cmds.  Slick.

--719--
 PB> Bill, You had a vote topic on Whether Ken should replace the # of files
 PB> downloaded in the scans -or- leave it in the new Number of replies format.
 PB> I am happy to report that if you edit line # 422 in your BBStext file and
 PB> replace the v83  with a  v85   you will have it made!

 PB> {v83} = Number of Replies
 PB> {v85} = # of Downloads

 Pete, I posted (locally and Fidonet) this joyous news (including the
 line # and {v} #s) a few days ago, to help sysops who might like to
 change this.

 I was 1 of a very few users that encouraged Ken to make this MCI-able.
 I'm very glad to see it (and some of my other suggestions) made it into
 v2.61.

 I hope those SysOps that tried to discourage this idea DON'T use any
 of the *20* new, powerful MCI codes.  (One user even tried very hard
 to get me banned from ever posting VOTE topics again.  Yikes!)

--721--

SYSOP> User's are shown "Event will occur in 803 mins during log-ins.)

Yes, I agree with you, that text should only be displayed when the
events-time is within 10 mins, or so.  NOT it's current "ALWAY show
it".

Not only 'cleaner' displays, but we can add our own pfiles/arexx/dos
cmds to that BBSTEXT string, knowing that it'll only get displayed/
executed when 'events within 10 mins' are about to occur.

Should (or does CNet already) make a distinction between "Immediately",
"Clear-line", or "After-logoff" type events?  Would a CONFIG "Warning-User"
flag be desirable?  We could distinguish between major and minor events that
are about to occur and the SYSOP (not CNet) could control whether the user
even gets asked,  "Event in 10 mins.  Log in anyway?"

This would be very different from the current "Answer" or "Don't-
answer" flags.  Maybe making it a 3 cycle-gadget for "Answer" or
"Don't-answer" or "Answer w/option".  Let's face it, not ALL of our
events are going to fall into the current 2 choices:  "lock-out all
users" or "allow all users".

Also, does anyone think 10 mins is too long?  Users might just need
to do a quick 1-2 min mail check or something.  Should this be
shorter?  Or longer?  Should this MIN variable be settable on a per-
event basis?

All of the above are just ideas/suggestions/comments.  Not "MUST-HAVE"
necessities.

On another subject, mentioned LONG ago, I'd still like to see a "-1"
or "25" event's port, that would be executed regardless of whether or
not any of my 0-24 ports are running.

It is truly a shame to keep a full unused port running 24hrs per day
just to guarantee important events get executed.  On my 2-line system,
I regularly am opening/closing lines 0-2, so I have to keep a port #23
running, just for events.  I hope someone tells me this total waste of
memory isn't needed.  But I regularly use my lines 1-2 for running
terms and other things, so I can't guarantee CNet will be running at
the exact time of every event.

--722--
Whenever I move from MAIN to the PFILE menu, v2.61 gives:
>Users with your computer type may not enter that subboard

I haven't even entered (or tried to enter) a subboard.
Anyone else get this?

I'm running a stock v2.61 BBSTEXT file.

Did I forget to run something that converts pfile data?
         
R> BA> Whenever I move from MAIN to the PFILE menu, v2.61 gives:
R> BA> >Users with your computer type may not enter that subboard
R> BA> I haven't even entered (or tried to enter) a subboard.
R> BA> Anyone else get this?

R> Yes, go to Pfiles, type EL.  You will see that computer types defaults to
R> <none>.  Change this to the computer types you wish (probably 0-23)

Thanks.
I guess I just found it very odd that:
1)  "Forbid ANYONE using ANY type of computer" is the 'default'. (???)
2)  It controls access to that MENU, not SUBBOARD.
3)  I hadn't tried to "ENTER" any subboard, yet.

--723--
Ken, please consider having the online "AG" cmd, and/or "Idle-Screen"
also display "% of use avg".  (Like SYSINFO does.)

--724--
I always thought there should be a BIG distinction between:
1)  Do you want ANSI in the full-screen editor? Y/N
2)  Do you want ANSI for color and other text online. Y/N

I'd love have #1 without suffering (my opinion) through #2.

I think it would encourage more users to use nifty full-screen editors.

Those liking #2, would probably benefit also.  You wouldn't have to
worry about your excessive color or cursor-dancing games offending #1 users.

(Of course, you could certainly turn ON or OFF both, either or neither.)

--725--
Ken, please consider adding an MCI code that [E]nters the char
specified by the ascii value:
{E27} to generate ESC, etc.
{E1} to generate ^A, etc.
{E26} to generate ^Z, etc.

From remote, not all terms can generate/enter all values into msgs.

Many also can't be generated because CNet uses them for various purposes.

All 255 would then be possible.

--726--
>	In these same screens, the RETURN key may now be used instead of TAB
>	to move from one string input box to the next.
Ken, please consider doing this in the *20* string gadgets in CONFIG's
macro-keys, too.

--727--
RD> ... it would make
RD> everything you go over in reverse to let you know the block is marked then
DEFINITELY!!!!

And/or feedback prompts that help show things failed/succeeded:
Marked 23 lines, #1-23.
Pasted 12 lines, #10-22.
Copied 34 lines, #30-64.
Killed 19 lines, #7-25.
 
> Mouse positioning in the full-screen editor.
This is a good idea.  But heck, I'd settle for better, faster and more
familiar cursor-key moving, instead.  (Or both!)

Would anyone find any 1 (or more) of the following useful in aiding the
faster movement around the visual-editor?
 1) shift-left: move to beginning of line
 2) shift-right: move to end of line
 3) ctrl-left: move left 1 word
 4) ctrl-right: move right 1 word
 5) alt-left: move left to next 20/40/60/80th position
 6) alt-right: move right to next 20/40/60/80th position
 7) shift-up: move up 12 lines
 8) shift-down: move down 12 lines
 9) ctrl-up: move to top of screen
10) ctrl-down: move to bottom of screen
11) alt-up: move to top of file
12) alt-down: move to bottom of file
13) delete entire current line

(#3-4 and 13 are BIGGIES.  Badly needed.)
(#1-6 could also be supported in the line-editor and online cmd prompts.)

Some of these keys do the work of upto *20* current keystrokes.
(Not a bad improvement.)

Some of these are already supported by CNet.  I'm NOT suggesting the
cmd-keys that activate them be CHANGED.  But rather, added to.
(BOTH ^B and  #1 should do the same thing.)
(BOTH ^N and  #2 should do the same thing.)
(BOTH ^A and  #9 should do the same thing.)
(BOTH ^Z and #10 should do the same thing.)
User's could use whichever they like. (or both)

Some of these mimic DOS-CLI (and other editors/word processors)
editing keys that many of use and are already familiar with.  (Learn 1
set of keys, instead of 2.)

Hopefully all these would be usable via remote, but I'd even settle for
'local screen only'.  (Better than NOT having them at all.)

PB> the Delete entire line is already supported.
PB> Ctrl-K  will do the trick.  Thought you knew that.
Pete, that just deletes 'from cursor to end of line'.
I mean 'full current line delete'.  (in 1 keystroke)

I wonder how much 'over-quoting' is (in part) due to:
1) No single-key, quick 'delete line' cmd.
   (It takes 2 key strokes.)
2) No 2-key, quick, no submenu, 'delete block'.
   (It takes 4 keystrokes via 2 submenus.)
3) No 'delete range of line #s'.
4) You can't block-delete without losing the contents of your cut/paste       
   buffer.  (A BIGGIE!)
5) Can't specify 'include partial quote'.  
   (You currently have to include the FULL quote, then chop it afterwards.)
   (And my wordy-posts might be 100-200 lines! ;-))

(All are referring to the full-screen editor.)
 
I can't very well bitch at callers for over-quoting when *0* of
the above are possible.  (Ken, could you add a couple of these?)
 
--728--
If implimented, which would be a better way to do it?

1) Allow the SysOp create a NEWS dir (AL) and specify:
   CNet> "Flags required to add new items: 2,5,10,20"

2) Add a new per-user flag to every user's account.  
   CNet> "Add NEWS items: Y/N"

I'd be in favor of #1.  
A) You could control WHO.
B) You could control who by "groups", not 1-by-1 by-hand editing of
   individual user flags.
C) Limit them to WHERE (only certain NEWS dirs that you've allowed).  
   Or certain types of users, into certain types of dirs (public, CNet, etc.).
D) One less per-user flag to deal with.
E) You could simply change a dir's add-flags and instantly include/exclude 
   a totally different group of 100s of users.
(Try ANY of these 5 with #2.)   

If Ken adds this, I hope he appoints a handful of trusted CNet SysOps
to add to HIS News Menu.  Keep us up-to-date on important CNet things
WITHOUT having to read every new msg in every sub.  (Or wade through
all of Bill Allen's wordy, useless posts. ;-))

--729--
Ken, any plans on making the point&click cycle-gadget-like VDE
choices, more cycle-gadget like?  That is, have SHIFT-CLICK move
backwards through the list.  If you whiz by a 10 choice one like
ARCHIVE TYPE, you have to click 10 more times before it comes around
again.

--730--
>     81 Current Item #       (header, scan)
>     82 Current response #   (header only)
>     83 Total # of responses (header, scan)

Do the new MCI codes include one for "Total # of items in this sub"?
So we can do things like "Item 12 of 35".
I didn't see one mentioned.

--731--
Could we automatically alter our local screens (if they are already
open) into various color-modes based on the current caller's speed.
So you won't slow down the caller's output (or your system, overall).
(And save memory.)  But you can still have the highest # of colors
desirable per each speed.  A typical setup (yours may vary) could be
something like:

Switch to no screen if bps: 16800-38400
Switch to WB screen if bps: 0-2400
Switch to  2-colors if bps: 2400-9600
Switch to  4-colors if bps: 1200-2400
Switch to  8-colors if bps: 300-1200
Switch to 16-colors if bps: 0-300
Switch to x-colors when idle: 2 color.  (To save mem.  It's not doing
anything anyway.  Why waste 16-color memory on an idle screen?)

I don't know if Ken feels this is worth adding any 1-7 of these to
CNet's CONFIG.  Would anybody have a need?

CPU load and memory savings might start to add up with 4-12 line
systems.

--732--
UP250 currently changes the old MCI "\V8" into "{V47}", which should
be "total # of calls to system" .  (NOT by any 1 caller, but overall.)

When expanded, it just gives "-1".

Also, I can't find 47 (and several others) under any 'GetUser' OR 'MCI
lists' released to date.  (I know the new MCI now uses 'GetUser'
values, but apparently also some BRAND NEW, undocumented 'GetUser'
values were added where there weren't any existing MCI->GETUSER
counterparts.)

Ken, can we get your full, master Arexx 'GetUser' list?
(It would NOT have to include the XT##### codes.)

GetScratch, LoadScratch, GetUser, PutUser, etc, and, {V}, {T}, {L},
{M}, pfile %passing, etc all depend on this 'GetUser' list being
correct, complete, up-to-date, and available to us.

(That's some pretty powerful AREXX/MCI/PFILE values to miss out on,
due to old, missing docs.  And some pretty dangerous things to try and
'guess at'.)

If you had a gfile-menu choice that displayed your master list, (kept
uptodate as you changed CNet), we would NEVER have to ask for these
values again.  We could get the latest list ourselves, at any time.

--733--
Ken, please consider allowing the file MOVE cmd to be executed at places
in addition to the current "UD BASE PROMPT".  Two such places where
it would be MOST useful.
1)  When scanning/browsing for new files.
2)  When at that item's "Respond/Pass" prompt.
Currently we have to 'stop-down' while doing #1-2 to get back to the UD
PROMPT, note an item's #, and MOVE it by #, from there only.

Files ULed to the wrong areas can be a pain, and occur far too
frequently sometimes.  ANYTHING you can offer to speed this MOVE
process along, is greatly appreciated.  (The cmd is already
implimented perfectly, except for "where is it available?".)

--734--
     
 DS> Yep, it's a bug in the test MCI routine. also the Test for Maintenance is
 DS> curently 1234567890 and non-maintenance is 0123456789 (bug?).
 Mike, please explain this.
 
 I hope this isn't a bug.  Some of us are relying on 'Test for Maintenance'
 to do much more than just 'show maintenance cmds?'.  (ie:  Like,
 '*GIVE* access to powerful cmds'.)

This is NOT a slash against the beta-testers, but:
1)  5-10 SysOps can never debug/test as well as 100s.
    (They just can't.)
2)  Handling 100s of callers/msgs/transfers/etc won't find bugs
    as well (or as fast) as 10,000s of callers/msgs/transfers/etc.
    (It just won't.)

--735--
Daisy-chain, locally:
Until we see more 14-24 line systems (currently I think there are 0,
worldwide), I don't think we need 25-48 line power.

Daisy-chain, remotely:
YES!  Join-Link (JL) starts this idea, but only with group-chats.
Maybe Ken will expand this idea in steps:
1)  Fully automate JL connects via events.
    (See my KEN.LHA file for more info.)
2)  A caller can execute a BBS cmd, it is sent to the remote system,
    the results are sent back.  (FINGER, FIND, INFO, WHO, etc.)
3)  Private mail can be sent between remote systems.
4)  Public msg bases can be read.
5)  File areas can be scanned.
6)  Public bases can be replied to.
7)  Files can be uploaded and download.
I'm guessing, but that's probably listed in the order of 'difficulty to do'.
(Easiest things first.)  #1 would be GREAT even if JL is NEVER expanded.
#2 sounds INCREDIBLY easy to do.  (We'd need a way to mark which BBSMENU
cmds are also available from REMOTE JLs.)

Or maybe a totally different method should be pursued...
When a caller uses TERM to call out to another BBS, a few other
callers can 'jump-into' the connection.  Each can do different things.
The connection will probably be slowed slightly during file transfers,
but 9600-14400 should be able to handle the narrow-bandwidth needed
for a handful of callers to independently chat, read, write, search,
etc, simultaneously.

We'd also need better control over which phone #s can be dialed-out.
(But we need that NOW! even if 0 other things are added to TERM.)

--736--
2.61> 189 The "notify uploader at download" feature may now be defaulted to
2.61>    "on" for all new uploads.  This new flag is found on the subboard
2.61>    EL screen.  Also, the "mail" that uploaders receive will now contain
2.61>    the number of file/byte credits that were rewarded.

(CNet already supports some of the following...)

Yes, it is starting to look like this and nearly every new/old
individual per-file variable should have an EL per-sub counter-part.
All uploads to a sub would pickup that sub's defaults.  You could then
tweek (or not-tweek) those defaults on an individual per-file basis,
if you wanted.

Otherwise, we'll always be subjected to either 1 problem or the other:
1)  Per-file only: SysOps have to go in and edit each file 1-by-1.
2)  Per-sub  only: Constantly having to move files in/out of certain subs,
                   because the whole sub had to be set as "free/
                   private/frozen/favorite/AutoGrab".
The per-file settings would override the per-sub settings, unless the
sub's 'override' flag was set.  It's a shame if this is getting overly
complicated, but I think things can still be kept "clear but powerful".

--737--
Wouldn't it be pretty unlikely that any BBS would need 2 (or more) QWK
UL areas?  Yet every base-sub and UD-sub has a flag for it.

Couldn't this be better handled by just a single value in CONFIG:
> Physical # of QWK sub: 34

You won't be able to turn it on/off from remote, but how many times do
you anyway?

Eliminates 100 flags, if you have 100 subs. 

Or am I missing the point (again) here?

--738--
This is just a suggestion for a different 'real-world' type of [W]rite
filenote description...

A caller ULs a file, its short filenote is either:
1)  Incorrect or vague.  OR...
2)  Nonexistent.

If #2, then CNet automatically turns on a flag for that file known as
"Describe for credits".   If #1, then the SysOp can manually/optionally
can turn it on.  In either case, once on, it also does several other things:
3) APPENDS onto the current filenote, a line from BBSTEXT.  (Something
   like, "Describe this file and be awarded its UL credits".)
4) Auto-mails the ULer a line from BBSTEXT.
   (With the new file-MCI codes available.)
     MAIL> Your UL has a missing/incorrect, or vague filenote.
     MAIL> FILENAME.LHA    388K    A really great file to have.
     MAIL> Please better describe it to be awarded UL file/byte
     MAIL> credits.  (or other callers will)
5) The "WRITE" cmd will work differently, but just for this 1 file,
   with the new "describe-flag" set.
   a) Anybody can [W]rite.
   b) The editor is placed into the 40(?) column mode,
      like it is after an UL.
   c) Using it, will post the text as a REPLY, not alter the existing
      filenote.
   (For items without this "describe for credits" flag set, WRITE will
   instead, work as it does now.)

Other callers are then free to [W]rite *REPLIES* onto that item, each
offering what they feel will be the better file description.

6) Afterwards, the SysOp (SubOp/maintenance person) can execute a new
cmd at the "Respond/Pass" prompt that will move/kill the text from any
one reply into the short filenote's place, replacing it entirely.

7) The author of that 'moved reply' then gets the UL credits.
8) The original ULer is auto-mailed a different line from BBSTEXT.
   (With MCI codes.)
     MAIL> Your upload:
     MAIL> FILENAME.LHA   388K   A really great file to have.
     MAIL> was better described by another caller as:
     MAIL> FILENAME.LHA   388K   A pong-type game v1.32 by John Doe 02Feb93
     MAIL> He was awarded your UL file/byte credits for it.

(The whole above process could also be used for "adopted orphans", but
without the auto-mail.)

Yes, I do think accurate, descriptive, correctly spelled, filenotes
are worth all this special attention and effort.  Without them, who
knows what to DL?  And it's just too time consuming to expect a lone
SysOp to unpack, read, identify, describe them.

Ken, if you aren't sure about going 'whole-hog' on this idea, maybe
just try it out by adding #6, for starters.  And see how things work
out.  (The rest can be done 'by-hand', but it would be slick to have
CNet do all (or some) of it automatically.)

--739--
Bob, are you open to suggestions?

Would it be possible to have the software check/add/remove the needed
"/" from the path?  I have several DOZEN programs that specifically do,
or specifically don't, need it.  I always have to refer to the docs to
remember which are which.  The software could just 'add-as-needed' and
it would never be an issue again.

Also, any plans on allowing files to be added to a callers list
while he's online?  (ie: effect his list's POINTER)  I hate to chat
someone and tell them, I can add that file for you, but you have to
hang-up and call back in 10 secs, though.  (At LD rates from Europe.)

--740--
Ken please consider adding to the {@} MCI enviroment variable to
include RAW I/O, Echo Input, and CR/LF Translate possibilities.

If you need any of those turned on, you are limited to pfile-menu use
only.  NO MCI via text files, NO BBSMENU use for placement anywhere,
no place but the pfile-menu.

Without this new {@}, it could very well forbid the use of a DOS-pfile
from a certain prompt, entirely.

--741--
Maybe 1 (or more) new MCI codes?
How many mins until the next 'don't answer' event starts.   (or ends).
How many mins until the next 'answer' event starts.   (or ends).
How many mins the user will be 'shorted' due to a upcoming system event.

Would could show users text like:
> The system will stop accepting callers in 12 mins.
> Please call back in 17 mins.
> The system will begin doing maintenance in 3 mins. 
> Your time is reduced from 90 mins to 75 mins due to an upcoming event.

Instead of the current:
> Please call back "later".  (Whenever that is.)
> You may experience a slowdown in the system if it might be
> doing maintenance during your call.
The system will tell them that their time has been cut, whether you
want the caller to know, or not.  Or if a '10 min loss' notification
is 'enough' or 'too much'.

And remember, in addition to just displaying the above variables, the
new, powerful MCI can {TEST} variables against set values.  You can
have the system automatically decide to display or not display the
above strings depending on how close you are to the actual event times.

--742--

Is anyone else having problems with XMODEM ZIP upload of msgs through
the visual editor?

I always lose the 1st line of my post.
All the rest of the text appears fine.

--743--
I hope Ken's not going to change the existing 1/10ths mins MCI
variable.  Many of us changed our code and text files counting on this
ALWAYS being 1/10ths.

Considering its popular use, maybe Ken will consider adding a 2nd (separate) MCI
code for 'whole-mins', just for this 1 variable.
> You have 84 mins left.

Or maybe even a 3rd:
> You have 1:34:03 left.

It gets pretty lenghty to do it with MCI math.   And 'mins remaining' is
a pretty commonly needed variable to display.

--744--
Here's an idea I don't think anyone but me will like.
And I'll never, never, never get Ken to go along with it, but here
goes anyway...

CONFIG>  Use physical #s throughout: []

If clicked "ON", all your subs/msgs/files/gfiles/pfiles/votes/and
everything else that is currently numbered in real-time, will
instead be numbered by its physical-internal number.

This is for four reasons.

1)  So that users with a lower access level will see that they are
missing out on A LOT of things.  They'll see subs/msgs/files/gfiles/
pfiles/votes listed as "1,2,3,7,12,13,45,243..."  And be greatly
encouraged to gain higher access.

2) Systems won't look so barren to 1st time callers.  They'll see subs
(and everything else) numbered like 1,13,145,390 and know this is a
GIANT system.  Not the current 1,2,3,4.
"Oh, just 4 small file areas.  1-4"

3) So that item #46 will ALWAYS be item #46.  You can count on it
always being right where it was yesterday.  It won't change by next
week.  (Or in many cases, it won't change EVERY time there's a new UL.)
You can refer other users to all things by an absolute #.
> Try pfile #5.
> Be sure and read item #12 in sub #7.
> That info you need is in gfile #14.
> That file is in sub #5.
> Post that in sub #24 only.

4) Searching cmds that look for a file/item/sub can tell you EXACTLY
which sub # to jump to and which file # you are looking for.  (Yes,
sub-searching.  It's getting to a point where we'll need a FIND-SUB
cmd on those giant CD-ROM systems.)

I don't think any of this is possible with CNet's default, real-time
numbering system.

I feel, the lack of this non-real-time #ing feature is one of the
MAJOR things that new-users (and some old-users) find "odd" about
CNet.  I've heard CNet referred to as "The BBS from Mars" on more than
one occasion in the Fidonet/Usenet bases.  (Their words, not mine.)

I don't know how hard this would be for Ken to impliment.  CNet
definitely knows which physical-internal # it is at, at all times.
Otherwise it wouldn't know what info to display next.  It just doesn't
tell the user this #.

Ken is seeing how important this is.  v2.60 refers to its per-sub-
voting by physical-internal #s.  I don't think this feature could have
even been done without this 'absolute-reference' internal #.

--745--
>Respond or Pass: D
>Sorry, item 2 is a post, not a file.
What's the quickest, simplest way to DL the text in an item or response?
(Or ANY way?)

Some are lengthy and well worth saving.
I'd love to just quickly [D]ownload them with error free Zmodem.

(Or in the local-mode, "Copy to path:".)

--746--
This is for the MANY people that are having trouble/confusion with
{V7} displays.  It's not a bug.  V7 has been changed (totally
unannounced) from 'whole-mins' into 'tenths of a min' as of v2.60's
new MCI codes.

Tenths of a min: {V7}

1) To show in whole mins (34 mins)...
Clear variable: {L60 #0}
Divide by 10  : {M60 7 #10 / +}
Show it       : {V60}

2) Or if you want 1/10th min accuracy (34.2 mins)...
Clear variable: {L60 #0}
Divide by 10  : {M60 7 #10 / +}
Clear variable: {L61 #0}
Mod by 10     : {M61 7 #10 % +}
Show it       : {V60}.{V61}

3) Or if you want 'time' format (1:23:31 left) (clearer than 492 mins)...
Clear variable: {L60 #0}
Math for hrs  : {M60 7 #600 / +}
Clear variable: {L61 #0}
Math for mins : {M61 7 #10 / +}
              : {M61 #60 % +}
Clear variable: {L62 #0}
Math for secs : {M62 7 #60 * +}
              : {M62 #10 / +}
              : {M62 #60 % +}
Show it       : {V60 %s}:{V61 %02s}:{V62 %02s}

Any 1 of the 3 would be lot of extra coding to stick in MANY prompts/
text-files/menus etc.  I hope Ken adds (NOT replaces) an additional
MCI code.
Whole mins left: {V##}
Much simplier.

(If anyone knows RPN math, how does it work?  How would I do the math
shown below, in one RPN step?)

Ken, you r-e-a-l-l-y want CNet's powerful MCI-math forever stuck with
RPN, instead of 'normal' math???

> {M60 ((70/10)+60)*2}
Could anything be shorter, more readable, easier to write, more
complete, more universally accepted and understood, without any
special lessons or instructions in RPN math?

Does RPN do great things that are impossible with 'normal' math?

--747--
When you SCAN your waiting mail, would anyone like to see 1 (or more)
of the following markings in addition to the current "* for new"?

 1) "  " old private mail (non-carbon copy)
 2) " P" old party-mail
 3) " B" old bulk-mail
 4) " C" old carbon copied from a public sub
 5) " F" old carbon copied from a Fidonet sub
 6) " U" old carbon copied from a Usenet sub
 7) " D" old download-able file attached
 8) " *" new private mail (non-carbon copy)
 9) "*P" new party-mail
10) "*B" new bulk-mail
11) "*C" new carbon copied from a public sub
12) "*F" new carbon copied from a Fidonet sub
13) "*U" new carbon copied from a Usenet sub
14) "*D" new download-able file attached
15) " R" you already read the actual post in the subs
         (In case you want to avoid re-reading this carbon copy)
16) " A" you already answered (replied to) this letter.

Or at least #4/7/15/16 added onto the current #1/8.

Or if this is too cryptic, maybe the actual words (FIDO) (USENET)
(PARTY) (BULK) (PUBLIC) (PRIVATE) (REC) (REPLIED) can appear after the
scan's subject.

A quick SCAN could really give you a lot of info, before you even
start reading your first letter of the day.

--748--
CNet goes to amazing lengths to allow *SYSOPS* to custom things.  But
maybe a little more could be done from the CALLER'S viewpoint, too.
(There's a 1000x more 'callers' than there are 'sysops'.  Let's not
forget about them and their needs.  They're the reason BBSes exist.  A
BBS without callers is pretty dull.)  CNet currently has about 5 flags
that users can set themselves.

Maybe some per-user flags could be added.  (4 bytes can store 32 new
flags.)  Does anyone like/dislike 1 (or more) of the following?

CNet> "EP"
CNet> 15) Edit MACROS                16) Configure USER flags
CNet> 16
 1) Do you wish to preview 1 previous msg during new-scans:
 2) Do you wish to preview YOUR previous msg during new-scans:
 3) Do you wish msgs/files/sub/n/g/pfiles to be numbered by physical #:
 4) Do you wish to be asked for a protocol-change before EVERY UL and DL:
 5) Do you desire "Quick log-in":
 6) Have [L]ist show subs you've [D]ropped:
 7) Show 'new msg/file counts' for [D]ropped areas:
 8) Flush input-stream before each prompt:  (Line-noise helper.)
 9) Turn off all cmd Y/N verification without a need for "!":  (for the REAL pros)
10) Suppress all intermediate text output during cmd-stacking:
11) Does your term support mouse-click and movement:
12) ANSI usage within the editor:
13) ANSI usage outside the editor:  (YES, #12-13 should be separate flags.)
14) Edit data via VDE or "text question lists":
15) Receive party-mail:
16) Skip Mail-Read of Carbon-Copy items already marked RECEIVED:
17) Skip Base-Reading of Carbon-Copy items already marked RECEIVED:
18) Receive carbon-copies of local posts:
19) Receive carbon-copies of Fidonet posts:
20) Receive carbon-copies of Usenet posts:
21) Filter all screen-clear codes:  (A personal pet-peeve of mine.)
22) Skip "UNVALIDATED" file headers:
23) Skip "PRIVATE" msg headers (in public bases, addressed to other users):
(I've compiled a list of 179 (and counting) other user-flags.)

(#5 would be used as an MCI code in custom log-in text files to
replace the frequently ask "Quick Log-In" that many SysOps now use.)

(#18-20 would avoid having the same msg waiting for you on 50 different
systems you might call.)

I'd set mine to NNYNYNNYYYYYNYNNYY.
But each caller could config 32 flags in any of 4,294,967,296 different ways.
Pretty flexible BBS.

It is great that the SYSOP can set some of these, or great that the callers
are asked some of these questions each time, but for these harmless
"user-preference" type choices, there's just nothing better than:
A)  Let the caller himself decide, not the SysOp.
B)  Save these preferences to disk, so the caller doesn't have to answer
    the same questions over and over again for each call.

(Actually, I'd like to see #4 be made obsolete by combining...
> Use your default protocol Zmodem [Yes]?
> [L]ogoff upon completion, [A]bort, [Begin]?:
into 1 prompt:
> [L]ogoff upon completion, [A]bort, [P]rotocol, [Begin]?:

THINK OF CONFIGURATION FROM THE CALLER'S VIEWPOINT, TOO.

As an additional benefit...
I wonder how many non-CNet SysOps, call CNet BBSes and say to themselves:
"`ET' and `EP', look at what a primitive BBS this is."
Not knowing what powers (40-64 flags) are available from the *SysOp-
only* side.  "Expanding user-flags" would show 10000s of callers (and
maybe a few perspective CNet SysOps) some of this power.

--749--
Trying to send MM MultiMail to ALL users...

>Enter route file name [none].
>Enter access group range [all].
>Enter ID# or Handle of user to INCLUDE.

I hit RETURN at each of the prompts, which should give me:
"no specific route file of just 'some' users",
"All access groups",
and not specifically "including any 1 user".

0 copies are sent.

If I specify 0-23 for 'access group', all works fine.
But "RETURN" isn't getting the bracketed "[all]" default, as it should.

--EOF--

-Friday 05-Mar-93 15:54:26
-Bill "Mr. BBS" Beogelein, 313-473-2020, 2-line HST 14.4k USR DS, 1:2410/207
