
Monday 11-Jan-93 04:30:14

--550--
Regarding the current "monitor another port feature"...

Would there be a way for me to invite a user into my node instead
of moving into theirs?

Instead of trying to explain how to do something, I could invite them
over and run them through it "in person".

If I jump to their port, I can only do what their access, flags,
ratios, privileges allow.  (As it should be.)

--551--
Ken, for those of us running CNet in window-mode, would it be possible
to change the windows from SMART-type to SIMPLE?

If you enlarge/resize the window, the text will expand to fill the
newly available space, allowing you to see text that had been scrolled
off the top of the window.

(Now that CNet & WB2.0 allows us to create windows with widths/heights
of 100s of columns.)

--552--
User Confuser...
CNET> (94) Browse (*, Download, Read, Quit)  ?
CNET> Unknown command "?" ... enter ? for a list of commands.

I can change it in my copy of CNet, but Ken might want to change
it on the distribution disks, too.

--553--
TP> How do I set the min-level of EP;9 without effecting the EP command? In
TP> other
TP> words, how do I prohibit use of EP;9 and still allow users to use the EP
TP> command?

It would require Ken to add a new menu onto BBSMENU and individual
1-15 choices, 1 for each element of EP.

Might be handy, might be overkill.  What do others think?

You could set min-max access limits on individual EP elements.
Even replace 1 or more with your own arexx/dos/pfiles.
Alias cmds, [S]ignatures could be "S" or 13.
Editor choice could be "E" or 10.
Protocol could be "P" or 4.

--554--
DS> BA> You could even go as far as letting each caller edit his own
DS> "_fdisplay"
DS> BA> file in his home dir.  Then EVERY caller to EVERY CNet BBS could
DS> BA> have his own custom filelist display.
DS> This sounds like Excelsior:)  The user has several options to choose from
DS> for Message display & File display formats.

But not 'each caller creates his own format style'.
I've not seen ANY Amiga BBSes do that powerful feature.
(Giant UNIX BBSes have it.)
It would be another CNet 1st for Amiga BBSes.

By 'each caller creates his own format style', I mean:
Each caller can call up the editor, and create his very own file
containing the actually MCI codes that get expanded into the file
format.  If he chooses not to do so, CNet's internal format is used.

You could even show a user 1 of 100s of "_fdisplay" files that other
users have already created.  Let them pick 1 of those.

All of the above might be overkill, though.

I think if Ken picked a handful of the most liked filelist displays,
and let each caller pick 1, that would do it.

But what would be concidered "the most liked filelist displays"?

Any kind of choice for the user would be better than the
current "just 1".

--555--
S> (not sure for the width) of space to put the description of the file. So
S> this
S> permit to runners (or the sysop) to put some nice logos of the group who
S> originatly spread the file... It is SO important that so many sysop will
S> sacrifice the ease of use of a programm like c-net just to get this file
S> listing format... Just that is my major "must have"...

But what are these 'nice' 44-column logos going to look like when
we 'read' (not scan) items and they get displayed at 80-columns
(as it should be)?

>Info: *|+|# # # # # # # # # # # # |+|* *|+|
>|+|* *|+| ThIs FILe wAs uPlOaDeD |+|* *|+| bY ThE GrEaT AnD
>aLL   |+|* *|+| PoWeRFuL wIZarD oF oZ! |+|* *|+|
>|+|*

--556--
What ever happened to the idea of 'alternate sub list displays'?
(The ability to display a text file instead of CNet's built-in [L]ist
generator.)  Then your suggestion could be done with a small arexx script.
(And 100s of other formats would be possible, too.)

--557--
Yikes, I .A'borted that last response and got:

> CNet/3 LineEditor:
> Enter up to 250 lines--enter .H at column 1 for Help, or .S to Save.
> Only press ENTER when beginning a new paragraph.
>
> Command:Abort
> Response filed.
>
> More responses. Respond, Pass or ENTER to continue  ?

I just had to try it again:
> Command:Abort
>
>
> Lose all changes [No]? Yes
>
> Response filed.
And it clears the buffer and posts an empty msg.

--558--
What is causing some of my responses to have headers like:
> #66/76 from: Bill Allen
>        to  : 1
>        on  : Thu  7-Jan-1993  7:28p

> #67/76 from: Bill Allen
>        to  : 1
>        on  : Fri  8-Jan-1993  7:29p

But others show the full name:
> #68/76 from: Bill Allen
>        to  : Big Brother  (Ken Pletzer)  *RECEIVED*
>        on  : Sat  9-Jan-1993  9:20a

