************************************************************************* _______ _______ _______ _____ _______ / / / / / / / / /| / / / /______/ / / / / / / / | / / / / / / / / / / / | / / / / / / / / / / / | / / / / /______ /______/ / /______/ / |/ __/__ /________ ************************************************************************* An FTS-001 *.msg area manager with serial routines Runs as a door on OzMetro BBS & probably other Amiga BBS programs Also runs standalone in a point or node environment (c) 1991-1994 by Peter Deane (3:622/401) Written in GFA-Basic V3.51E Version 2.0 - 21-Nov-94 ********************************************************************** Chapter Headings ********************************************************************** Section 0 - Getting Started Types of Mail Software System Requirements Nodelist The Plutonic Utilities Section 1 - Introduction Description Acknowledgements KeyFile Libraries Features Serial Matters Section 2 - Plutonic.cfg General Notes Dictionary of Plutonic.cfg Keywords FORMAT OF ENTRY (NO)4DMSGDISPLAY (NO)4DMSGHEADER (NO)ACTIVATEWINDOW (NO)ADDMSGID (NO)ADDPATH (NO)ADDPID (NO)ADDREALNAMEKLUDGE (NO)ADDSEEN (NO)ADDTAGLINE (NO)ADDTEAR AREAFILE ATTACHDIR BBSNAME COLO(U)R1 - COLO(U)R7 (NO)DEFATTACH DEFAULTAREA (NO)DEFINTERNAL (NO)DEFREFLOW DEVICE EDITOR (NO)FLOATTACH (NO)GATEROUTE HIASCII & LOASCII INBOUND KLUDGEOFF/KLUDGEON LEV-1 (NO)LOCKEDMODEM (NO)MATCH1 - (NO)MATCH9 (NO)MATRIXPID MAXAREAS MAXBAUD MAXLINES & MAXLENGTH MAXTIME (NO)NODELIST NODELISTPATH OUTBOUND QUOTELINES & QUOTELENGTH SCREEN0 - SCREEN7 SHOWKLUDGE SIGNOFF1 - SIGNOFF3 SWIDTH & SHEIGHT SYSLEVEL SYSTEMFILES TAGLINEFILE (NO)TRANSAMIGA UNIT UNUM1 (NO)UPDATELOG (NO)UPDATESTATS USER1 USERS ZONE Section 3 - Plutonic.areas General Specifying the Areas file Areas File Format Line (1) Directory Name Line (2) Local Area Name Line (3) Read security Line (4) Write security Line (5) Origin line Line (6) Node Number for this area Line (7) Flags Netmail Flags Echomail Flags Example The PlutAreas Editor Section 4 - Using the Program General Main Menu Options [C]hange message area [F]ind new messages [R]ead messages Normal Headers only Mine only Selective search One line summary [W]rite a message [O]ne line summary [N]odelist lookup [E]cho rules [A]lter setup [S]et last message read [Q]uit [D]elete Whats.here [L]oad Plutonic.cfg [>] Next Message Area & [<] Prev Message Area Section 5 - Bugs or features? Section 6 - Distribution & Politics Section 7 - Registration Section 8 - Standard Disclaimer ********************************************************************** Section 0 - Getting Started ********************************************************************** You will NOT be able to run Plutonic without first reading this documentation in full (probably multiple times). I spent many long hours putting the docs together - PLEASE read them! Types of Mail Software: ----------------------- Plutonic is what's known as a 'Fido Message Editor'. The term should really be 'Message Area Manager' because not only does it allow you to write the messages, but read and manage the rest of the message base. Also the term 'Fido' is really only after the FIRST network to use this technology. You could find Plutonic VERY useful and not be in FidoNet at all, but in any of a number of other Nets. The term is being used here to refer to what's known properly as a 'FidoNet Technology Network' (or "FTN"). In fact, most 'Message Editors' don't even have a text editor as part of their code. You can use your own text editor from the standard workbench 'Ed' program to Cygnus Ed Pro, from AZ to GoldEd or even a word processor. The only requirement being that what you use saves its output in ASCII format, and will accept a filename as an argument when run. Generally you develop your favourite text editor anyway, it's one of the major tools of any power user. What's more, Plutonic even has a built-in line editor, which makes it very simple to use. Your external editor will be more powerful, however, and give you the ability to include already existing text in your messages. However, for quick messages, the built-in line editor may well suffice, save memory, load faster and is easier to configure. You need three types of software to operate as a point (and node). One very important piece is your Mailer. TrapDoor seems to be the dominant Amiga mailer out there. I will assume you are using TrapDoor throughout all of this. It's that good. If you want a better mailer than TrapDoor, you will need to sell your Amiga. Then you need a Tosser/Scanner for going through your message bases, converting messages you write into packets for transmission; or taking packets and converting them to messages in your message areas. I wholeheartedly recommend TrapToss here. DLGMail, FastPoint ConfMail and even Foozle (in the *.MSG creation mode) are other possibilities. As long as the tosser is a relatively generic *.MSG tosser, that's all you need. The final piece of software is a Message Editor, which is what Plutonic is. It replaces such software as RMB, Chameleon or Juliet. To run a BBS, you'll also need a BBS package of some form. Plutonic is a companion piece to the OzMetro BBS. If you want to add the ability to take external callers into your point and operate a BBS you'll also need OzMetro. If you have OzMetro, you'll find there are NO message functions in that BBS program - you MUST have Plutonic to run with it. But the reverse isn't true - you don't need OzMetro if you are using Plutonic - unless you want to run BBS package as well. Much of the newer point software packages coming out (eg GCC, Foozle, PointManager, April and most recently Spot) are combined Tossers/Scanners and Message Editors in one package. Plutonic retains the separation of tasks and only handles one side of things, the actual messages. This means the software can be more specialised and give you a good message-writing environment without worrying about the tosser implementation. The benefits of using separate software are clear that you can mix and match should newer better software later become available, and generally you get more powerful software. But one very important point that no other point package has is Plutonic's serial routines. Plutonic can be used to write messages either locally or from REMOTE. You have a lot more power available locally, however because you can use the mouse. Someone using Plutonic from remote only has the keyboard interface available to them, which is powerful enough, mind you. System Requirements: -------------------- It is extremely difficult to run a point on a floppy-based system. It is not recommended at all. All the floppy-based points I have come into contact with have eventually either folded or obtained a Hard Drive. So if you are masochistic enough to want to use floppies, then you'll have to be especially skillful. The clue is to keep a LOT of floppies around called MAIL: and having message directories on them. Only keep a few days' worth of messages per floppy. It's hard, and really slow tossing to floppy. If you have enough ram, ASSIGN MAIL: to RAM: and do all the tossing there, copying back to floppy afterwords. Tricky. One Meg of ram would be the bare minimum, but I'd strongly recommend more. Plutonic is most certainly NOT a memory hog, but it's nice to have a little leeway. Plutonic will support 1.2 Workbench for a long time to come yet. It will run under both 2.0 and 1.2 simply because the program makes no low-level system calls at all. It doesn't need to because it mainly deals with file handling, not all the new-fangled graphic modes available under more recent versions of AmigaDOS. Plutonic does run a little faster under 2.0, but that's only because of the new FileSystem. Registered versions (ie keyfiles) for any software you are running will become almost essential as you begin to use your point or BBS more. With registered software, everything except reading and writing the messages can be automated through use of a cron program (eg tptcron or cybercron) and cleverly-written event scripts (you'll write these). Please consider supporting the authors of the software you use. It will ensure we get revisions and support. If you need to register TrapDoor and/or TrapToss, you'll be pleased to know I carry out the function of Zone 3 registration site. I can accept registration applications for both of these programs from anyone in the world (although there will possibly be another registration site closer to you if you aren't in Australia or New Zealand). Included in this archive the file "TrapRego.AUS" will give you the necessary details. You will also need a passing familiarity with your Tosser and Mailer before you run Plutonic. Please see the documentation for that. For a general overview of how FidoNet works, I suggest you consult the TrapDoor "FidoNet Manual" by Maximilian Hantsch. This is included in the TrapDoor archive. If you are going to use FidoNet messages you should also obtain a copy of Policy 4 - basically the rules and regulations of the network. Nodelist: --------- You can turn off nodelist support in Plutonic, but it's extremely useful to turn it on. To use the nodelist, you must have prepared a nodelist index file using the program in the TrapDoor distribution called TrapList. Note that Plutonic REQUIRES the Traplist.library to run - even if you don't have nodelist support turned on. (It uses other functions from it as well as the nodelist lookup section). To prepare your nodelist you should consult the TrapList documentation, and compile it by running TrapList. Once this is done you enable Plutonic access to the details of every node in the nodelist(s) you compiled. This is important - TrapList will provide access to ALL your nodelists as if they were one (for our purposes). Plutonic has a separate Nodelist lookup function, plus it will check the nodelist each time you attempt to send or reply to Netmail. When running as a BBS, turning nodelist support on is virtually mandatory to prevent users from posting messages to non-existant systems, resulting in messages that have no chance of delivery coming out of your system. This might result in complaints if you do it frequently. As a final word, it's often useful to have the logical assignment of 'NODELIST:' pointing to the directory where you keep your nodelists (Suggested possible nodelist directory would be MAIL:Nodelist/). Other software may make use of the NODELIST: assignment at times. (Plutonic doesn't) The Plutonic Utilities: ----------------------- This is an advertisement for some utilities I've written over the years that I find indispensible in a mail environment. As your system grows you'll find something here of use. The Plutonic Utilities archive was hatched in the ADSFIDO file echo in mid October 1994, and should be available at a BBS near you. The current archive name of the full utility set is PLTUTE01.lha, plus the programs are available as individual archives if need be. A new PLTUTExx.lha collection will be hatched every time major revisions are made to AT LEAST three of the individual programs. All of the Plutonic utility programs are freely distributable and include full source code in GFA-BASIC. The Plutonic utilities archive currently consists of these programs: PltBak01.lha : Makes backups of your .cfg files PltDay11.lha : Gives the Julian day number of the system time PlText05.lha : Gives three types of ascii dump for a *.MSG base PltFdt02.lha : Sets filedates of TrapDoor inbound to original creation time PltFlM02.lha : Moves .?LO files from one directory to another PltHed11.lha : A powerful *.MSG binary header GUI Editor PltLst10.lha : Automatic nodelist detection and processing system PltMap13.lha : Remap .?LO files from one address to another, PLUS MORE PltPrg03.lha : Deletes unnecessary 0-byte files in the outbound PltPrv02.lha : Sets the private bits ON/OFF for a *.MSG directory PltRej02.lha : Prevents TrapDoor receiving a file you've already got PltRiv20.lha : Automatic *.MSG BadMail retrieval system for TrapToss PlTrxD01.lha : Calculates human-readable dates/times for TrxID #'s EVERY POINT AND MAIL SYSTEM WILL FIND SOMETHING OF USE HERE The individual archives are all frequable from Inquestor using the above names should you not be able to find them (or the full archive) on a BBS near you. BTW, the PluText utility is included in this archive. ********************************************************************** Section 1 - Introduction ********************************************************************** Description: ------------ Plutonic is a mail area manager for nodes, points and BBSs. It uses the FTS-001 *.msg format of storing messages in various directories usually under the MAIL: device. It is completely compatible with message areas prepared for Chameleon, for instance. Plutonic has a very special feature to set it apart from all other mail area managers: it has serial routines and will run as a door program on OzMetro BBS and probably other Amiga BBS programs. Acknowledgements: ----------------- First, a BIG thanks to Percy Broadnax who started the ball rolling with the original Metro BBS program, and without whom I doubt I'd be a computer programmer and Sysop. Next even more thanks are due to Peter Nicolas who has been running Plutonic and OzMetro for a couple of years now, and has been an excellent sounding board for ideas and supplier of suggestions. Thanks to ALL regular callers to Inquestor, who are too numerous to mention. Thanks to Max Hantsch, Rene Hexel and Martin Laubach for writing the most powerful mailer software available for Amiga. Thanks to Mum who bought me my first hard drive at the typically ludicrously inflated prices we had to pay back in 1990 for Amiga peripherals. (I bought my 500 meg Fujitsu for a third of the price my first 80 meg beast cost)! Thanks to the 70's musicians who I listened to while preparing the code and docs for this release. (EG Abba, Cat Stevens, Al Stewart, The Carpenters, Jim Croce, Billy Joel and Paul McCartney, et al) No thanks to Philip Morris tobacco company for providing me with the 5 cigarettes an hour I generally go through while programming :-( Thanks to the Amiga-Lorraine company for providing doubtlessly the world's best computer operating system. Hi to all the AUST_AMIGA groupies. KeyFile: -------- The version of Plutonic you now have is unregistered. Plutonic is not a free program - it has taken many years to get to public release and I can't put all this effort in for NO return. As a result there are two limitations when Plutonic runs in unregistered mode: * Plutonic will only load up to at most 20 message areas per invovation (See Section 3 - "The Areas File" for a workaround to this limit). * Plutonic will quit after it has been running a maximum of twenty-five minutes. It WILL NOT quit in the middle of posting a message (it will wait for you to finish off and save the message and then quit). To overcome these limits and encourage me to make further improvements to the program, you should register. The released archive is only for EVALUATION purposes, and you are not permitted to run the program for a period exceeding five weeks (not continuously! Five weeks from the day you first start to run the program) without registering. When you register you will receive a 512 byte keyfile, which when placed in the MAIL: (or current) directory will cause Plutonic to ignore these limits and run with full power of theoretically unlimited message areas and the time limits you set in the configuration. There is only one released version of the Plutonic program, it's the presence or absence of the keyfile that disables the limitations. This means registered users will be able to obtain upgrades by downloading them from BBSs and get to use any new features straight away. It also means I don't have to maintain TWO copies of the one program. Plutonic is CHEAP. I hope I haven't priced myself out of the market by setting a fee of around HALF that normally paid for shareware mail software. And I hope this encourages you to register. For more details consult one of the last sections in this manual, and see the order form available in the archive. Libraries: ---------- Plutonic REQUIRES the traplist.library before it will run. PlutScan (Plutonic's message area scanner included in this archive) also makes use of a couple of functions in arp.library. I'll include the latest version of the traplist.library in this archive. If it's not already there, copy it to your libs: directory. Arp.library should be VERY easy to obtain, so I won't include yet another copy of it here. It's in the OzMetro archive if you have that. On the early Fish disks you'll find it on just about every second disk. If not, call an amiga-supporting BBS and throw yourself on the mercy of the sysop, write a message asking, or take a look through the file areas. Arp.library is so common it won't be a problem locating it at all. Features: --------- Plutonic's main feature is its speed. Being written in compiled GFA-BASIC makes it faster than any C program, and almost as good as straight assembler. Comparing the speed of Plutonic with TransAmiga's message base, for instance (VERY similar programs except TA is in HiSoft BASIC), will show a noticeable increase in speed of a factor of around about three or four. Plutonic isn't something that's been whipped up in the last month or two. Development started back in September 1991, and it shows. Pluto is getting to be quite mature now, and its reliability is a testimony to the development. This is NOT a public beta release or anything, it's been extensively tested and while I cannot say there are no bugs in the program, I haven't been able to find any! o Full nodelist support Plutonic can extract all relevant information from a nodelist index produced by TrapList (ie traplist.library). There is an option to disable this should your drivespace not allow for a full nodelist setup. o Multiple netmail directories You can have as many Netmail directories as you care to setup. Since Plutonic is a message area manager only, it's up to the Tosser to send incoming messages to the various directories. You should therefore be able to setup all your message areas to be whatever you like, echomail OR Netmail. Plutonic supports this important concept. o Alias message areas Users can use an alias in message areas where the sysop chooses to allow this. o Private Message areas Some 'echoes' are private ones. Usually they are only local net areas where the phone call charges are small. Any echo message area can be setup to allow the private bit to be set at request of user or set as default, not just for netmail. o Full ANSI/HI ASCII message display The sysop can choose the range of ASCII values to be displayed thus en/dis-abling ANSI display for messsages so written and likewise with Hi Ascii characters. When displaying Hi Ascii characters, use of an appropriate system font (usually an ibm.font) will be required via the use of WB 2.0 Prefs or a program like FastFonts (included on the WB 1.3 distribution as c:FF). The standard amiga console.device is used as the ANSI interpreter, so some IBM ANSI screens, mainly those using the SCP and RCP (Save/Restore Cursor Position codes) won't display properly. In messages, you don't see much ANSI anyway, (it's forbidden in most Fidonet echoes for instance) so this won't be a problem in practice. o BBS-Only message areas The SENT bit of any message can be set when it's created, effectively preventing its export by any decent mail tosser. This can be set at the option of the user or by default. This means you can have message areas where some (or all) of the messages never leave your system, but still allowing other systems to feed in messages. o Times Read field The Times_Read field of a message is incremented each time it's displayed, thus allowing a sysop to see which areas his users really do read. o Reply Threading fully implemented Reply threads created by your mail tosser are available and the ability to jump to the Previous or Next Reply (if there is one) is available betwen messages. When replying, the message you write is chained to the message you reply to. o ^A-MSGID: kludge line All of Plutonic's messages have a MSGID line, using the Unix timestamp as its base. This ensures that messages going out from your system won't ever have the same message ID number for 136 years. Naturally MSGID creation can be turned off in case you want to get some other program to add them instead. (TrapToss ALSO uses the Unix timestamp for its MSGID creation, so turning them off in Plutonic is of limited value). o ^A-REPLY: kludge line Plutonic will fish out the MSGID from the message you are replying to (if there's one there of course), and insert it in your reply, thus helping other mail processors to more effectively link the reply thread. Plutonic itself does not use the REPLY line, but will assist any software requiring it. o ^A-PID: kludge line or TearLine Plutonic adds either its PID line in the message or a short TearLine as per your config. Note you CANNOT have both, the program will not allow it. o ^A-INTL kludge line The INTL kludge will be used for any netmail going to out of your own zone OR for EVERY message produced in that netmail area. (Up to you). o No hard Carriage returns Messages are presented as free-flowing text with no hard carriage returns. If the message is written in the internal editor, the only carriage returns added are the ones where YOU press return yourself, not at automatic line wrap. If the message is written in an external message editor, some nifty re-flowing routines are used to strip out hard carriage returns. Reflowing is optional, and the program asks you after each message you write whether you want to reflow it or not (not globally set in a config). o Options to show kludge lines to certain users The security level at which to display kludge lines is sysop-selectable. If a user has access to the kludge display (s)he will also have access to turn them off at any time. o File Attach facilities for the sysop in 4D Trapdoor mode Any file can be attached to a netmail message. Either Plutonic or TrapToss can route file attaches, so you can choose which program actually creates the FLO file - either on the spot as the message is created, or later when the message is exported. Naturally, you should only choose to use ONE of these methods, unless you want to send two copies of the same file :-) o One-line summary display/reply mode Messages can be read either normally, or in the One Line Summary mode. Using this mode, the sender, receiver, subject and date of the message is displayed one line per message, and you can select to read/reply to any of these individual messages. This is great for reading through high traffic areas, and saves a LOT of time scanning through irrelevant messages. o Print Message Function Upon reading a message, it is possible to dump an ASCII interpretation of it to a file, or the printer. o Full Message Header Editor There's a full GUI-based message header editor which can change ALL the details of a message header using an easy point-and-click display, rather than using a binary hex editor. This is only available to users with Sysop security, and only in local mode (uses the mouse!) o Message Footer editing The footer of a message can be called up into your external editor, so any of it can be changed, even after you've written it. Well in fact ONLY after it's been written :-) o Selective Search Any or all of the From Name, To Name, Subject and Date fields can be searched for text, and if a match found the message displayed. o Echo Rules A textfile of echo rules or tips (anything really) can be stored in each message directory, and if present users can have it displayed for them. This is very handy to keep track of echo rules and functions on an AREA basis. o Last Message Read pointers Plutonic keeps track of the last message any user has read in every area, and also allows the user to over-ride the program's opinion and set this value manually. The number of users the program will keep track of is unlimited (set by a config option). o Tagline adding An optional feature is available where a random tagline will be selected from a file you provide and added at the foot of messages produced. My aim is to keep adding the features over time. Your suggestions will be quite beneficial to me and the program! Serial Matters: --------------- The program will run in remote mode as a door off the OzMetro BBS program. It could also be run off other SINGLE LINE BBS programs with a bit of kludging (contact me for details). The serial routines are NOT the inbuilt GFA routines, they were custom-written (originally for Metro BBS) and allow opening the modem in shared mode, specifying which serial device and unit number to use, and can be opened at ANY speed AmigaDOS has the power to support. ********************************************************************** Section 2 - Plutonic.cfg ********************************************************************** General Notes: -------------- Plutonic uses two config files. By default their names are: 'Plutonic.cfg' 'Plutonic.areas' Plutonic will first look for "Plutonic.cfg" in the current directory, and then it checks for "MAIL:Plutonic.cfg" If either of these are found (in that precedence - current dir over MAIL:) that will be the config name we use. If Plutonic has been run from OzMetro BBS, then _IF_ the program can find a "Plutonic.cfg" in the DOORFILE directory it was run from, then that will override all other filenames. There's a sample Plutonic.cfg file in the archive. It's suggested you start with that and edit it, add to it or remove keywords as your needs dictate. The main points to adhere to when creating or editing the Plutonic.cfg file are: Keywords are not case-sensitive, and the order in which you give them does not matter. If you use a keyword twice, then the last-specified value will be used. A mis-spelt keyword is simply ignored and has no effect. No warning is given. Leading and trailing SPACES only are stripped from your config. Please DO NOT use tab characters (ie expand tabs to spaces). To comment out a line its first non-space character should be a semicolon. You can only have comments on lines BY THEMSELVES, not following a keyword. DO NOT USE INVERTED COMMAS around filenames, etc. Just give the string as-is verbatim. It's okay to even have spaces in the filenames WITHOUT using inverted commas. (This only applies to Plutonic of course!) If you need to specify a directory name, then the trailing slash is completely optional. To Plutonic, "Mail:Inbound/" and "Mail:Inbound" mean the same thing. If the directory you are using is a device or assignment name, however you MUST specify the trailing colon. If you leave a keyword out, Plutonic will use a default value. In reality, you probably don't have to specify too many of these keywords, the default is generally what you need. Don't be overwhelmed by the 120 or so keywords Plutonic actually understands, you won't have to use anywhere near that many in your own configs. Dictionary of Plutonic.cfg Keywords: ------------------------------------ This section will explain ALL the keywords available from Plutonic.cfg. They are listed in alphabetical order. For information on the areas file refer to the next section. --------------- FORMAT OF ENTRY --------------- One or several paragraphs of description. Possible hints and tips. Please make note of all information given here. Default: Value used if the keyword is omitted from the config. Example: A way the line might appear in someone's config. ---------------- (NO)4DMSGDISPLAY ---------------- When you're looking at messages in a defined Matrix (not echomail) area the To and From addresses of the message are displayed. This keyword controls whether the address appears as the net and node numbers or the full zone, net, node and point numbers. The reason for this keyword is that a lot of tosser software doesn't support 4d message headers, only 2 dimensional. TrapToss 1.50 and above has the 4d message headers available which you should use - they are far superior to 2d headers. This is only a display keyword, having it set to on even if your tosser doesn't support 4d headers only has a cosmetic effect on these address displays. (You'll see REALLY LARGE Zone and Point numbers if your tosser is not operating in 4d header mode). Default: Turned on Example: NO4DMSGDISPLAY --------------- (NO)4DMSGHEADER --------------- This controls the actual message creation - whether to write out 4 dimensional headers or not. 4d headers are much better than 2 dimensional and TrapToss 1.50 and above supports them. You should only turn this off if using ancient tosser software that gets confused by 4 dimensional headers (I don't know of ANY). Default: Turned on Example: 4DMSGHEADER ------------------ (NO)ACTIVATEWINDOW ------------------ This only applies to remote callers - in local mode the screen is always popped the the front and made the active window. If you have a remote caller online, then you may or may not want the screen popped to the front as the user loads the door. If you're working on other things on your amiga, it's a pain in the neck for the door window to pop to the front and make itself active. If you're sitting across the room in an armchair, then it's a pain in the neck to have to get up and pop the screen to the front yourself so you can see what the user is doing when he enters the door. So it's up to you. This will probably be made more intelligent in the future by setting it as an ENVIRONMENT variable, only problem is that all the other doors you'll be running off the BBS have their own ideas about this screen activation process, so they'd have to be modified too... Default: Windows are activated and popped to the front Example: NOACTIVATEWINDOW ------------ (NO)ADDMSGID ------------ Defines whether or not a ^A-MSGID line is added to messages as they are created. It's probably a good idea to use this. In case you're interested the msgid timestamp used is the Unix timestamp in Hex. This is the number of seconds since Mindnight on 1 January 1970, and is exactly the same timestamp used by TrapToss for its MSGID lines and packet names. You may also have seen it as a TrxID in your TrapDoor logs. If you get carried away, there is a Plutonic utility called PluTrxID which will convert these Hex values into a human readable time and date. Default: Turned on Example: NOADDMSGID ----------- (NO)ADDPATH ----------- Defines whether or not Plutonic will 'start off' the PATH line by adding in your own node/point's details. TrapToss doesn't need it. A point should NOT use this at all, to avoid placing more than 2 dimensional info in the PATH: line. If you use a tosser which does not start the PATH: line off with your own node number then you will want to use this, however For a point, it's best to leave this totally blank rather than add more than 2-d info here. By 'more than 2d info', I refer to Zone and Point numbers. If a PATH looked like this: PATH: 123/456 789/110 234/6 No message tosser I know will have problems with it. However lines like: PATH: 3:123/456 456/890.12 622/401 54/99 712/611.1 will cause no end of trouble to some tossers (Foozle being a common one). Note TrapToss will not blink an eyelid if it DOES get PATH lines like this, so you WON'T EVEN KNOW about it. Traptoss handles it fine. Passing the messages like this to other systems may cause problems, however, you have to be on the lookout for it. There are a few switches in TrapToss also for controlling this function, BTW. Default: Turned off Example: ADDPATH ---------- (NO)ADDPID ---------- Defines whether or not a ^A-PID line is added. Works in conjunction with (NO)ADDTEAR (Please see the entry there for more). Default: Turned off Example: NOADDPID --------------------- (NO)ADDREALNAMEKLUDGE --------------------- Defines whether or not to add the ^A-REALNAME kludge line to messages written using an alias in areas you've setup as alias-able. This is the longest keyword Plutonic understands, incidentally! The realname kludge simply lets you and other systems know who the person who wrote the message really is. Most mail software doesn't allow users to see kludge lines at all. However Plutonic CAN display kludge lines to users of high enough security, so you may not want to use this to avoid giving away people's aliases if you allow a lot of users access to the kludge lines. In short, turned on is better for security, turned off is better for maintaining the user's alias as secret. I don't know about you, but I feel the first argument has a stronger case. Default: Turned on Example: NOADDREALNAMEKLUDGE ----------- (NO)ADDSEEN ----------- This is very similar to the (NO)ADDPATH funtion, only working on the initial SEEN-BY instead of the PATH line. Generally this will not be required. Most tossers end up putting your node number in messages they export, TrapToss is no exception - it will add any node number(s) you like in ADDITION to your own! (see the ADDNODES command in TrapToss). Make sure your own node number does get into messages you export, however, as without it, there's nothing then protecting you from having it bounce back! If you're a point, it's nice to know your bossnode should be able to strip out anything unseemly in the SEEN-BYs. Default: Turned Off Example: ADDSEEN -------------- (NO)ADDTAGLINE -------------- Defines whether or not to apend a random tagline to the foot of your messages from a textfile of taglines. This was pretty easy to add, and gives Plutonic one of the nicer "show-off" features of other editors. Another way of turning this off is simply not having a tagline file, this keyword allows you to turn it on or off without having to rename or move the tagline file, however. You also need another keyword telling Plutonic the name of the tagline file to use. For specific information on the tagline file itself, see under the TAGLINEFILE keyword, below. Default: Turned Off Example: ADDTAGLINE ----------- (NO)ADDTEAR ----------- Defines whether either a 'blank' [---] tearline is added or an annotated one [--- Plutonic X.xx]. This works in conjunction with NOPID/ADDPID. You cannot specify to have BOTH a tearline and a PID. IF you do, the Tearline will take precedence. Make sure you read the tearline options in the TrapToss manual again, before using these, because TrapToss can override your choice when the messages are exported :-) Default is to add a tearline, not a PID. I find it more interesting where ALL message readers can see it, rather than only those with access to the kludge lines. Default: Turned ON Example: NOADDTEAR -------- AREAFILE -------- If specified in the config, then instead of using the default Mail:Plutonic.areas as the areas file, you may specify your own. The areas filename can also be given from the command line, and if so the command line will over-ride this keyword in the config. Thus, if running from OzMetro BBS, TWO methods are available to you to get Plutonic to select its AREAS file: Firstly, since Plutonic looks firstly in the DOORFILE directory for a config file, then you can have a Plutonic.cfg for each door directory specifying a different AREAFILE ine each one. Secondly, you can set the door program up as a script, to specify the areas file from the command line. EG Filename of script: "Door.exe" Contents - 1 line: MAIL:Bin/Plutonic Mail:Configs/MsgAreas-1.cfg (Don't forget to set the Executable and Script bits of the script). Default: Mail:Plutonic.areas Examples: AREAFILE Mail:Configs/Areas.1 AREAFILE Mail:Plutonic.one --------- ATTACHDIR --------- When selecting to file attach to a Netmail message, a file requester is brought up. This parameter allows you to determine the initial directory this File Requester will look in. This wasn't as useful an addition as I thought, because I file attach from all over the place anyway. However the Inbound directory seems to be most commonly used, and I have it set there at the moment. NB: Ensure this directory exists, please. Default: SYS: Example: ATTACHDIR MAIL:Fred/Attaches/ ------- BBSNAME ------- The name of the host bulletin board. Basically irrelevant for local use, but what the user sees upon logout. It may be used in other functions later (such as automatic messages, for instance). Default: Unnamed BBS Example: BBSNAME Inquestor --------------------- COLO(U)R1 - COLO(U)R7 --------------------- These keywords have both American (COLOR) and English (COLOUR) equivalents. Since I speak Australian, I use the form COLOUR in these docs. You may substitute COLOR for it, however if you like, it still works the same. (You can even mix them eg: COLOUR1, COLOR2, etc) This allows you to play around with the display in a limited fashion. Certain parts of text can be printed in different colours. I allow you to remap the major ANSI colours used. Some caveats: NEVER! Change colours 1 and 7 (ie Red and White). Colour 4 (dark blue) is often invisible on certain terminals. It will also cause a mono IBM monitor to use underlining from there on. I find it best to avoid it for remote users. However it still can be remapped, and if you are only using the system in local console mode, then feel free to use it! For best effects for user remote terminals, only swap around the assignments for colours 2, 3, 5 & 6. At least it gives you something to play with. The black background, incidentally is FIXED! You can duplicate colours - I haven't tried doing this. Experiment away! Default: The numbers correspond. (ie COLOUR1=1; COLOUR5=5, etc). Example: (This one is quite effective) COLOUR1 1 COLOUR2 6 COLOUR3 5 COLOUR4 4 COLOUR5 2 COLOUR6 3 COLOUR7 7 ------------- (NO)DEFATTACH ------------- This keyword applies to file attaches. Thus it's only available at the local console, and is only applicable in Netmail (Matrix) message areas. If you turn it on (DEFATTACH), then after posting a netmail message you will be asked (inter alia) "Attach a file (Y/n)?". Then, you can press "N" to answer NO, press "Y" to answer YES, or hit return and get the letter which is capitalised in the list of alternatives (in this case, YES). If you turn this off, the question will be asked in the form "Attach a file (y/N)?" and hitting return will answer NO This is useful if you keep forgetting to attach files like me, and you can just hit the cancel gadget in the requester to get out... Default: FALSE (ie will answer NO to "Attach a file?" with a return) Example: DEFATTACH ----------- DEFAULTAREA ----------- The message area number the user is deposited in after the program first loads up. Will correspond to the 'n'th entry in the Plutonic.Areas file. If you specify a value larger than the number of areas you have, it will be ignored and the users will be at area number 1. Default: 1 Example: DEFAULTAREA 6 --------------- (NO)DEFINTERNAL --------------- This one changes the way Plutonic asks you which editor to use for writing your messages. It only works in local mode (remote, you don't get a choice, you have to use the internal editor with its serial routines, of course). If you turn this on (DEFINTERNAL) then when you're starting to write a message or reply the program will ask: Use your own editor (y/N)? And just hitting return will answer NO to the question (you can also actually hit the "Y" or "N" key to give a definite answer, BTW). If this is false (NODEFINTERNAL) then the question will be asked as Use your own editor (Y/n)? And a Return-key will answer YES Default: TRUE (ie will answer NO to "Use your own editor?" with a return) Example: NODEFINTERNAL ------------- (NO)DEFREFLOW ------------- This works in a similar way to the DEFINTERNAL and DEFATTACH keywords in controlling the default YES/NO answer to a question. In this case it's whether or not to reflow the message text written in your external editor (messages produced by the internal editor don't need re-flowing, the only hard carriage returns in them are the ones added when YOU press the return key, not at end of line). Unless you are including formatted tables or logs (etc) in your message text you should always get Plutonic to reflow the message so it can be correctly formatted and quoted on other software platforms, irrespective of the line length they have. I'll include some notes on the reflow algorithm elsewhere in these docs, because there will be cases where you want some parts of the message to be reflowed and other parts not. Default: TRUE (ie answers YES on a return) Example: NODEFREFLOW ------ DEVICE ------ For remote use, the name of the serial device to use. Any devicename can be specified here. BEWARE! AmigaDOS device names are case sensitive. The general convention is to use all lowercase. But make sure the library in your libs: directory matches what you specify here in this keyword. Default: serial.device Example: baudbandit.device ------ EDITOR ------ The name of your favourite text editor to use in writing messages. Only available for local console use (not remote). The name of the edit file is currently fixed. The filename of the edit file is simply tacked on to the end of the string you specify in this keyword. Say you were using EDITOR ed, then the command that would be run when writing messages would be: ed ram:Plutonic.tmp For non-sticky editors, an aditional 'Press Return' to re-enter the program is in place. This nicely stops all the CPU usage of the program at the time, while waiting for you to compose your message. Don't forget to SAVE your message in the editor before you return to Plutonic!! Default: C:ed Example: EDITOR DH0:c/AZ EDITOR ced -keepio ------------- (NO)FLOATTACH ------------- This controls what actually produces the FLO file with the full pathspec of the attached file in order for TrapDoor to send it. Both Plutonic and TrapToss can route file attaches, and you can't have them BOTH doing it otherwise the receiver will get TWO copies of the file you're attaching. Turning it on (FLOATTACH) will make Pluto create a FLO file for any file you attach. This file is always created in 4d outbound naming format. The full path and filename of the file will be written to the FLO file, and the SUBJECT of the message will consist of the filename ONLY of the file (ie no path details). If you need to change this in any way, (eg you attach the WRONG file), please remember to edit the FLO file produced for that system. Turning it off (NOFLOATTACH) will mean the FULL path/filename is copied to the subject field; leaving TrapToss itself to make the relevant .DLO file provided of course you have the keyword for file attaches turned ON in TrapToss. In this case, when TrapToss exports the message the subject field will be changed to merely list the file's name. BEFORE it's exported, the full pathname must be present to allow TrapToss to find the file! You can change these filenames before the messages are exported by simply using the message Header Editor to change the subject of the message. If it's already exported, you will again need to edit the FLO file for that node. Default: Turned ON Example: NOFLOATTACH ------------- (NO)GATEROUTE ------------- This will work on matrix mail to either send any INTL messages to the ZoneGate or simply to the address of the system. If you are using TrapToss there is a separate switch in TrapToss which completely over-rides whatever you have set in Plutonic, so if you're using TrapToss it doesn't matter what you use (I suggest you use NOGATEROUTE really). I'm not sure how other tossers handle this, so I've left the keyword in just in case it's useful. GateRouting is a pretty convoluted message function which many people (including some tosser authors) do not seem to understand. So only turn this on if you know what you're doing. Default: No gate-routing Example: GATEROUTE ----------------- HIASCII & LOASCII ----------------- These are the ASCII character values the door will use for input via the internal editor. This can be very handy. For example filtering out Ascii 27 (the escape character) will eliminate the use of ANSI codes messages, generally a no-no in Fido. Setting HiAscii to 127 will also prevent users sending Hi-Ascii characters into messages, often undesirable, but becoming much more frequent these days, particularly for messages from European writers (Hi Rene). To avoid potential problems, the lowest you are able to set LOASCII to is ASCII 15. Specifying a value lower than this will see 15 used anyway! If you DO wish to allow users to write ANSI messages, it's best to use the LOASCII value of 26 or less. And if IBM graphics characters and diacritical marks on letters are common in your area, you'd best not impose an upper limit and set HiAscii to 255 To see what characters have certain ASCII codes, please consult an ASCII chart - they are common in modem manuals and in other computer documentation. If you're completely confused by this, forget all about it, and leave the keywords out of your config. The defaults will do you. Default: 125 (HIASCII) 28 (LOASCII) Example: HIASCII 255 LOASCII 15 ------- INBOUND ------- The name of your inbound directory. Currently this isn't actually used ANYWHERE, but it's certainly within the bounds of possibility that we will use it at some stage later :-) Default: MAIL:Inbound/ Examples: INBOUND DF0:FZ/IN/ INBOUND IN: ------------------ KLUDGEOFF/KLUDGEON ------------------ This defines the setting of kludge line display for users with enough security to be shown the kludges (see SHOWKLUDGE) logging in at the local console. For remote users, if they have enough security they will be asked whether or not to show kludges when they first enter the door (along with questions about if they want ANSI and if they want to change the screen height). Locally these questions aren't asked - the door starts loading the areas file straight away. So a setting is needed in your config file to let Pluto know your choice. Don't forget, once you're in the program, you can always turn the kludge line display on or off from the [A]lter Setup option on the main menu. Default: Turned off Example: KLUDGEON ----- LEV-1 ----- The security level of User #1 (for now the only user, multiple users from the local console will be available soon). If you are the sysop, and wish to enable all the sysop functions, set it to the same level you have defined for this. See under SYSLEVEL for more information. Metro levels are from 1-9, Paragon levels are 1-15. It really is unimportant how big a number you specify, it can be up to 2,100,000,000-odd (ie 4 byte integer) :-) Recommended level for an OZMetro sysop is 9. (IE the highest level available in OzMetro). You are strongly recommended to use security levels corresponding with any BBS packages you use or may intend to use. Note that this configuration keyword only applies to local console runs. If entered from the BBS, you get the security level the BBS sets. Default: 5 Example: LEV-1 9 --------------- (NO)LOCKEDMODEM --------------- A boolean value as to whether you are running a locked modem or not. If you specify YES, then the modem will always be opened at the rate specified in MAXBAUD. Otherwise, the modem will be opened at the value given in the ram:userdata file by OzMetro. Systems running with locked modems do not, therefore need to worry about the baud rate supplied to the door in ram:userdata it can ALWAYS be this value. However if you DO use the LOCKEDMODEM setting, please ensure you have a valid value for the MAXBAUD parameter. Naturally, this only applies to Door use - not local console. Default: FALSE (ie NOLOCKEDMODEM) Example: LOCKEDMODEM ----------------------- (NO)MATCH1 - (NO)MATCH9 ----------------------- The MATCH feature has been introduced to select groups of message areas. In Plutonic.areas, each second line has a 'name' of the message area. It's used for display and easy reference. Now, you can precede this line with a single digit (0-9) to filter your message areas into groups (eg all Fido mail might be group 1, AmigaNet might be group 3, etc, etc). To activate this completely optional feature, simply edit Plutonic.areas so that each number 2 line has a digit in front of it. EG Say the area initially said: MAIL:Matrix Fido NET Mail 1 2 This origin line is not used, but MUST be here!! 3:622/401.0 MATRIX KEEP 70 If we wish to put this in group 1, simply add in a 1 before the area description (every 2nd line): MAIL:Matrix 1Fido NET Mail <========= (1 added in front of area name) 1 2 ... A line commencing with a 0 or with a non-digit character will be classified as group zero. Group 0 echoes ALWAYS display in Plutonic. There is no way to turn them off. It is always a very advisable idea to always have AT LEAST ONE group 0 echo area, simply to avoid the problem of loading up Plutonic and not being able to find ANY areas to choose from! The other groups, 1 to 9, are up to you. Any area can be classified as anything, as messages from ANY group are selectable from within Plutonic.cfg. Areas not loaded, incidentally, do NOT use any memory space at all while the program is running. To choose which areas you will be reading, simply include an appropriate MATCH statement in your PLUTONIC.cfg. There are 9 such statements, MATCH1 - MATCH9 (note they are one word, with no space). There are also 9 corresponding NOMATCHx statements to turn message groups on off. The default action for each message group is ON, so unless you actually specify NOMATCHx then the areas WILL be displayed. If you have Sysop security, you can choose the [L]oad Message Areas from the main menu, and you will see that you can toggle each of the areas WHILE THE PROGRAM IS RUNNING, without need to edit your Plutonic.areas file all the time. If you have a lot of areas, then just get Plutonic to display a few areas you off, then switch them on and off as you need to as you use the program. Default: ALL areas will be loaded Example: NOMATCH1 MATCH2 MATCH3 NOMATCH4 MATCH5 NOMATCH6 NOMATCH7 MATCH8 NOMATCH9 ------------- (NO)MATRIXPID ------------- This defines whether Plutonic will add a PID line to your netmail (matrix) messages or not. It's different to the ADDPID keyword in that If you are specifying to add a TEARLINE instead, your netmails would go out "unbranded". This allows you to use a PID line in Netmail and a tearline in echomail. If you are specifying ADDPID, then MATRIXPID is automatically set on, regardless of what you have for this keyword. (I think - I just had a quick look at the source, and I'm not 100% sure on this). I recommend you do turn this keyword on, however, so your netmails always carry a small advertisement for the program. Default: Turned on Example: MATRIXPID -------- MAXAREAS -------- The number of message areas to allocate memory for. Can easily be added to (or diminished) by merely specifying a new value. It must allow space for each message area specified in the Plutonic.Areas file, otherwise message areas beyond this number will not appear to the user. Take the number of lines in Plutonic.Areas, divide by 7 and that's how many areas you have. Round this value up a small amount for safety, and use that resultant value. Don't forget to increase this value when you add more areas. The number of message areas Plutonic can have set up is, in theory unlimited. Default: 100 Example: MAXAREAS 50 ------- MAXBAUD ------- If you are running with a locked modem, the baud rate at which to open the modem. This should correspond to the value you use elsewhere (and in Metro systems with the one in the Metro.cfg and Trapdoor.cfg). The Minimum value for this is 300, and it's advisable to only use multiples that are valid baud rates (eg 300, 1200, 2400, 4800, 7200, 9600, 12000, 14400, 19200, 38400). This only applies to use in remote mode, of course. Default: 19200 Example: MAXBAUD 2400 -------------------- MAXLINES & MAXLENGTH -------------------- These are settings for the inbuilt line editor. They determine how large a message can be created, and at what point to wrap the display text in the editor. The MAXLENGTH value is somewhat diminished in importance since the removal of the hard carriage returns in v 1.50, but does indicate at what point to wrap the user's text for display purposes. 5 characters should be allowed for the line numbers printed up (ie on our 79 column screen, you may use up to 74 (no greater!) as the MAXLENGTH value). The MAXLINES value specifies how many lines a user's message can be. Very large values can be specified, at the only expense ram. Not many users write >200 line messages anyway, and a value of 250 has been used at this end for some time with no problems. Note Well: The message editor actually allows 2 less lines than what you specify. Sorry about this. To give the users access to 100 line messages, you need to specify 102 in the config. Using 100 will allow them 98 lines. I hadn't gotten around to fixing this for this release, and I'm not going to bother. Too late now. Default: 100 (MAXLINES) 64 (MAXLENGTH) Examples: MAXLINES 252 MAXLENGTH 72 ------- MAXTIME ------- The time to allow local console users access to the program. In other words, the user's time LIMIT! Since you probably don't want to give yourself a limit, you will set this to a high value. (It's in minutes, by the way). In case you accidentally leave the program going, it will, however, time you out after 10 minutes (for sysop level) and 5 minutes for other level users, so the MAXTIME value isn't of much use really unless you wish to remind yourself how long you've been at it, by quitting surprisingly. Plutonic will never kick you off while you are IN the editor, if your time expires. It will still quit if you don't press a key for 10 minutes, however. If you are going to leave the system while halfway through writing a message, make sure you press both mouse-buttons together and pull up the Quit alert (which will cancel out the idle timer). Don't forget the time limit a BBS user will get is determined by OzMetro itself, not this value in the config. Default: 120 Example: MAXTIME 999 ------------ (NO)NODELIST ------------ This is the keyword we use to turn nodelist support off. Well, in fact it really determines whether or not we will allow a message to be posted to a node NOT in our nodelist. (This might well be due to the fact that there IS no nodelist, or maybe the node number is simply typo'd). So you can still make use of the nodelist even though you have specified NONODELIST in the configs. If you don't have a nodelist, then you MUST specify NONODELIST, or else you won't be able to write netmail to anybody. See NODELISTPATH for important info should you not have a nodelist all setup and compiled. If you have a nodelist, then any address you are attempting to send netmail to will be checked. If you specify NODELIST, then Plutonic simply won't allow you to send the message to an unlisted node number. (It's quite insistent). If you have NONODELIST, it will take your word for it that the node exists, and send anyway. As a point, I'd be using NONODELIST, then even if the system you're writing to doesn't come up in your nodelist Plutonic will still let you post the message. (EG you may have a Zone 3 only nodelist and need to write to someone in Zone 1 or 2). As a node, however, I use NODELIST to stop users writing to non-existant nodes (but I do run with a full Fido nodelist, along with 10 others). Default: Turned Off Example: NODELIST ------------ NODELISTPATH ------------ The directory where your Traplisted Nodelist files live. The trailing slash is optional (as always in Plutonic). You should have a FidoNet.index file here under this directory. If you do so, and have traplist.library around, Plutonic should be able to get information from your nodelists. Note that if you DON'T have a nodelist setup, you must still specify a path here. I'd recommend the use of RAM: in a case like this. Default: NODELIST: Example: NODELISTPATH MAIL:Nodelist NODELISTPATH RAM: -------- OUTBOUND -------- The name of your outbound directory. This is used to generate .FLO files when you attach a file to a netmail message, with FLOATTACH turned on. Otherwise, it's not actually used. Default: MAIL:Outbound/ Examples: OUTBOUND DF0:FZ/out/ OUTBOUND OUT: OUTBOUND DH0:Mails/Xtra/Outbound ------------------------ QUOTELINES & QUOTELENGTH ------------------------ Sets aside the maximum amount of memory to reserve for quoting purposes. Generally, very high values pose no problems at all on 1+ meg machines. QUOTELINES is the number of LINES in the input message allowable to be quoted. If using the internal editor, you can't enter a quote beyond line 999 so values above this are really only useful for when you use an external editor. The QUOTELENGTH is the raw size of the input message, in bytes. When the program used to re-flow text before quoting it many moons ago, there was need for a limit. (Come to think of it, reflowing text to be quoted may well be added back in at a later stage, given the rise in popularity of offline readers which insist on using hard carriage returns all the time quite contrary to the FTS-1 specification). For now, this limit appears to be next to useless. Set a high value if you can afford the memory. Maybe 50-100k. This amount of memory will in practice NEVER be used because messages usually just aren't this long... These keywords are actually a hangover from the olden days of 1991, so your best bet is probably to leave them out of the config and take the defaults. Default: 999 (QUOTELINES) 32768 (QUOTELENGTH) Example: QUOTELINES 30000 QUOTELENGTH 60000 ----------------- SCREEN0 - SCREEN7 ----------------- These 8 keywords are similar to the COLOURS command in TrapDoor, with a few extensions. Also, since COLO(U)R was already being used as a Plutonic keyword I had to choose a different name. The important distinction between SCREENx and COLOURx is that COLOURx actually changes the display that the REMOTE caller sees, by altering the ANSI code that is sent to the modem (and local screen). SCREENx only affects the display at YOUR end. If ANSI colour 2 is sent to the remote, then the remote caller will see green (unless he's remapped HIS colour registers in the comms program, of course). However you can remap your local display so that this screen colour on the local console is anything at all. Plutonic uses an 8 colour console window for its display. By default it is mapped almost to ANSI standards, with a very dark brown background and the seven colours nearly matching the ANSI settings. The ANSI standard colour maps are: 0 - black 1 - red 2 - green 3 - yellow 4 - blue 5 - magenta (purple) 6 - cyan (aqua) 7 - white Using the SCREENx commands, you can select exactly what colours the screen uses if you get sick of the ANSI mapping. For each SCREENx keyword you need to specify a three-digit hexadecimal value indicating how much Red, Green and Blue that register should get. Take as an example the SCREEN0 command. This is black. To get a jet black colour from the keyword you'll need to specify no red, no green and no blue. In the config this would appear as SCREEN0 000. The first digit of the argument is the amount of red, the second digit, blue, the third the amount of green. The values have 16 posible settings, from 0 to F. Let's take a look at a few more examples: To get a bright white (say for SCREEN7) then you need to use as much red green and blue as possible. And in Hex, the highest value you can use is "F" (decimal 15). So you'd need to use SCREEN7 FFF. If you want a really bright red colour, you simply have to use a high value for red, no blue and no green. So you might use SCREEN1 B00. To get purple, you need a lot of red, a lot of blue, and not much green at all. So you might use SCREEN5 C2B. If you experiment with these settings and come up with a colour combination that looks really good, please let me know what it was. I haven't had enough time to experiment much myself, and I'm looking for a change after using an ANSI mapping for three years. Default: SCREEN0 141 SCREEN1 D62 SCREEN2 2D2 SCREEN3 CB2 SCREEN4 56C SCREEN5 B6B SCREEN6 5DC SCREEN7 FEF Example: (these are the pure ANSI standards settings) Screen0 000 Screen1 F11 Screen2 1F1 Screen3 FF1 Screen4 55F Screen5 F1F Screen6 1FF Screen7 FFF ---------- SHOWKLUDGE ---------- The security level at which to allow display of the MSGID REPLY PID EID INTL FMPT TOPT SEEN-BY PATH and other DietIfna Kludge lines. The user still has the option to not display them - this merely gives him ACCESS to turn it on or off. Generally no harm is done allowing users access to the kludge lines - indeed they get to see the wider picture when it comes to three word messages and the associated bulk, however you may care not to allow them access to this. Set this value to the security level of users you can trust with this info. To disable it entirely, use a massively high level (eg 999), and then kludge lines will NEVER be visible - even to the sysop! Default: 5 Example: SHOWKLUDGE 3 ------------------- SIGNOFF1 - SIGNOFF3 ------------------- This function allows automatic adding of up to three sign-off lines to your messages. To save adding to useless echo bulk, I have decided to limit you to three lines ONLY, even though adding more would be simplicity in itself. To use this function, you MUST specify a SIGNOFF1 parameter. This really turns the function on and off. If there is no SIGNOFF1 parameter then SIGNOFF2 and SIGNOFF3 will not be used regardless of whether you have set them or not. SIGNOFF1 defaults to a NULL, so unless you add them to the config, they won't be used. To turn them off, simply leave the SIGNOFF1 keyword out of the config (or simply comment it out). The text used in the SIGNOFF keywords is limited to 78 characters per keyword. If you use a longer argument, it will be truncated. Leading and trailing spaces are NOT stripped from this string, allowing you to indent your signature if you like. If you are using your own editor, the text will be placed inside the temp file your editor opens. You are then free to change it as you desire while writing the message. If you are using the internal line editor, it will be tacked on to the end of your message AFTER you finish writing it. A blank line is inserted before your signature, there's no need to add one at the end when you write your message from the internal editor. Just get to the last line and go /S (save). If you choose to re-flow a message written in the external editor, and you are using more than a one line signoff, you will almost certainly not want the signature part of the message re-flowed. To do this you should add 1 space in front of each signature line (anything indented at least one space in an externally written editor will not be reflowed). If you should happen to be writing in an area which allows ALIAS names, and you use one, then the SIGNOFF lines WON'T be added to the message, to preserve your anonymity. Naturally, so remote users don't get YOUR signoff, this only works in LOCAL mode. If you've logged into your own system from remote, don't forget to sign off yourself :-) Default: Not to add a signature at all Examples: SIGNOFF1 | Peter Deane Fido: 3:622/401 | SIGNOFF2 | Plutonic Development AmigaNet: 41:200/401 | SIGNOFF3 | BBS Phone +61-49-721647 GlobalNet: 54:6101/401 | SIGNOFF1 Cheers, TREV SIGNOFF1 Regards, SIGNOFF3 -Peter! (Note that in the above example, SIGNOFF2 since it doesn't exist will be ignored when the program enters the signature into the message). ---------------- SWIDTH & SHEIGHT ---------------- The size of the screen you wish Plutonic to open. All values work, but please specify a width of 640 - it looks real weird otherwise. The Height is what the NTSC/PAL users will need to look at. Interlace is NOT supported (hey, my head! - 1084 monitor here). It will probably be available in a future upgrade. For NTSC use 200, for PAL, use 256. Longer/shorter screens are again possible, but of not much practical use. Default: 640 (width) 200 (height) Example: SWIDTH 640 SHEIGHT 256 -------- SYSLEVEL -------- The level at which to allow access to sysop functions (ie File attaches from the local console, access to the message attribute bits on netmail (crash/hold/normal/KillSent), the sysop functions after each message and the access to ALL private messages). You should be careful when defining this value, as it may allow a few surprise accesses. I recommend that really only one person should have this power. You should choose a value for this which corresponds to the Sysop level on any BBS package you may be using. For instance, in OzMetro the sysop level is 9 - you should therefore use a corresponding value of 9 in Plutonic. Default: 9 Example: SYSLEVEL 7 ----------- SYSTEMFILES ----------- The place to look for BBS-specific files - meaning currently only the BBSFILES/Stats and BBSFILES/log files kept by OzMetro. This specifies what is added in front of the 'BBSFILES/' path. This is only used if you enable the UPDATESTATS and UPDATELOG features, so can safely be ignored on systems not using these features. Also, due to a change in the system file device policy in OzMetro, if you are using Plutonic in conjunction with OzMetro, you MUST have these files under the BBS: assignment. In reality you should probably leave this value out, because the default is exactly what you need. Default: BBS: Example: SYSTEMFILES Paragon:Metro/ ----------- TAGLINEFILE ----------- Keyword telling Plutonic where to find its taglines if you have turned on the option to do add them. It defaults to a file called Mail:Plutonic.tags. If you do call your tagline file Mail:Plutonic.tags then you don't need to use this keyword. If Plutonic cannot locate the file, it will act as if you had selected NOADDTAGLINE. Pluto doesn't do any checking on the file, so read on to ensure you get it in the right format. The TagFile Pluto uses is pretty basic, and allows for either one-line tags, or two-line tags. The file is simply an ascii file of plain text. No line should be longer than 74 characters, otherwise it will be truncated to 74 characters. You can use Hi ascii characters or even ANSI codes in it if you like, however be aware that a lot of echoes have banned the use of them. Each line should start hard against the left hand margin, unless it's the SECOND (continuation) line of a pair. In that case the second line needs to be indented one or more spaces from the left margin. Plutonic will never use the last 80 characters of the file, so the last line should be a dummy (but these last 80 characters HAVE TO BE THERE). Here's a very short example from the tagline file I'm using at the moment: You have a tendency to feel you are superior to most computers. You have the right to remain silent. You have an ambitious nature and may make a name for yourself. You will attract cultured and artistic people to your home. You'll never be the man your mother was. You're never alone with schizophrenia. This last line will never get used and must start hard against the left edge It's a good idea to add two or three blank lines at the end of the file, too. Mind you, the odds of selecting this last line are pretty slim (depending on the size of the file), but take my word for it - Make sure the last dummy line is pretty long and there's a few blank lines after it. Your luck may not hold! As you can see, the second line of a pair is indented by a space. If Plutonic selects the first line of a pair, it will read in the next line and insert a two-line tagline. Only single and double line tags can be used. Multiple line tags just unnecessarily add to message bulk and are a burden on the network. It's pretty easy, really. You can easily convert tagline files from other point packages for use in Plutonic, probably with a Macro in your text editor. Thanks to Nico Francois for the inspiration for the implementation of tagline addition. It's the same as Spot, which I find to be very neat and unobtrusive. I will include a reasonably large tagline file with this archive. The length of this file will not matter, in theory you could use the Fido Nodelist or an even bigger file, and it shouldn't make ANY difference in memory usage or speed of tagline selection. Oh, BTW to avoid problems, the NAME of the tagline file needs to be greater than two characters in length. If you have specified a filename of only 1 or 2 characters in total (including the path) then tagline adding will not be enabled. Default: Mail:Plutonic.tags Example: TAGLINEFILE BBS:Textfiles1/Fortunes -------------- (NO)TRANSAMIGA -------------- Plutonic can create Message.BBS files in the message directorys for the benefit of TransAmiga. The reason this is done, is because TransAmiga, unlike Plutonic, accepts the index pointer's word for the number of messages in a base absolutely. So if the REAL hiwater was 10, and the index said that it was 8, the next message that Transamiga saves is 9.MSG!! Plutonic checks its index and then also checks if a message EXISTS before it uses that message number (bumping it until it finds a message number that DOESN'T exist). So if you are running a dual system (ie both OzMetro/Plutonic and Transamiga or running Pluto as a door off Transamiga) users can safely write messages in Plutonic that WON'T get overwritten by TransAmiga itself. If you DO NOT wish to create Transamiga's Message.BBS files, do nothing, or specify NOTRANSAMIGA. If you do want to create these files, then use the config keyword and Pluto will create Message.BBS files in addition to its own. Default: FALSE (IE NOTRANSAMIGA) Example: TRANSAMIGA ---- UNIT ---- The serial-type device unit number. Generally 0, but may be different given various types of serial boards. Default: 0 Example: UNIT 1 ----- UNUM1 ----- The User Number of the (first and currently only) local user. This is important for keeping track of the last_message_read numbers in each base. Generally it's user number 1. There MUST be a correspondence between this number, and those given by the BBS in the userdata file, otherwise the LMR pointers are next to useless (and possibly worse as they will be erroneous). Note that this configuration keyword only applies to local console runs. If Pluto is loaded from the BBS, the user number given to it by the BBS will be used. Default: 1 Example: UNUM1 15 ------------- (NO)UPDATELOG ------------- DO NOT USE THIS AT ALL. You have been warned! Leave it out of your config file entirely. Default: FALSE (ie NOUPDATELOG) Example: NOUPDATELOG --------------- (NO)UPDATESTATS --------------- Will add in messages written at the local console into the BBS:BBSFILES/Stats file, for the status pane line. Useful for keeping tabs on your own message-writing efforts. This is an OzMetro format file which Plutonic supports, and can harmlessly be updated, even if you're not running OzMetro. Non-OzMetro users can support this if they create a directory called 'BBSFILES' in the path specified in the SYSTEMFILES entry. Default: FALSE (ie NOUPDATESTATS) Example: UPDATESTATS ----- USER1 ----- The name of the first user of the program (ie YOUR name). Capitalisation is unimportant, as the program will run ALL usernames it is given (eg from the BBS) through a parser which ensures correct capitalisation except for the Macs - EG "MACDONALD" becomes "Macdonald", not "MacDonald" as they usually prefer. Support for more users is coming, but probably won't make it for v 2.0 [Hmm, it didn't]. I get around it now by keeping a spare config (in this example, called Plutonic.cfg.new) and renaming it before running the program. EG: rename MAIL:Plutonic.cfg MAIL:Plutonic.cfg.temp rename MAIL:Plutonic.cfg.new MAIL:Plutonic.cfg run PLUTONIC wait 30 sec rename MAIL:Plutonic.cfg MAIL:Plutonic.cfg.new rename MAIL:Plutonic.cfg.temp MAIL:Plutonic.cfg Important points are to give Plutonic enough time to read the config, and to reverse the renaming order on the way out. Note that this configuration keyword only applies to local console runs. If entered from the BBS, the BBS details over-ride the config. Default: Unnamed User Example: USER1 PETER DEANE ----- USERS ----- Allocates space in the Last_Message_Read indices for the number of users you are likely to have on the system. You MUST ensure that there is ample space in this file for the number of users you are EVER likely to have, because the only way you can currently increase the size of this file is to delete the old one and generate a new one, losing the last message read values for everyone in the process. (Actually not true - contact me if you'd like to know how). It only takes 4 bytes of diskspace per user to store the Last Message Read pointers. EG for 500 users, 2,000 bytes (plus 512 for the file header) will be used on disk (about the size of a typical message - maybe a touch longer). So always OVERestimate this value if ever in doubt. I recommend you set the value to AT LEAST 3 times as many users you ever expect to have - a bigger multiple if you are a new BBS. Default: 500 Example: USERS 1000 ---- ZONE ---- The Zone of your primary mailing address. This will be used as a default should you omit it when it may be required. Default: 3 Example: ZONE 1 ********************************************************************** Section 3 - Plutonic.areas ********************************************************************** General: -------- This is a 7-line multiple ASCII file generated by either a text editor or the PlutAreas file editor included in the archive. It has gone through a few changes over the years, but the file has always remained backwards compatible, despite having many more configuration options implemented in the file. One advantage of this method is that in theory unlimited areas are possible (only limited by memory - at less than 200 bytes per area). However, the area numbers will change depending on the layout of the file. If you add an area into the file, then all areas beyond that record all move down one place. In the archive I'll include an areas file showing how to setup a Netmail area, a BadMail area, a normal echo area, an ALIAS area, a Private echo and a local (BBS-only) area. You can then edit or add to that as per your needs. Specifying the Areas file: -------------------------- There are three ways of specifying the areas file Plutonic uses. First, the easy way. Simply name your areas file MAIL:Plutonic.areas. I've been using this method from the very start, and it's what I recommend. However there may be cases when you don't want to use the default area file - maybe you have several invocations of Plutonic running off your BBS. You could have one invocation calling FidoNet messages, another calling the AmigaNet messages, another calling AnOtherNet messages, etc. You might also separate your areas on a topical basis - eg a Plutonic setup with all the For Sale echoes, another with all the Amiga areas, another with the Point/Comms message areas, etc, etc. To do this, you'll need an areas file for each invocation, and Plutonic needs to be told the filename to use. (Hint: this is a workaround for the 20 message area limit in the unregistered version - I won't say more). Note that you will ALSO need a file MAIL:Plutonic.areas with ALL your areas listed in it for running PlutScan (Plutonic's area scanner). So don't actually use MAIL:Plutonic.areas as the name of a PARTIAL areas file, okay? You can also specify the filename of the areas file from the command line. Whe you run Plutonic it understands one command line argument - the name of the areas file. Here are several possible invocations of Plutonic using a custom areas file: Plutonic MAIL:Configs/PlutAreas1 Plutonic S:Fido.areas Plutonic Plutonic.areas (In the latter case the Plutonic.areas file in the CURRENT directory - as distinct from MAIL:Plutonic.areas - would be used) The third way of specifying the areas file is to use the AREAFILE keyword in Plutonic.cfg. Since there is a range of methods Plutonic uses to find its config file, using the AREAFILE keyword is another flexible way of using a non-default areas file. See above in the keyword dictionary for full usage details of the AREAFILE keyword. Areas File Format: ------------------ The file is an ascii file. You use either a text editor or the specialised PlutAreas program for its maintenance. It's imperative that you always keep the entries always in multiples of 7 lines, which can be somewhat tricky unless you're careful. I suggest you start using the PlutAreas editor to begin with, but as your area file grows and you gain confidence, you can start editing it with a text editor. By keeping the file in ASCII format you have the best of both worlds - the ease of the specialised editor, and the flexibility of your favourite text editor. Notes for using PlutAreas will be given shortly after we have a look at the format of the areas file, and the keywords and commands are explained. Note: the numbers given below DO NOT form part of the config. Here is the basic skeleton of the areas file: 1) Directory Name 2) Name of area on the BBS/Local Screen 3) Read security 4) Write security 5) Origin line. 53 Characters maximum 6) Node number for this area 7) FLAGS 7+1) Directory Name 7+2) Name of area on the BBS/Local Screen 7+3) Read security 7+4) Write security 7+5) Origin line. 53 Characters maximum 7+6) Node number for this area 7+7) FLAGS 7n+1) Directory Name 7n+2) Name of area on the BBS/Local Screen 7n+3) Read security 7n+4) Write security 7n+5) Origin line. 53 Characters maximum 7n+6) Node number for this area 7n+7) FLAGS Let's now take a look at each of the seven lines: Line (1) Directory Name: ------------------------ The name of the directory where the *.MSG's are found. It need not have a trailing slash. If it is not specified with a trailing slash one will be added. If you are using a device or assignment name here, you WILL need to add the trailing colon. It is ESSENTIAL that this directory actually exists! If not, Plutonic will crash as you try to change to an area without a directory. The crash is clean - the program will simply exit, but you'll probably want to fix up the error, by either creating the directory in the first place or fixing up the typo that will be in this line. To check for missing directories quickly, use the [F]ind New Messages function from the main menu. You should be able to make it through ALL your message areas. Line (2) Local Area Name: ------------------------- Simply what you wish to refer to the area as. Maybe the true echo Tag-Names, or something else. This should be kept to less than about 30 characters to avoid messing up the display. The Name of the area can be preceeded by a single digit from 0-9 for the purpose of defining message area groups. See under the (NO)MATCH1 - (NO)MATCH9 keyword definition above for further information on area groups. Line (3) Read security: ----------------------- Level of user's read access. If a user does not have read access to the area, they won't even see it on their menus. Naturally, you can't give someone write access to an area they don't have read access to! NB: Make sure ALL CALLERS (even those with very low security) have read access to AT LEAST ONE message area. If not, I'm not sure what the program would do - but it wouldn't be nice. Line (4) Write security: ------------------------ The security required before a user can Write a message in or Reply to a a message from this base. Line (5) Origin line: --------------------- The text used in between * Origin: and (Z:NNN/nnn.p) in echomail messages produced by Plutonic. DON'T add the " * Origin:" text at the start or your node number at the end, Plutonic will add these itself for you. This line will be truncated to 53 characters MAXIMUM to prevent you creating an inordinately long origin line. Be aware of this when adding this line to the areas file. If this area is a MATRIX (Netmail) area, the origin line is not used at all - you still need a blank line (or some text) on this line to keep entries in multiples of seven lines, however. Line (6) Node Number for this area: ----------------------------------- The node number for the area. If Netmail will be added to the headers. If Echomail, will be added to the end of the Origin line, and in the intitial SEEN-BY: line (if the ADDSEEN option is selected). Note that this can well be DIFFERENT to the number you tell your tosser for this area. (Although except in the case of a fakenet, it probably shouldn't be). Points who have been setup with a FakeNet address by their bossnode should still use the real full 4 dimensional address here (and specify NODE in TrapToss for exporting the messages. Do NOT add an "@domain" at the end of your node number - Plutonic is only a four dimensional program (we don't "pretend" to support the fifth dimension without really doing so like so many other programs). Line (7) Flags: --------------- This section describes the flags Plutonic itself uses. PlutScan (Plutonic's area scanner) also uses this line for several keywords. You should consult PlutScan's documentation for details on those keywords. The keywords can co-exist on this line with no drama at all, PlutScan only looks for the keywords it knows, ignoring all others and likewise for Plutonic. Note that if you are using NO flags at all, you should use a blank line to take up the space in the areas file The flags come in two classifications: Netmail Flags: -------------- If the word 'MATRIX' or 'INTL' appears anywhere on this line, the area is regarded as a netmail directory, and require a destination address when messages are written in the area (which will be verified against the nodelist if you have one). File attach and attribute bit setting options will be accessible to user(s) with Sysop access in these areas. The user will be asked if the message should be private, and if sysop access is available you will be prompted for a lot more information. There are two 'flavours' of a Matrix keyword. MATRIX itself, and INTL. INTL works in precisely the same way as MATRIX, however it ensures that an INTL kludge line is placed on EVERY MESSAGE coming out of the area. With MATRIX this is only added if the message is going out of the current zone. One small tip: set your BadMail area up as a MATRIX area (not echomail). This will mean the From Address and To Address is displayed when you're reading the messages, allowing you to see exactly what system sent you the message and what address it was intended for. INTL and MATRIX over-ride any of the echomail flags you might also have on this line. Echomail Flags: --------------- There are three types of echomail flags, and they all default to OFF if the flag is omitted. You can specify as many different echomail flags on the seventh line as you like. Thus you could setup a private echo area which used aliases and allowed local-only messages if you like, or any other combination. PRIVATE Whether the private bit of the message is set. (This is ALWAYS asked in Netmail). Most echomail conferences demand you should NOT set the private bit, but for a few others (mainly net-local echoes) the private bit is allowed. LOCAL Whether or not to hit the SENT bit of a message. If you DO elect to do this, the message should not be exported by your tosser. Useful for keeping messages on this BBS only, yet still allowing incoming echomail messages from other systems (and possibly SOME outgoing messages). Note that the user is asked in reverse - "Echo to other systems?", if you answer yes, then the SENT bit is not set, and the message will be exported. ALIAS Whether or not the user will be prompted for an alias to use for the message. It would be a good idea to check that this is permissable in the echo before using this option. The moderator will be able to provide the answer. There are four variants of each of the flags: PRIVATEYES PRIVATENO PRIVATEASKYES PRIVATEASKNO LOCALYES LOCALNO LOCALASKYES LOCALASKNO ALIASYES ALIASNO ALIASASKYES ALIASASKNO ___YES Means that that option is always used. ___NO Means that option is not used at all (the default). __ASKYES Means the user is asked what he/she wants, defaulting to 'YES' with a press of the Carriage Return. __ASKNO Means the user is asked what he/she wants, defaulting to 'NO' with a press of the Carriage Return. Example: -------- A few example lines follow. When making the file, ensure the final character is a blank carriage return all on its ownsome, as the End of File Marker. (The PlutAreas editor will do this for you). If using a text editor you should look at how many lines are in the file, subtract one for this extra End Of File marker, divide by seven and you MUST get an integer. If having problems, just put the cursor on the directory line (EG MAIL:xxxx/) then cursor down counting in sevens. At every seventh line thereafter, you should be looking at a DIRECTORY name. Remember, if Plutonic loads up and does not deposit you at the top level menu of your DEFAULTAREA, the chances are your Plutonic.areas file is the one where you will have a problem. The frequency at which the final blank line with 1 linefeed character is missing is uncanny, incidentally. I have fixed many new users' problems by merely adding one character to their Plutonic.areas, right at the end :-) Anyway, if in doubt, run the PlutAreas editor, it will help you get the file in ship-shape condition. --cut-- MAIL:Matrix/ FidoNet NETmail 1 2 Doesn't matter, won't be used. 3:622/401.0 INTL MAIL:InqLoc Private Local Mail 1 1 Inquestor. GFA-BASIC is better than C. 9:200/104.5 PRIVASKNO LOCALASKYES ALIASASKNO MAIL:Inquestor/ Inquestor (Local) 1 1 Inquestor. Whaddya mean can you change it so... 3:622/491 PRIVYES LOCALASKNO ALIASYES --cut-- The PlutAreas Editor: --------------------- PlutAreas is a small (some would say quick and dirty) specialist editor for a MAIL:Plutonic.areas file. I still prefer to use a text editor to edit my Plutonic.areas file, but some people definitely have problems with this, particularly in regard to keeping the entries in multiples of seven lines, and getting the end of file character in the correct spot. PlutAreas will solve these problems and allow you to get a WORKING Plutonic.areas file up and running very quickly. Please start with a Plutonic.areas file that has at least TWO areas defined, however. (Such an example will be found in the archive). PlutAreas will ONLY look for a file called "MAIL:Plutonic.areas" at the moment, so if you want to edit other files, you will need to rename your original "MAIL:Plutonic.areas" to some temporary name, and rename the file you want to edit to "MAIL:Plutonic.areas". I'll probably add a file requester into PlutAreas at a later stage, but it's not high on the priorities list at the moment. Simply run PlutAreas (from Shell or Workbench) and you will be met by a screen of several gadgets. The four gadgets at the top left are fairly well self-explanatory, QUIT, SAVE, ADD and DELETE. ADD adds a new area one after the area that is displayed on the screen, and DELETE removes the area you're looking at (after asking for confirmation). If you should accidentally delete an area you really want, don't forget you can quit without saving and be left with the Plutonic.areas as it was on disk. In addition, if you DO save the file with changes you don't want, the old Plutonic.areas file is not deleted outright, but actually renamed to Plutonic.areas-bak when the program saves the new one. So if you've only saved the file once, you can easily restore your old areas file from this backup. There is a row of black-on-yellow gadgets across the top row. These are for navigating through the areas, and look a little like so: |<< <<< << < 1 > >> >>> >>| ^ ^ ^ ^ ^ ^ ^ ^ ^ | | | | | | | | | Jump Jump Jump Jump Stay Jump Jump Jump Jump to back back back put forward forward forward to first heaps a few one one a few heaps last area of areas area area areas of area areas areas The number of areas each gadget will actually jump is proportional to the total number of areas you have in your areas file. If you only have a small number of areas in the file, then <<< may well do the same as <<. There are then seven lines you can edit for each area. To activate a line, CLICK ON THE LINE. The colour of the text will change, and you can then edit the string. You can use the right/left arrows, Shift-right and Left arrows to move the cursor. The backspace and delete work as usual. To erase the ENTIRE line, press the Escape key. When you have finished a line, you must press return to exit from it. You can then change any other lines at will. When you add an area, it will be added immediately following the area you are currently located. EG if you are looking at the details for area number 20, the area you add will be area 21, the old 21 (and all subsequent areas) will be shifted down one. Certain defaults will be used in the new area you create, 99.9% of the time you will HAVE TO edit these, of course! To delete an area, then the one you're looking at is the one that gets deleted, and all areas beyond it move up one. Don't forget to SAVE your areas file if you have made any changes :-) PlutAreas does not keep track of whether you have made any changes or not. PlutAreas will also "condition" your areas file - by this I mean that leading and trailing spaces are stripped, slashes automatically appended to directory lines, your origin text is truncated to 53 characters (if necessary) and probably a few other things. PlutAreas can load any number of message areas. By default it allows array space for 500 areas, but if you have more than that many areas then you can run PlutAreas with an argument. For instance if you have 700 areas setup in the file, run PlutAreas with the command line: Run PlutAreas 700 And then you'll have room for that many. I have loaded areas files with over 800 areas into this version of PlutAreas. (Earlier versions would throw up Out of Memory errors at about the 250 area mark - this problem has been fixed - although at the expense of having to allocate a lot more memory than older versions). ********************************************************************** Section 4 - Using the Program ********************************************************************** General: -------- If using Plutonic reminds you of being logged into a BBS and using the message areas, don't be surprised. Because that's exactly what it is! If you are setting the program up to run from the OzMetro BBS, Plutonic needs no special treatment. Set it up exactly how you would set up any other OzMetro door. This is outlined in the "Adding Doors" chapter in OzMetro.doc, which you should definitely read now, if you haven't done so already. You will need to create a DOORxxx directory in a DoorfilesX directory and rename the Plutonic executable to Door.exe after copying it into the DoorfilesX/DOORxxx/ directory. I have an alias to run my Plutonic which is: alias Pluto run BBS:Doorfiles1/Door225/Door.exe This means I only have to keep one copy of Plutonic around, and the one that I use is always the same as the one the BBS uses. This makes it a lot easier to upgrade to more recent versions - only one exe needs to be replaced. Plutonic from the local console is basically the same code as a remote serial user would see, but with a few extra commonsense mouse commands and external program options. It's almost completely text based. While there are requesters and alerts at times, most of your interaction with the program will be via the keyboard. And since most of the messages you write will also be written with the keyboard, I feel this is a big PLUS for the program, not a detraction. You need to be aware that Plutonic has a 10 minute idle timer which clicks down from the time of your last keypress. If you are going to leave Plutonic running for longer than five or so minutes you will need to put Plutonic to sleep by pressing both mousebuttons at the same time when the program is waiting for input. This will pop up a GFA alert gadget, allowing you to either quit Plutonic, or re-start it when you get back. While the alert is up, no CPU usage occurs, and the idle timer is reset. You can leave Plutonic sitting there, go and do other work (maybe unarc a file, load a text, answer a call of nature, etc) and come back to Plutonic exactly where you left off. When you setup a new message area and you access it from Plutonic for the first time, it will have to create the Last Message Read pointers file, and the message index (Whats.here). This sometimes causes a few minor display errors as text from these routines is displayed as the files are being generated. Don't worry about this, it only has to do it once for each new area, and the display will be fine next time you visit the area. Also, it's a good idea to run PlutScan over your areas when you are first setting the program up BEFORE running Plutonic itself. PlutScan is the program to update Plutonic's message index pointers, so it will need to be run before Plutonic will know new messages have been added to an area. Plutonic is not like Transamiga in that PlutScan doesn't have to be run to prevent PlutScan over-writing new messages - Plutonic DOESN'T over-write existing messages. You don't have to run PlutScan EVERY time you import mail, only when you want to read the new messages. I run PlutScan here only twice a day (it's a big job - lots of areas and lots of messages), and find that sufficient. Oh, and you can always use the Delete Whats.here function (see below) to get Plutonic to rescan just ONE (or a few) areas rather than running PlutScan over ALL your areas! The program is virtually self-documenting. It's exactly like being logged into a BBS, so you should follow all the prompts and experiment! For this reason forgive me if the following sections skimp a little on the details. Most actions are self-explanatory. Main Menu Options: ------------------ From the Main Menu some or all of these functions will be available depending on whether you have enough security or the system is configured to do the function. [C]hange message area --------------------- This prints up a list of all accessible message areas (two columns) showing the Local Name of the area, and message area number. It then asks you to select an area. While the areas list is being printed you can abort it with the spacebar (or S key or N key or Ctrl-C) if you don't need to get all the areas printed. If the areas list is too long to fit on the screen, page pausing prompts are sent, to which you have three options: (Y/N/C). YES gives you another screenful; NO stops the listing, and CONTINUOUS will print the rest of the areas list up without further page-pausing. If you select an area outside the range of available numbers, you'll be returned to the area you were already in. [F]ind new messages ------------------- This is short for "Find Areas With New Messages". It scans the index files and Last Message Read pointers of each area and displays message areas with messages in them above your Last Message Read pointer. It also shows how many new messages there are in each area. It will not display any areas where there are no new messages. This can also be aborted with the space bar (or other abort keys as above) and has page pausing. As a nice feature this list starts at the area you are currently in, and cycles around to the area you're in minus one (usually going up to the highest message area and back through area one to the area one before where you are. Clear? Try it - you'll see). [R]ead messages --------------- Selects to read messages from the current base. The program defaults to start reading messages at the very next one past your Last Message Read pointer, but you can type in any other number to start from should you choose. You then have an option of five types of message reads: Normal ====== Displays each message in full (with page pausing). Between messages, any or all of these commands are available depending on security, the message number, or if there are replies or not: N]ext A)gain P)rev J)ump -)Chain Back +)Chain Ahead R)eply $) Pressing Return selects the N]ext message, and the other message movement functions should be pretty well self-explanatory. NB: If you select to reply to an echomail message into a Netmail message area, the sender's return address can only be found automatically if the original echomail message actually has a MSGID line. In these cases if Plutonic says 'Predicted Return Address' and gives you the node number of your FEED for the echo, it's probably because the original message has no MSGID in it (Or then again the message DID come from your feed's system). You'll then have to figure out the REAL address you want to send the message to. If you can't remember it, run Plutonic again (ie have two copies of it running) and check out the origin line of the message you're now replying to. Hopefully the address you want will be there. The $) function breaks you into the sysop functions (and thus is only available at Sysop security level). Currently the sysop options always available are: X]it K)ill C)lone K)ill deletes the message being displayed after asking for confirmation (twice) and C)lone copies the message to the highest number in the base (after which it's often useful to K)ill the current message). Clone is useful for a lot of purposes, but mainly since it puts the current message above the present hiwater mark this can be useful if you haven't got time to reply to the message and don't want it buried among the rest of the messages in the base. It's also useful for failed areafix messages to give the user a second chance after you correct the message in some way. WARNING: Ensure you are aware of the status of the SENT bit if you clone a message. If you don't want the message to be re-exported ensure the SENT bit is set on on the copy produced. (Alternatively, ensure the netmail message is addressed to YOU or one of your AKAs - the latter only works in netmail, though). There are then three additional functions only available from the local console: P)rintMsg H)eaderEdit F)ooterEdit Print Message asks for a filename to send an ASCII interpretation of the message to. To send it to the printer, specify PRT: A dialogue box will pop up asking for the input. Press Escape if you want to clear the contents, otherwise use normal string editing keys. You can crash Plutonic by telling it to use a device or filename it can't access, incidentally, it's an interesting clean exit :-) The Header Editor is one of Plutonic's most powerful sections. It is a full graphical user interface binary message header editor for the first 190 bytes of the file. All of the fields of the *.MSG are available for editing The top half of the window contains text gadgets for the various message fields. Simply click in them to activate them. You must PRESS RETURN TO LEAVE A FIELD, even if it's unchanged. Special parsing is in place in the program to correctly capitalise From and To names, and to ensure a valid address is entered. To change any of the message's attributes, you can simply toggle them on and off in the lower half. ALL attributes are available, but be aware that if you are editing an ECHOMAIL message, then most of them will NOT make much sense! Only the LOCAL, SENT and RECEIVED attributes are generally used in echomail. Netmail of course is different. Be careful not to set contrary bits (eg CRASH and HOLD bits should never BOTH be set)! If you select to toggle the File Attach bit, Headit will pull up a file requester allowing you to select a file to attach. If you ever want to change this, just de-select and re-select the File Attach attribute again. This is really useful when you write a message and forget to actually attach a file when you save it. But it can also be used to change the file you attached, or also stop sending the file. You can use this gadget as many times as you need - each time you change it from OFF to ON, it will ask you if you want to pull up a file requester to select a file. Note that any KLUDGE LINES already in the message will be unchanged. These might conflict with the header if you change the Zone or Point parts of the header. Headit, remember, is only for the HEADER. Use another editor for the body of the message! And naturally the F)ooter edit function allows exactly this - it will load up the rest of the message (that after the first 190 bytes) into your selected editor, allowing you to edit that part. Beware - you're now editing a *.MSG footer, and NOT a normal textfile. Don't use LineFeed characters (what you get when you hit the big squareish "return" key on the right of the amiga keyboard) at the end of line - the Carriage Return is used instead (to get a carriage return, hitting Ctrl-M should work, depending on how powerful your editor is). Your editor needs to be up to the task of editing message bodies (not all editors are). Cygnus Ed will never let you down here! Headers only ============ This is almost identical to the normal read mode, except the actual text of the messages is not displayed, only the header details. This is of limited value compared to the One Line Summary (see later), but I've left it in the program, it may be of some use one day. Mine only ========= Same as a Normal Read except only messages to or from your username will be displayed. All others are skipped. If lots of messages are being skipped, Plutonic will print .....'s to the screen - one dot every ten skipped messages. If you get sick of waiting, pressing the SpaceBar (or other Abort keys) will quit this function if it's between messages. Selective search ================ Selective search is similar to mine only, except the user can specify the actual search parameters. This is actually self-documenting, so choose the function and read the instructions. You can search through the FromName, ToName, Subject and Date fields for any text or partial text matches. One line summary ================ This has grown to be quite a powerful function, displaying the message FromName, ToName, Subject, Date and Attributes on the screen one line per message. At each screenful the program will ask if you want to read any of the messages displayed, and you can type in the message number and have it shown to you. If you have read a message this way it will also ask you if you want to reply (if you have enough security). [W]rite a message ----------------- This allows you to post a message outright into the current base (if you have enough security). If you're at the local console you have the option of using either your own editor or the inbuilt editor. If you are using your own external editor to write messages (and replies), then among the questions Pluto asks as you're saving the message into the bases will be "Reflow this message?" (You have control over the default answer, see under the (NO)DEFREFLOW keyword). The Reflow routine is really nifty, however it's a two edged sword and if you've included log extracts, tables or other formatted text in your message then you won't want that part of the text re-flowed. You can either answer NO to this question and Plutonic will use your text verbatim or, better still, to get Plutonic to not reflow some sections of your message you have two options: 1) Indent the line(s) by one or more spaces. 2) Use a Carriage Return (Ascii 13 or Ctrl-M) rather than a LineFeed (Ascii 10) at the End of Line. All carriage returns are entered into the message verbatim. Naturally, for the reflow to be effective you need to separate paragraphs with a blank line (like this document) or indent the next paragraph by one or more spaces. (You'd be doing this anyway). [O]ne line summary ------------------ Works exactly as described above in the between messages section, except from the Main Menu it will start the read at the lowest message in the base instead of one plus your Last Message Read. [N]odelist lookup ----------------- Another self-documenting funtion (Press ? for help) which will display details on node numbers you type in - provided you have a nodelist set up of course! [E]cho rules ------------ If you have a textfile in the *.Msg directory called "EchoRules" the user will be presented with this option. It's up to you to collect these texts, so as you're reading an area and notice a message with the Echo Rules posted, you can save it off, edit it up a bit, and put it in that message directory. The text needs to be a normal ASCII file (remove the CRs if it's from an IBM), and !MUST! end with a blank line on its own (as usual for most files sent by GFABasic). You can, of course, use this for other than Echo Rules - any old ASCII text is fine. [A]lter setup ------------- Allows you to change the screen height, toggle ANSI on or off and if you have enough security (See the SHOWKLUDGE keyword) to toggle on or off the display of the DietIfna kludge lines. [S]et last message read ----------------------- The program makes reasonable assumptions about setting your last message read pointers, but you may not agree with it. This option allows you to over-ride what Plutonic sets. As a special bonus, as you enter an area, Plutonic will remember what your Last Message Read was - and use it as the default answer for this question. It only remembers it while you're in this message area, however. This is useful for quickly scanning through the messages, (which will bump your LMR on the way) and then setting your LMR pointer back to the original value so you can come back later when you have more time. [Q]uit ------ Yep - quits the program! [D]elete Whats.here ------------------- This is a Sysop-only function available only from local logins and causes the Whats.here file in the current area to be deleted. This then triggers Plutonic off into a message area scan - and thus any new messages arriving in the area will be accessible. Plutonic will never over-write messages - it checks to see if the message number it is going to create exists, and if so, will bump the intended number looking for a vacant number until it reaches the 32,767 mark. (If it hasn't found a vacant message number by then it will overwrite 32767.MSG). So if new messages have arrived that haven't been scanned by Plutonic, and you post a message in that area, it will effectively be re-scanned, and you'll see more messages available in the area. Consider it a sort of reward for posting the message :-) [L]oad Plutonic.cfg ------------------- Allows you to reload the configs without having to quit and re-start the program. The screen will be closed and re-opened in case you are experimenting with the SCREEN0 - SCREEN7 keywords or any of the other display keywords. This is a Sysop-only function. This also brings up a question: "Rematch selection Parameters?" If you answer yes to this, then you can re-choose the MATCH parameters from the areas file this way. This, incidentally is another workaround for the 20 areas limit - you can select to match a different message area group, yet still have the same large Plutonic.areas file. See the (NO)MATCHx keywords for more details. [>] Next Message Area & [<] Prev Message Area --------------------------------------------- Simply jumps you forward or backwards one area. You don't have to hold the shift key to get the < or > signs (although you can), the "," and "." are synonyms for them. If you're at the first message area, pressing "<" will jump you to your LAST message area, BTW. ********************************************************************** Section 5 - Bugs or features? ********************************************************************** Plutonic suffers from a number of problems in design and implementation, but hey? What program is perfect? I AM aware of them all, but I still run it all the same. I think you might take this opinion as well, but I WILL be up-front with you in these docs. First and foremost, it uses busy-polling loops for the input routines, and on a multitasking computer, this will slow down all other programs running at the same time as it. The problem is since the program should really Wait() on Signal bits, the signal bits are too difficult to get into BASIC in the first place. And it's a complex setup, too, you'd need to wait on three devices, the input.device for the local keyboard, the serial.device for the remote user and the timer.device to provide the idle timeout function (which no BBS should be without). But because the language is a high level one, these devices are not opened at a level low enough to be able to locate the signal bits. The compiler itself looks after many things and doesn't let you get to all the nice structure information you'd have if you were programming in C or Assembler. To switch the input routines off (you can do this almost any time the program is using the input routines - quite often, even when it's SENDING text it's still having a look for a Ctrl-S to pause or Spacebar to abort, etc) press down both mouse buttons at the same time. This will throw up a GFABasic "alert" gadget (like a requester) which actually INTERNALLY Waits() for a key to be pressed or a mouse selection, and thus any other program you are running will speed up NOTICEABLY :-) This method also allows you to quit from the program (its original intention, in fact), but its putting the program to sleep was a VERY nice bonus. This can even be done with a user online, and their output and input is still all buffered - but they might get a little bit worried about the fact that the BBS will have stopped responding to all their keypresses (until you un-sleep it whereupon it will start processing all those keys they pressed frantically thinking the system has crashed). Still, you can get away with it quite a bit, particularly when they are staring at a menu or waiting for a (More Y/n/c)? prompt, and you can give any other programs you're running a lot more CPU time for a few moments. GFABasic is also VERY VERY picky about end of file markers in texts. Basically it needs a blank line at the VERY end (and not a Ctrl-Z like IBM texts often have). If you're using Cygnus ed, the end of file marker looks like a small rectangle. This has to be on the very last line of a textfile, NOT at the end of the last line. To illustrate, if the eof marker looks like this [], then this end of a textfile will be okay: Line of text, etc, etc [] But this sort of line would cause an error: Line of text, etc, etc[] (Please don't take this literally, the end of file marker is NOT "[]", it's a linefeed character (ascii 10) - but it's hard to see a linefeed character in docs so I've used "[]" to illustrate it). ********************************************************************** Section 6 - Distribution & Politics ********************************************************************** The Plutonic archive is not and has never been in the Public Domain. The copyright always remains the property of Peter Deane. You may not modify, copy, distribute, attempt to reverse-engineer or disassemble the program except as provided for in the licence agreement below. The Plutonic archive can be distributed by any means provided the person or organisation making such distribution makes no charge over and above a small copying fee. By "small copying fee" I mean a value usually charged for a freely distributable disk, and in NO CASE WHATSOEVER above a fee of $AUD8.00 plus postage. Any person or organisation asked by Peter Deane to cease distributing the archive shall comply forthwith. Partial distribution of the Plutonic software is NOT ALLOWED, if you distribute the program, you must distribute it lock, stock and barrel, with no files removed or added from the original distribution archive as created by Peter Deane - re-archiving is NOT allowed. You may not use or distribute this software for an illegal purpose. Without limiting the generality of the foregoing this means that any person using the software to run a pirate BBS where COMMERCIAL software is available for download is infringing the copyrights of this product (Not to mention the copyrights of the commercial software they have for download)! The maximum liability of Peter Deane for any damages the use of or inability to use this software may cause is limited to the amount (if any) paid directly to Peter Deane for the software, exclusive of postage and handling charges. ********************************************************************** Section 7 - Registration ********************************************************************** The released archive of Plutonic is only for EVALUATION purposes, and you are not permitted to run the program for a period exceeding five weeks (Not continuously! Five weeks from the day you first start to run the program) without registering. If you register you will be sent a small 512 byte keyfile, which will unlock the limits set in the evaluation version. This will allow you to download the latest version from a BBS and not rely on a special custom registered version with inherent delays, etc. The cost of a Plutonic keyfile is $AUD25 (IE twenty-five Australian Dollars). Please note the Plutonic Keyfiles are NOT TRANSFERRABLE UNDER ANY CIRCUMSTANCES. The only person you can currently register Plutonic with is myself - you are not allowed to purchase any other person's keyfile, and likewise you are not allowed to sell your keyfile. If you stop using Plutonic - I'm sorry - the $25 you paid covers your use of the program to that date (and any future use if you decide to start using the program again). If you wish to register from outside Australia or New Zealand, please send $US25 (the extra exchange rate will cover the extra postage). Please don't send foreign PERSONAL cheques drawn on foreign accounts, my bank charges about $30 to clear them! If in doubt, send $US bank bills - this has been successfully used in the past by many people. Alternatively a Bank Draft or International Money Order won't involve me in extra expense to clear the funds. I will include a registration order form (Plutonic.rego) in this archive you should fill out and forward to me - see the registration form for specific instructions on how to go about registration. If you have ANY questions, need ANY help or need to contact me for ANY reason you may do so at any of these addresses: Peter Deane FidoNet: 3:622/401 Postal: PO Box 228 GlobalNet: 54:6101/401 Swansea NSW 2281 AmigaNet: 41:200/401 AUSTRALIA Or call the BBS: from O/S +61-49-72-1647 (24 hrs) from Aust (049) 72-1647 I have setup a FidoNet echo for discussion of this software and the OzMetro BBS System, and will frequent this echo, answering any questions the users may have on any program I've written (and probably a lot of programs I haven't written). The tagname of this echo is PLUTONIC and distribution isn't very wide at the moment, however, keep watching in Amiga comms message areas for announcements of its existence. If you need access to the echo, you can always pick it up from Inquestor, but we will make moves to distribute it via normal echomail links as well. ********************************************************************** Section 8 - Standard Disclaimer ********************************************************************** This product is meant for educational purposes only. Any resemblance to real persons, living or dead is purely coincidental. Void where prohibited. Some assembly required. Batteries not included. Contents may settle during shipping and handling. Use only as directed. No other warranty expressed or implied. Do not use while operating a motor vehicle or heavy equipment. Apply only to affected area. If condition persists, consult your doctor. No user-serviceable parts inside. Freshest if eaten before Use-By date. Subject to change without notice. Simulated picture. No postage necessary if mailed in Antarctica. Breaking seal constitutes acceptance of agreement. As seen on TV. One size fits all. Colours may fade. Slippery when wet. For office use only. Adults Only Modified TV Version. Not responsible for direct, indirect, incidental or consequential damages resulting from any defect, error or failure to perform. At participating locations only. Do not write below this line. Falling rocks. Add toner. Place stamp here. Avoid contact with skin. Sanitised for your protection. Employees and their immediate families are not eligible. Beware of dog. Limited time offer, call now to ensure prompt delivery. You must be present to win. No purchase necessary in South Australia. Use only in well-ventilated area. Keep away from fire or flame. Replace with same type. Some equipment shown is optional. Not recommended for children. No anchovies unless otherwise specified. Not for individual resale. Call 1100 toll free before digging. Driver does not carry cash. If use of this product causes rash, discontinue use. Do not apply to broken or damaged skin. All measurements are approximate only. Any accesories used to display items are not included in the price. No Rain-checks. Failure by a supplier to deliver goods in accordance with sample or description will result in our inability to supply said product. Keep out of reach of children. Supply without prescription illegal. Keep refrigerated. Not to be used for any purpose or in any manner contrary to this label unless authorised under appropriate legislation. Do not apply to pigs or goats later than 14 days before slaughtering. Store in a cool dry place out of direct sunlight. No artificial colourings or flavourings. 99% fat-free. Read safety directions before opening. For additional hazard information refer to the Material Safety Data Sheet. If product in eyes, wash out immediately with copious amounts of water. Wash hands after use. Do not spray directly on humans. Intentional misuse by deliberately concentrating and inhaling contents can be harmful or fatal. Do not puncture or incinerate can, even when empty. Do not dispose of in fire. May leak if recharged by user or device. Use with confidence: this product does not contain fluorocarbons, claimed to harm the ozone layer. Unsuitable for infants except under medical advice. Prices may vary in country areas due to freight. Due to the printing process, some colours may vary from those shown.