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 but it ends up do 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