(I think they should never just show the user's #.)

--559--
How about having the current short-list displayed automatically, but
if the user specifically hits "L", he gets your long-list?

Or maybe, "L" gets the current short-list, and "LL" gets your long-list?

I like the current 2-column format.
It actually has some room to display some of your suggested additional
info, and still keep its 2-column, 48 (not 24) titles-per-screen power.

--560--
Ken, very good to see the CPS and longer filenotes, if you are going
to expand CNet's file structure, perhaps you could consider a few of
the following.

Even if CNet does absolutely nothing with them for now.
(Great for future expansion without a need to expand the structures again.)

Even if CNet NEVER does anything with them.
(Great for our own pfile and arexx script usage.)

(Some of these are already available with CNet, some don't even apply.
It's my own '"complete" list of possible elements'.  Some are NOT
available on ANY Amiga BBS software.)

SHORT AccOverride  :1; Can DL this file even if lo-access-level prevents it
SHORT AddComments  :1; User's can add their comments onto file desc
SHORT AlwaysNew    :1; Always listed as "new" in file scans
SHORT Anonymous    :1; Display "Anonymous" instead of ULer's name
SHORT ArcOK        :1; True if archive passed archive integrity check
SHORT AuthorULed   :1; File ULed by the actual, original author/artist
SHORT AutoDL       :1; File is File Requestable by actual disk name
SHORT AutoUL       :1; File was received by ADS or like
SHORT ComputerType :1; For certain machines (# matches "user's computer" #s)
SHORT DLnotifyULer :1; ULer gets email each time this file is DLed?
SHORT DLnotifySysOp:1; SysOp gets email each time this file is DLed?
SHORT FreeBytes    :1; Size added to free bytes DLed, not non-free
SHORT FreeFile     :1; 1 added to free DL count instead of non-free
SHORT FreePoints   :1; DL points added to free DL points, not non-free
SHORT FreeTime     :1; DL time added to free DL time, not non-free
SHORT FreeAcc      :1; DL is free even if user access level prevents this DL
SHORT Incomplete   :1; UL aborted, needs to be resumed
SHORT IsArchive    :1; Packed w/recognizable archive type for view/extract
SHORT IsReadable   :1; After UL, file was determined to be readable text
SHORT OffLine      :1; File still available, but currently offline
SHORT KillRequest  :1; Delete this file ASAP
SHORT OnlyOnce     :1; 1st DL will automatically kill this file
SHORT OnlyOnceAsk  :1; 1st DLer will be asked if kill-file is needed
SHORT ReplaceByAny :1; Any ULer can kill file if newer version is ULed
SHORT ReplaceByOwn :1; Original ULer can kill if newer version is ULed
SHORT Valid        :1; Is file valid or has it been deleted

USHORT AreaNum;         File area # (for faster finds of actual file)
struct Date CompiledOn; Author compiled/wrote file on this date
struct Date DLableFrom; File can be DLed on/after this date/time
struct Date DLableTo;   File can't be DLed after this date/time
struct Date FirstDL;    Date/time of first  DL
struct Date LastDL;     Date/time of latest DL
struct Date PurgeOn;    This file automatically purged on this date
struct Date ReplaceOn;  Any UL to this area after this date kills file
struct Date ULdate;     Date/time of UL
struct Date ValidatedOn Date/time file was validated (0=unvalidated)
ULONG  NumDLs;          # of times DLed
UBYTE  FileName[20];    File's name, catalog name == actual disk name
ULONG  FileNum;         File ID # (for faster finds)
SHORT  FilePoints;      If DLed, add/sub +/-32768 to user FilePoints
UBYTE  Keywords[48];    Keywords describing this file
ULONG  Length;          Length of file in bytes
USHORT LongDescLen;     Length of long description (0=none)
ULONG  LongDescPos;     Points to position of long-desc in data file
UBYTE  MultiDiskSet;    This is disk # x in of a multi-disk set
UBYTE  PasswordNum;     Needs password # n in password.dat file to DL
UBYTE  PrivLevelDL;     Privilege level needed to DL this file
UBYTE  PrivLevelList;   Privilege level needed to even see this file in scans
USHORT ByteRatio;       If file is removed by SysOp, so are your bytes-credits
USHORT FileRatio;       If file is removed by SysOp, so are your files-credits
USHORT PointRatio;      If file is removed by SysOp, so are your point-credits
USHORT RewardsFile;     Reward ULer x file  credits each time file is DLed
USHORT RewardsByte;     Reward ULer x byte  credits each time file is DLed
USHORT RewardsPoints;   Reward ULer x point credits each time file is DLed
UBYTE  ShortDesc[100];  Short description of file
UBYTE  ULer[32];        ULer name or alias (Even if Anonymous flag=YES)
ULONG  IDvalidater;     ID # of the user who validated this file for DL
ULONG  IDdescriber;     ID # of the user who described this file
ULONG  IDkiller;        ID # of the user who requested this file be killed
ULONG  IDfirstDLer;     ID # of the user to first DL this file
ULONG  IDlastDLer;      ID # of the user to last  DL this file
UBYTE  Version[8];      UL's version # as string:  "v1.0" "v2.123x"
UBYTE  Padding[80];     Padded for future expansion and long-word alignment

Anyone have a few suggestions on which would be handy?

--561--
Vote topic posted Wednesday 13-Jan-93 19:03:37...

Would you like to see CNet's author write a custom, external FrontDoor
to support Fidonet/Usenet?

(There would be a small additional charge, but only if you chose to
purchase this optional add-on.)

1) CNet's custom, external FrontDoor.
2) I'd still buy/run TrapDoor instead.
3) I will never run Fidonet/Usenet.
4) No comment. Other. I don't understand.

--562--
Suggestion #562...

When adding a new vote topic,
1st)  Add the topic.
2rd)  Add the question.
3rd)  Add the choices.
(It is currently done 1-3-2.)

Could the max length of each response be increased?  From 35 to 80 char?
Shouldn't cost too much disk space.  It is sometimes difficult squeezing
things into 35 chars while remaining clear.

Could you include the vote structs in the next cnet.h file?

Could we set the min-max access ranges at time-of-post.
(No need to re-edit the vote item afterwards.)

Also,
Would anyone have a need for a new type of post known as a vote-post.
Callers could set a VOTE-FLAG on their posts or responses.
At the "Respond, Pass or ENTER to continue" prompt you could also cast
a Y/N vote on whether or not you favor/disapprove of that suggestion.

It's similar to the voting booth, (maybe it could even share many of
its C function calls) but doing it in the bases allows full
discussions to take place.  And after voting, the results would be
shown.

> Respond, Pass or ENTER to continue: Y
> Voting YES...
>
> 62 voted YES  (82%)
> 14 voted NO   (18%)
> 76 votes cast (34% of the users)
>
> Respond, Pass or ENTER to continue:

As always, Ken, thanks for listening.

--563--
It just scares me when I see software that uses filenames like
"SysData:BBSList/!!!00000000000000", instead if something more
informative.  (An actual CNet filename, still in use today.)

It would have worked just as well if named "SysData:BBSList/BBSlist.dat".

--564--
Can someone please post (or UL) the 'struct ItemType' template used in v2.42e?
I can't find anything newer than the one in a cnet.h v2.40e back from
an Oct.92 release.

I didn't see a Programming dir (and sometimes not even a
disk #2 at all) on my last few updates.  I had to go all the way back
to v2.40e to find:
>cnet.h                     40184 ----rwed 30-Oct-92 16:27:50
From Oct.92.

That is the current header for v2.42e?  Including the current cnet.h in the
archive can be extremely important to programmers.

All of my ItemType flags are appearing shifted 2-4 bytes off, so I was
thinking that I had an old structure template.  (Maybe I'm just counting
the offsets incorrectly, but I've re-counted them a dozen times, so I
don't think so.)

--565--
'Point-ratio' idea...

User's can easily get around strict file-ratios by specifically U/Ling
many small files.  (ie. breaking a 20 font collection up into 10 sets
of 2 each.  Or just specially ULing small files.)

User's can easily get around strict byte-ratios by specifically U/Ling
giant files (ie. include a full WB disk on a DMS U/L when the non-WB
files themselves only represent 20% of the disk.)  (Or use inefficient
file compression.  Or just specially ULing big files.)

User's can NOT get around a point-ratio so easy.

A point-value 0-255 would be assigned to each file.
(It would pick-up the default set for that sub.  But could later
be changed when the sysop validates the file.  Or even after that.)

It would be what the SysOp thinks that file is truly 'worth'.
For ULing it, you gain x points.  Each time someone else DLs it, it
'costs' them x points.  UL giant files, small files, few files, or many
files, it doesn't matter.  If your total file-point credit is 147, you
can only DL other files that total 0-147 points, too.)

Byte-ratios would remain a pay/cost method based on file size.
Count-ratios would remain a pay/cost method based on # of files.
But point-ratios would be a unit of file "quality".

As always, if you didn't need point-ratios, the SysOp wouldn't have to
impliment them.

--566--
Regarding rewards to uploaders...

I wanted to avoid 1 big pitfall.  That is, users that UL something
under 1 acct and DL it dozens of times under a 2nd, just to build-up
the 1st accts credits.  (So the rewards that #1 gets, should never
exceed what it 'cost' #2 to DL.  I hope that will help discourage the
pitfall I mentioned.  Users won't really gain anything by using up BIG
credits, just to gain SMALLER credits.)

So I guess just base it on a +/- percent value.

Each time the file is DLed, the ULer gains/loses x% of that file's
size as a reward.

0%   No reward.
50%  ULer gains 50% of file's size.
100% 100% of file's size.
200% 200% of file's size. (But "The Pitfall" could occur.)
(I think most SysOps would use 0% to 25% ranges.)

-25%  ULer actually LOSES credits (If your file is a commericial
      advertisement, chain-letter, or undesirable file.)
-100% Automatically penalize folks that UL old releases.
-200% Really penalize folks that ULed hacked version #s, non-working,
      over-exaggerated claims in file descriptions.)
(If you ULed a file that 45 people just wasted time, credits and $$$
DLing, it just cost YOU big credits.  All automatically.)

The above method could only cover file BYTE rewards.  (And file POINT
rewards, if implimented.)

File COUNT FILE rewards would be trickier because you can't really
grant "50% of 1" towards the uploader's FILE COUNT ratios.  (I
wouldn't recommend getting into, "You can now DL 7.34 files".  But I
guess it's possible to count file CREDITS to the nearest 10ths or
100ths place.)

Each base would have a 1-2 percent values:
1) BYTE
2) POINTS (if implimented)

And 1 whole # value:
3) COUNT (if you decide to go with it.  I guess it would just be a value
-x to x.  Each DL gets the ULer +/- file COUNT credits.)
(Most SysOp would use 0 to 1 settings.  Settings >1 could also lead
to "The Pitfall".)

Each file to that sub would pick-up that subs default.
(They could later be edited on a per-item basis by the SysOp.)

Each file would need a value that tracks how much total rewards have
been paid to the ULer.  (When the SysOp kills the file, he would be asked:
> Bill Beogelein was paid 234k in DL rewards, remove [0%]:
Where you could enter 50%, 100%, etc or just hit RETURN to not
subtract anything.

I was hoping we could kick this idea around, before it gets fully
implimented, because I'm sure I'm missing some important point(s).

I guess first decide whether these rewards are going to be based
on BYTES, POINTS, COUNTS, or a combo of 2 or 3.

               --------------------------------------

Recapping....

If you wanted to simultaneously allow use ANY/ALL 3 of 3, then each
sub needs:
>Reward BYTE  value:  (as a %)
>Reward POINT value:  (as a %)
>Reward COUNT value:  (as a whole #)
Every UL to this sub would pick-up these defaults.
(They could later be altered on a per-item basis via a VDE "edit
ATtribute" cmd.)

Each user would also have 2 flags that would turn all rewards ON/OFF
entirely, at the flip of a switch.
>Rewards:   Toggles ON/OFF.  (For increases.)
>Penalties: Toggles ON/OFF.  (For descreases.)

--567--
> How do I get the logs working?

Run CONFIG, click on LOG.

Move the slider, pick a cmd.  Assign it a 'type-number' (User Log Flag) 0-31.
For example, you can assign:
Type #0 cmds are KillMail, EditItem, EditTerm...
Type #1 cmds are Finger, BBSlist, CC...
Type #2 cmds are Join, MoveItem...
Type #3 cmds ara Vote, ReadMail...

Online, edit any/all user's log-flags to 0-31:
User #492 will have all Type 3, 19, 27 cmds logged.
User #213 will have all Type 1, 9, 17 cmds logged.
User #981 will have all Type 7, 21, 29 cmds logged.

This cross-reference method is extremely powerful.  Pick the EXACT cmds
you want logged, group them together, then pick EXACTLY who logs them.

I wish more areas of CNet supported this kind of method.

Also, there's a few things you can't do.  So before you ask, you CAN'T:

1) Click on HELP (or use HELP-key) in any/all CONFIG screen.
(Hopefully someday it'll just open a window and display an text file.
You could make the text file as simple and clear, or as complex and
indepth as you wanted.)  (You probably wouldn't have had to write/post
for a question, then wait, nor I write/post an answer.)

2) Find "NewVote" (it's still erroneously called "NetVote"), but DOES
work.

3) Sort the LOG-HANDLE names alphabetically, so you can find them quickly.
   (Or sort ANY list-gadget elements.)

4) Log-flags can be:
   a) "Log only when calling from remote"
   b) "Log when calling from local or remote"
   but not, the 3rd, which would complete the 'set':
   c) "Log only when in local"

5) Can't hit WB2.0 style _U_nderscore keys as gadget equivalents.

6) Immediately change all values in real-time.

7) Change ANY config values from online, as we could in the past.
   (Ken's menu-based or VDE-based editors.)

8) Change many system-variables like:  Total # of calls, etc.

9) Have each node appear in a different color (as we could in the past).

10) Call config from the Control Panel.

11) Have CONFIG open on a public screen.

--568--
I consider the "+" and "-" markers on the sub name-list ("L") to be
VERY important.  Since those are the only dirs that get scanned, you
could be missing out on 100s of new file-listings, if you have them
set as JOINed/DROPped incorrectly.

It's a shame we lose ALL "+" "-" markings for ALL areas that have new
items.  (On heavily active BBSes that could be 50%-100% of the dirs
you scan.)

All that would need be done is to display "*" AND (not, instead of)
the important "+" or "-" markings.  (If neither "+" nor "-" appeared,
that would designate it's 'invite-only' and you haven't been invited.)

> 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

OR (arranged differently):
> 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

On non-dirs, there's even room to add "(UD)" (Upload/Download)
access markers, too.  So you'll instantly know where you can UL and DL
without joining tons of subs just to find out you can't do one, the
other or either.

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

Instantly, ALWAYS tells which areas have:
 1) New files, you can UL, you can DL, you've JOINed it.
 2) No New files, you can UL, you can DL, you've JOINed it.
 3) New files, you can UL, you can DL, you've JOINed it.
 4) No New files, you can't UL, you can DL, you've JOINed it.
 5) New files, you can UL, you can't DL, you've JOINed it.
 6) No New files, you can UL, you can't DL, you've JOINed it.
 7) New files, you can UL, you can't DL, you've JOINed it.
 8) No New files, you can't UL, you can't DL, you've JOINed it.
 9) New files, you can UL, you can DL, you've DROPped it.
10) No New files, you can UL, you can DL, you've DROPped it.
11) New files, you can UL, you can DL, you've DROPped it.
12) No New files, you can't UL, you can DL, you've DROPped it.
13) New files, you can UL, you can't DL, you've DROPped it.
14) No New files, you can UL, you can't DL, you've DROPped it.
15) New files, you can UL, you can't DL, you've DROPped it.
16) No New files, you can't UL, you can't DL, you've DROPped it.
(As well as which are invite-only.)

Currently you can tell:
1) You've JOINed it (But only if there's no new files).
2) You've DROPped it (But only if there's no new files).
3) There's new files. (But I don't know if I've JOINed or DROPped
   it any way.)

As always, the "UD*+-" string would be in BBSTEXT and could be
modified to any characters you wish, including "remove 1 or all".

--569--
Mini-VDE menu for (DIR) subs only (SysText:VDE/SubDirBoard)...

Since approximatley 50 of the variables settable with EL apply
only to subbases (but not subbase DIRs), would it be worth having
a separate VDE for subbase DIRs only?

The current VDE for subbase DIRs has 3 of 23 main menu choices.
Just 9 of 15 "access variables".
Just 2 of 24 flags.

You could have a small, simple, single menu with 14 choices (no need
in jumping to submenus), and leave the other unused 48 choices off.

Or are the they present for future expansion?  Many really would be
useful.  We could change a DIR's ratios/charges/flags/etc and
immediately affect the 100+ areas within it.  But still edit them
individually, per-sub afterwards.  (And since I'm always torn between,
"make it per-DIR for speed/ease" VS "make it per-sub for flexibility",
this would be perfect.)  If this is planned, then please disregard my
idea for a mini-dir-only VDE menu.

--570--
If implemented, maybe one of more of the following could help:

Each user can mark separate lists:
1)  The areas the user wishes to new-scan.
2)  The areas the user wishes to global-search.
The 2 different lists allow you to do things like:
Call and 'search for new files' in areas 2,4,10,20-30.
Or do a 'global-search' for a certain file in areas 1,10-20,50-89.
All without having to change/reset your desired area-lists.
(2 different area-lists are maintained.)
Most users would probably set #2 to ALL areas.  (Currently, you
could be trying to find something, but it's in one of your DROPPED
areas, you'll never find it.)

3)  The areas the user wishes to be notified when 'mail is waiting'.
4)  The areas the user wishes to bundle and D/L via the msg D/L utility.
The 2 different lists allow you to do things like:
Call and read new msgs in areas 1,4,6,10-12,23 online.
But only have 'waiting mail' marked in areas 3,9,25,28.  (No need to
get the same carbon-copy msg on 25 different Fidonet BBSes you called
today.)
And bundle for D/L (or off-line reading/replying) areas 2,5,30-50.
All without changing/resetting your desired area-lists.
(2 more area-lists are maintained.)

CNet current supports 1 type of area-list (via JOIN & DROP).
(Which effects all 4 of the above.)

I know of NO Amiga BBS which does all 1-4.

--571--
Does anyone maintain a list of phone #s of all the beta-test sights?
I'd love to call them and check-out the new features.
(As well as give them a work-out and report bugs.)

If it isn't top-secret, if beta-testers will forward me their BBS
phone #s, I'll maintain/distribute the list.

--572--
Vote topic, "Limiting File Marking"...

When *MARKING* files for download, CNet should limit the number of
files that you can MARK by:

1)  The maximum number you can DL during this call.
    (If you can only download 2, you can only mark 2.  The other files
    you wish to download can't be marked and won't appear as new
    during your next call.)

2)  You can mark as many as you want, download some during this call,
    others during future calls.

In either case, the SysOp can limit the overall number of marked files.
And your 'marked-list' will still be available on your next call.

1) I like method #1
2) I like method #2

--573--
S>  I can think of numerous ways in which to completely clean
S>  out your harddrive using just standard bbs maintenance functions.
You better inform Ken about these "standard bbs maintenance functions"
immediately.

P#>  Ami-Express has a "secure" shell.. its an external shell.. check it out..
P#>  A shell like that would be REALLY nice for cnet
How about a hint?

I need the full power of a true CLI, like CNet has now.

--574--
DS>  Trapdoor does more then most SysOp's need ...
A very good point.  That's exactly what I'm saying.
Tons of features that many people don't need and will never use.

A bus holds more people than a car.  Why don't we all own buses?
Because most of us don't need all that they can do.
Why pay/setup/maintain/repair/operate all that excess?
If you need it, you are free to buy it.
If you don't, why buy it?

H> BA> If it was kept external, you could use whatever frontdoor you wished.
H> BA> (This was voted on by CNet SysOps and 100s more voted for a custom
H> BA> CNet frontdoor instead of using 3rd party software.)
H> heard of the horror stories of Paragon's built in front-end.
Like it says.  "External" VS "built-in".
(And 'stable' VS 'bug-ridden'.)
Makes quite a difference.

H> Paragon's built in front-end.  I put my vote on the Tosser/scanner instead
H> of a front-door program!
You don't think he'd be more inclined in re-write/improve the
Tosser/scanner if it was for something that
HE WROTE, SUPPORTS and EARNS PROFITS FROM?
(Like his own FD.)
Instead of doing it so that someone else's 3rd party FD works better/faster,
and sells more copies?

I never have, nor never will, state that CNet doesn't need a
better/faster Tosser/scanner.  It does!
I wonder why Ken has never done one.
I wonder why Ken doesn't run TD.
I wonder why Ken doesn't even run Fidonet at all.

--575--
H> BA> Running Paragon-BBS JUST for its built-in Fidonet front-door support.
H> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
H> Then why all the brew haha on a CNet support BBS?
Was I "brew haha"'ing again?  I hope not.

Just like you and ever one else:
"I have to have certain MUST-HAVE things in the BBS software I run."
Your MUST-HAVE list differs from mine.  That's OK.

My list differs from EVERYONE'S.  (Thank God we're not all the same.)

--576--
I had always hoped for MCI codes that would display "*" or " "
(BBSTEXT settable) if there were ANY:

1)  New stuff in ANY of the bases.
2)  New stuff in ANY of the UDbases.
3)  New Pfiles.
4)  New Gfiles.
5)  New Vote topics.
6)  New News files.
7)  New Feedback waiting for SysOp.

Heck, you would tell a lot about the whole system, just by looking
at the main prompt alone.
> News*, Base, Feedback, Gfiles*, Off, Pfiles, STatus, Time, Uploads*, ?=Menu

(No need to jump in/out of various submenus just to find there's
nothing new there anyway.)

--577--
Has anyone found a way to pass parameters from CNet to a PFile
(from online).

So that Pfiles could work like CNet cmds do:
>R23
>R 23
>Read 23
>Read23
In all of the above cases, the "23" would get passed to your pfile.

I was hoping for something like:
> argv[0] The full path/filename of the Pfile.
> argv[1] Values passed from BBSmenu.
> argv[2] Values passed from BBSmenu.
> argv[3] Values passed from BBSmenu.
> argv[n] The string "###CNET_PFILE".
>         (To POSITIVELY identify this as a pfile-run.  As well as to
>         mark the start of 'online-passed' parameters.)
> argv[n+1] Values passed from online.
> argv[n+2] Values passed from online.
> argv[n+3] Values passed from online.
> argv[n...] Upto "argc" number of values total.

>Read 23
The "23" could then be found in "argv[n+1]".

--578--
I'd love to see programmer docs.
(In your format or *ANY* format.)

Are you going to write manual pages for the other 478 functions?  Can
you imagine the powerful features we are all missing in these 478
calls?  All the code is already written/debugged/working.  Just no
docs on how to use them.

What a monumental waste!  (Possibly the biggest waste of talent I have
*EVER* seen in all my years of coding.)

I'd even settle for a 1 line comment for each function.
ANYTHING!

--579--
It just happened again today.
Is it just me?
Is everyone having to reset their Sort "ORder" over and over again?
Are these being saved correctly?

--580--
When I run a DOS-cmd from the CLI with:
Case1> r:a.out -node 0   -input Mail:Users/1/FileName.txt
Its output is correct:
CNet A> Testing.

When I log-into node #0 under account #1 and run the same file from
the pfile-menu as a DOS-pfile, with:
Case2> r:a.out -node %23 -input Mail:Users/%40/FileName.txt

It's output is:
CNet A> Testing.
CNet B> FileName.txt         (<-- Where is this coming from?)

%23 should be expanding to node # "0".
%40 should be expanding to acct # "1".
So the offline and online cmds being executed should be identical.
(SnoopDOS will verify this also.)

Shouldn't the output in both cases be the same also?
(If line #A is longer, line #B is chopped shorter an equal amount.)

--581--
> CALLEDITOR {s}
>        This invokes the user's default editor.
>        The current contents of the editor's
>        buffer are loaded, and the results are
>        re-saved.  "1" is returned if the temp
>        buffer is not empty ("0" otherwise).

Does anyone know what the "{s}" specifies?
(I thought SAVEEDITOR was the cmd that actually saved to a specific
filename, so it isn't "filename", as I initially thought.)

--582--
S>1                              01-3-------------------  or
S>2                              0-1,3 as the new format is now. */
Everything within CNet should go with format style #2, not the old #1.
Group-Chat ROOMS still uses #1.

--583--
Given the fact that we NEVER want sys requ's to pop-up while online,
in remote, I don't think it would be too odd a feature to put into the
BBS itself.  And that a single sys requ can hang an entire BBS forever,
I don't think this is a frivolous request.

CONFIG/OPTIONS: "Cancel all system requesters?" []
(Check-marked box.)

I always hate to cancel ALL sys req everywhere, because some of them
I DO want to see.  (Another good reason for this being built into CNet,
and only canceling those that it generates.  Either directly or via
pfiles/DOS/Arexx scripts that CNet calls.)

Here's What I'd REALLY, REALLY like to see.  But it could be tricky to
do.  A config value that would set the # of secs before CANCEL would
automatically be hit.

If you set it for 5 secs, the requ would still pop-up, local or remote,
you'd still see the problem in local, still have a chance to hit
cancel/retry, or just wait x secs and they get cancelled
automatically.  And It wouldn't effect non-CNet things either.

Doesn't this cover just about ALL bases?
Can anyone see where this would NOT be ideal?

--584--
TB> A good idea, but entirely muddy to read.  While you and I have no problem
TB> with such things, you have to remember that quite often complete imbisols
TB> will be calling your board, and all that just makes it all that more
TB> intimidating.

Even this display?:
TB> > > 1.      +  CLI/APR/Shells           2.      +  Kstart/Wbench
TB> > > 3.       * Packers/Copiers          4.(DIR) +* Disk/HD/Floppy
TB> > > 5.      +  Virus Killers, FREE      6.       * Home/Education
TB> > > 7.(DIR) +  Business                 8.      +* Other Utilities
It's only 1 char different than the current one.

But adds:
You see your DROPPED areas, even if they have new posts.
You see your JOINED areas, even if they have new posts.
You see your INVITE-ONLY areas.
You see your INVITE-ONLY areas, even if they have new posts.
NONE of which are current available.

Since that little "+" or "-" can make your new-scans miss 1000s of
new ULs, I don't think it should EVER be hidden.
As it is hidden currently with the "*" char.

--585--
TB> So next we won't be able to kill messages, erase users without 10
TB> passwords..
TB> There is no such thing as a secure system.
Your definition of 'secure' my differ.
I define a "secure system" as 1 that let's the sysop decide exact who
has access to which cmds.  (That's 100% secure, in my opinion.)  It's
odd that we can do this for nearly all normal cmds, but NOT for the
maint cmds which are a billion times more important/danergous.

But you create a non-secure system when you have to:
1)  Grant everyone you want to have access to MCI code x, also to have
    access to MCI code y.
2)  If you can edit, you can also kill.
3)  If you can kill, you can also edit.
4)  If you have access to 1 maint cmd, you have access to all of them.
5)  If you can edit certain accounts, you can edit them all.
6)  If you want callers to see "AM" stats, you have to grant them full
    maint & kill powers.
7)  If you want to allow someone else to check the call log, they
    can also delete it.
(I'm not sure which of these are still a part of Cnet.)

ANYTIME you hardcode into a BBS things like:
"If you want this caller to do [whatever], you have to allow him to
also do [this], too."
You make a non-secure system, non-controlled system.

We basically need a total separate maint config.
It would be a list of all maint cmds.  (I'd be happy just SEEING a list.)
You'd set each to ON/OFF.
You pick exactly which maint-cmds each maint-level allows/forbids.
Your maint-flag would no longer be its current "all or nothing" setting.
It would be a 0-31 maint-level #.
Or even 5 custom-defined levels would do it.
Or even 1.  Just as long as it's custom-defined.
We tell CNet what "maint-access consists of".
Not "Cnet tells us what maint-access includes".

It would be a matter of not only allowing sysops to decide WHO
has maint-access.   But also define WHAT maint-access itself is.
(And match the right level of power with the right users.)
I would gladly appoint 100 co-sysops, (And I could sure use the help.)
if I could control exactly what they are allowed to do.

All of this would be for REMOTE log-ins only.
(I'm all for letting LOCAL log-ins do anything/everything they want.
After all, if you are sitting right at the machine, its kind of odd to
worry about security.  The guy could delete/reformat any drives he
wanted via a CLI.)

--586--
DM> How bout a line telling each user not only how MANY mails he has, but also
DM> how many bytes it takes up.. also have a separate listing for how many
DM> bytes there is in file-mail.

This is ideal Arexx stuff.
If we have access to the variables, you could make this as short
or as long as you liked.  And every sysop gets exactly what they want.

1>You have mail.
2>You have new mail.
3>You have old mail.
4>You have 9 pieces of mail.
5>You have 9 pieces of mail.  6 old, 3 new.
6>You have 9 pieces of mail.  6 old, 3 new.  3892 bytes total.
7>You have 9 pieces of mail.  6 old, 3 new.  3892 bytes total.  40% full.

8>You have 9 pieces of mail.  6 old, 3 new.
8>3892 bytes total.  (40% full, room for 7422 bytes more.)

And dozens of others.

--587--
> 44 19-Dec   0 Filename      LHA 178K Short filenote goes here...
>             ^                        Describing this file.
>             |
>             |

When scanning for files, how many people like the old "show # of DLs"
instead of the new "show # of responses" display for file-posts?

I very often call large systems with 10000s of files.
And very few have responses.  Just see 0-0-0-0-0-0-0-0-0.

The DL-count used to show which files have been worth DLing to 100s of
callers.  "0-0-0-0-0-0-0-0-0" does show much.

(Some of these subs don't even allow responding anyway.)

1)  Let's see the old 'download-counts'
2)  Let's see the new 'response-counts'

--588--
Ken, regarding file-marking.

I'd REALLY like the idea of being able to mark more than I can DL on
this call.

I'm not alone...

#:Possible answers                        : Votes:Percent
1:Allowing marking only what you can DL   :  62: 21.5 %
2:Allowing marking MORE than DL'able      : 226: 78.4 %

3-4 times as many liked #2.

--589--
Where are you finding full docs to EnterLine()?

>cmess.arg2 = (ULONG)flags; /* 1=UpperCase       */

Does this support other flags too?
Or should.

(That's all the docs I can find on this flag.)

EnterLine() should at least have those that are now supported w/MCI
codes, for user input.

--590--
What possibilities would be handy after DLing via term and
dropping carrier:
1)  Exit term and wait for next caller
2)  Do nothing
3)  Exit term and closedown that node (saving memory)
4)  Allow you to pick 1 of the above
5)  ???

--591--
Access for this item  [0-23]: 0-23
Minimum age for item     [0]: 0
Maximum age for item    [99]: 99
100 float vote item     [No]: No
Allow users to add new choices [No]:      <--- *** NEW IDEA ***

Would this be a good idea?

Allow the POSTER of the vote topic to really "own" and "control"
HIS vote topic.  He'd be the 1 that would allow/prevent new
choices from being added.

(Of course, the voter would still have to have 'choice-add' powers, as
granted by the SysOp.)

There have been cases where I'd love to have seen others add
their own choices.

And other times, when I'm going for a simple YES/NO, BLACK/WHITE, NEW/
OLD type vote reply and specifically do NOT want 10 other "maybe this"
choices tacked on by users.  (Splitting the voting 12 (or more)
different ways.  Or worse, 8-way ties of 20 votes each.)

I guess what it comes down to is really, "who OWNS this vote topic"?
The original poster?  Or others trying to add/modify it?
I "vote for" the "original poster".

--592--
Ken, a question and a suggestion...

Question:
When adding a new vote-topic here at FW, there a certain flag
I can specify to only allow CNet SysOps to vote?  (Or allow
only non-CNet SysOp to vote.)

Suggestion:

Change:
CNet> Flags required to see:
into
CNet> Flags required to see [? for list]: ?

and if "?" was hit, a small text-file would be displayed
(SysText:Vflags.txt) containing something like:
>   1    Non-validated Users
>   2    Validated Users
>   3    Local Callers
>   4    Long Distance Callers
>   5    High-Speed Users
>   6    Paying Members
>   7    Beta-Testers
>   8    CNet SysOps
(or however you have your 0-31 flags defined.)

Of course, a SysOp could use any/all flags, but these would be the
ones that he wanted the users to see and pick from.

When users post a new vote topic (or pfiles/gfiles/news/subs/etc) they
could direct it at a specific group of users.  (SysText: Pflags.txt,
Gflags.txt, etc.)

It wouldn't really change the way vote works, but this help-file would
be a great reminder for callers and SysOps, alike.

> What does flag #23 do again?
> ?
> Oh, it means these users are "such and such".

--593--
I can read response #108 fine.  And read & edit others fine.
But get...

> More responses. Respond, Pass or ENTER to continue>  ed
> Edit response number  : 108
> Trouble locating this message.
> More responses. Respond, Pass or ENTER to continue>

--594--
When I do a ZG for a word and it is found twice (or more) in the same
line, CNet displays that same line twice (or more).

I feel everyone will see it the 1st time, and need not see it
the same line again and again.

Also, are there lines in BBSTEXT that are displayed right before (and
right after) the actual matching strings?  So we can do things like
color, underline, inverse the actual strings.  If so, which line #s
in BBSTEXT are they?

I also rather liked the now gone, "Filter text  #1:" options.
Since the code was already written and debugged, why remove it?

--595--
You can make individual cmds in BBSMENU limited to only certain access
levels by following the cmd with "`0-23".

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

Sure wish we could do similar things with:
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.)

#4-6 would be especially useful if CNet's BBSMENU came with all Sys/
SubOp-only choices marked (controlled) with "+" and "-" and "*"
(instead of hardcoding them into the BBS.)

We could then allow certain Non-Sys/SubOperates to use cmds like "AM",
"Arc TEst", "Log viewing", without giving them full Sys/SubOp powers.

Does anybody have a list of EVERY cmd in BBSMENU that is automatically
"SysOp-Only" or "SubOp-Only"?  (I'm assuming NONE of these can be made
to work for callers without such access.  No?)

--596--
Ken, did you get this SAS v6.1 installed, that I ULed?
v6.2 is already out.  Can some one UL it?

Many bug-fixes, some of which might be effecting your code (and CNet),
through no fault of your own.

--597--
Ken> The new MCI system has numerous numeric and string manipulation
Ken> commands.  I will be entertaining suggestions for enhancement to
Ken> this system before the release of 3.0.
Funny you should ask.  I just have a few things to add.

In addition to the MCI 'goto-label', are you planning on 'gosub-label'
and then a matching 'return' marker?  For easy reuse of the same part
(subroutine) of an MCI text file.  (Like a menu that gets displayed to
the user over and over.  Or a math routine.  Or a formatting &
displaying routine.  Now that we have all this power, people are going
to be doing this.)

Ken> {Vn s} Display a system variable
Ken>        n may be any valid GETUSER specification.  The special numbers
Ken>        60-69 correspond to the MCI numeric registers.  The special
Ken>        numbers 70-74 correspond to the MCI string registers.  See the
Ken>        CNet manual for a complete list.
Do the string registers (SR) take up much in the way of speed/mem/CPU?
10 SRs and 10 NRs would be a nice matching set.

Ken>        If the optional argument 's' is specified, it must be of the
Ken>        form %n.ms ... a 'C' style format command.
Ken>        Alternatively, 's' may be the special character 'c' followed
Ken>        by a field width.  The variable will be displayed CENTERED
Ken>        within a field of spaces of the specified width.

Here's what I put into my VARS.LHA pfile:
BA>  1) Allows verbose Cnet MCI codes by variable
BA>     name (NAME/ADDRESS/DOWNFILES) instead of MCI #s (/V3/V9/VE).
BA>  2) Allows field width formatting.     {12  NAME}
BA>  3) Allows left justification.         {-20 NAME}
BA>  4) Allows right justification.        {7   FILESDL}
BA>  5) Correctly adds/positions +/- sign. {+9  CREDITS}
BA>  6) Pads with leading zeros.           {05  TIME}
BA>  7) Show only 1st x chars.             {.6  DATE} {.3  DPHONE}
BA>  8) Show 1st 6 chars in field of 9.    {9.6 DATE} {9.3 DPHONE}
BA>  9) Shows sub string from 4-6 chars.   {4-6 DATE} {5-7 DPHONE}
BA> 10) Shows sub words 4-6.               {4-6 DATE} {5-7 DPHONE}
BA> 11) Inserts commas every 3rd digit.    {,8  DOWNFILES}
BA> 12) Centers string in field x wide.    {|40 COMMENT}
BA> 13) Display 'as-is'.                   {HANDLE}
Looks like MCI new does most of it.
#11 would be good for easy-reading of large numbers.
Like "{V24 ,12}"  Right justify, inserting commas, in field of 12 chars.

Ken> {XM n} Replace MCI character register 0 (70) beginning with its nth
Ken>        charater. Similar to BASIC MID$()
Ken> {XL n} Replace MCI character register 0 with its leftmost n characters.
Ken>        Similar to BASIC LEFT$()
Ken> {XR n} Replace MCI character register 0 with its rightmost n characters.
Ken>        Similar to BASIC RIGHT$()
These are great.  Any plans on their counterparts which would effect
WORD #n instead of CHAR #n?  Might be used just as much, if not more
than these char-functions.  (Parse words:  just a user's 1st name,
just city from citystate, just areacode from phone #, etc.)

Ken> {XP} Replace MCI character registers 0 and 1 with the PARSED version
Ken>      of MCI character register 0.  Text is parsed at the first space.
By "PARSED", you mean expand MCI chars withing the registers themselves?
I hope so.
i.e.  Right justify some #s and then justify the whole string afterwards.
> sprintf(buf1, "(%5d and %5d)", x, y);
> sprintf(buf2, "Results: %25s", buf1);

Is this new MCI going to have a new name too?
1) To distinguish it from the old MCI.
   TEC: Text Expansion Codes
   VFC: Variable Formatting Codes
   CCC: CNet Character Codes
   or about 1000s others.

2) To distinguish it from the copyrighted name of the long distance
   carrier: MCI.

   I've called a few systems and see things like:
   "We do/don't allow MCI codes to be entered into this msg area."
   I hate to think what some callers (that aren't familiar with CNet),
   think this really means.

>In CNet/3, MCI commands begin with CONTROL-Q.
I would have went with something mnemonic like ^M for MCI (or whatever
it gets called).

Or ^{ and ^} (Or can't all non-Amiga computers generate these?)

Or even:
^A to mark the starting { code.
^Z to mark the ending } code.

Or are some of these mandatory for the full-screen editor?

Now that we have all this power, but only 30 of 500 GETUSER values,
any plans on adding a handful of new GETUSER values?  Maybe use slots
42-59?  (Definitely UL/DL byte/counts and all the old "/Vn/" values
that never had had GETUSER values.)

All GETUSER values are priceless for they never 'move around' like
XT##### values.  I don't know if 17 more will be enough, though.  I
would have reserved 0-99 for GETUSER values.  And 100-109 and 110-119
for registers.  (Looking 5-10yrs into CNet's future, as well as for
'round numbers' starting at 100.)

Any plans on expanding the "X" in XT##### GETUSER codes?
1==PortData
2==MainPort
3==UserData
4==ItemType               (Why didn't this stay named 'SubboardType'
5==NewSubboardType   <---  and make the old 1 'OldSubboardType', like
6==AccessGroup             the other structs as they became obsolete?)
7==MessageType
Currently, I believe these can already be obtained but it's a bitch
correctly counting offsets within offsets within offsets etc.  (For
structs that contain other structs.)  And when 1 thing 'moves' (CNet
expansion) nearly everything 'breaks' that appears 'after' it.  With
"X" values for each struct separately, the most that would 'break'
would be that one struct that 'expanded'.

MCI is becoming a full-blown BBS LANGUAGE in itself!!!  Yeah!!!

--598--
> Users hit "D" which effects the "current item" instead of producing
> a "DOWNLOAD FILENAME:" prompt.
I like this idea.  And would like to hear many more such "users
intuitively try and do <this> but it ends up do <that> instead".
DLG-BBS is very big on every cmd effecting the "current item" and
sooooo many users don't like this "current item" method.  They don't
even realize they are at any kind of a "current item".

I would also like to see CNet have some kind of a 'fail-cmds' written
to the logs.  Maybe show the prompt # (as in BBSMENU) and the cmd that
the user tried to type.

Wouldn't you like to know that:
1)  200 times a day, users are faced with the "D" problem mentioned above.
    ("You haven't selected anything.")
2)  300 times a day, users are trying to use "*" to tag files instead of
    your "T" configuration.  (Or IBMers probably do it the other way around.)
3)  400 times per day, users are getting:
    "There is no help available on %s."
    "Message %d has expired."
    "Sorry, you have left too many feedbacks."
    "Sorry, only one port per account."
    "Sorry, that area is empty."
    "Sorry, you don't have enough file/byte credits"
    "Sorry, there are no empty rooms available."
    "Sorry, you need an invitation."
    "This item is missing."
    "Can't create temp upload dir."
    "Can't find your account!"
    "Can't setup protocol."
4)  500 times per day, users are typing "U" and "B" at the Main Menu
    instead of the "F" and "M" you've changed them to.
5)  600 times per day, users are seeing:
    "NOTE: can not find SysText:sys.info"
6)  99.9999% of all callers are hitting "Y" at
    "Use previous term settings [Yes]?"
    "Quick log-in?"
    "Skip on this date in history?"
    and NONE at
    "Terminal A=ANSI, C=CBM, I=IBM, S=Sky, [NONE]"
(I'm constantly typing the wrong cmds at BBSes that do #2,4.)

But how would this type of logging be CONFIG'ed in keeping with
CNet's current method?  Maybe 2 new "Log Handles":
1)  LOG_PROMPT which would handle types #1,2,4.
2)  LOG_BBSTEXT which would handle types #3.
    (Which would only log "Sorry" "Can't" "Failed" "Missing" type msgs.)
I don't know what could be done for #6.

I'd like to see this stuff logged in order to help the users, as well
as set-up the BBS to be very intuitive.

But of course, if you are a sysop that feels "If the caller is too
stupid to figure it out, I don't want him calling here!", then this
error-logging will be invaluable to you also.  (You'll know exactly
which callers to delete.)  (Some sysops do run BBSes like this.)

--599--
Ken, I gave up on my VDE-for-files project.  Just too frustrating
working without programmer docs, current structs/headers, and many
uncommented structure elements.

I've started on something else.  This is for v2.42e.

Which element, of which structure, gives the "Physical subboard #"
shown at the top of EL's VDE screen?

(This display-line was apparently added after VDE.c was released.)

I'll just bust if I have to wait until sometime in Feb.

--EOF--

Monday 25-Jan-93 03:52:52

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