Amiga Times

home *** CD-ROM | disk | FTP | other *** search

/ Amiga Times / AmigaTimes.iso / programme / trionbbs110 / Trion / docs / 03_Configuration.doc < prev next >

Wrap

Text File | 1998-10-06 | 59.5 KB | 1,706 lines

Introduction ------------ The Trion BBS system is mostly configured with text files. This chapter descripes the format of these files. Also all the configuration files are explained short, and the general configuration files are explained fully. Configuration files for files, mail and groups are explained in the next 3 chapters. Configuration files ------------------- Trion configuration files consist of plain readable text files. Each line can only take one entry. Most entries exist of a keyword followed with zero or more arguments. In most entry types the numbers of arguments are fixed .. with some the number or arguments can be variable. Note that in some files no keywords are used, but lines start with arguments. Examples: LOCAL When this line is used in a Trion-X.cfg file the node can't use the serial port. This is an example of a keyword that doesn't take any arguments. ICON 200 0 FONT cleanIBM.font 8 These are lines used in the Trion-X.cfg to define icon position and font to be used in a Node. Note that these keywords must be followed with 2 arguments. MAILER HYDRA ZEDZAP DIRECTZAP ZEDZIP ZMODEM This line defines in the Trion-X.cfg all the protocols that can be used by the Trion mailer. The keyword "mailer" is fixed but the number of protocols is variabel. Note that keywords and arguments are separated by one or more spaces. Also an entry doesn't have to start the beginning of the line it maybe preceded with zero or more spaces. Empty lines are allowed. In most files the order of lines is not important, and lines maybe switched. Comments may be placed in configuration files by using ';' characters. Note that all characters on a line after a ';' character are ignored. So you can comment on lines with keywords, but only in configuration files that are not changed by programs like files that contain passwords or lists of nodenumbers that are connected to some net because they maybe filtered out when a line is changed. If there is text on the last line of the file, end that line with a return. Or better .. end the file with an empty line. Sometimes you may need to use spaces in arguments. In that case simply place "" characters around the argument so the program sees it as one argument instead of more and give some sort of error message. In a few cases you can substitute spaces with underscores, this is a legacy of the time that you couldn't use "" characters. These are examples of the use of arguments with spaces: SYSOP NAME Sysop SYSOP NAME "Paul Spijkerman" SYSOP NAME Paul_Spijkerman These are the fields in the Trion-X.cfg files where underscores maybe used. Not recommended because it maybe removed some day. SYSOP NAME "Sysop" SYSTEM NAME "System" SYSTEM CITY "City" SYSTEM PHONE "+31-599-123456" Note that keywords are in uppercase characters, but most keywords will also be accepted in lowercase. But if you use uppercase you can clearly see what the keyword and what the arguments are. If there is an error in a line in a configuration file an error message will be printed in the CLI window. The configuration directory --------------------------- To configure the system there are a number of text files in the 'trion:cfg/' directory: This is a short description of the configuration files in the distribution archive. General configuration files --------------------------- badnames.txt <- Config. to prevent users with bad names. bbstext-0.cfg <- To config texts in the BBS nodes. bbstext-1.cfg language.cfg <- List with languages or text sets (see bbstext). protocol.cfg <- config for Xpr.. transfer libraries templates.cfg <- Definitions of the user levels term.names <- names en tel.numbers for the terminal mode. trion-0.cfg <- Specific info voor node 0 en 1. trion-1.cfg trion-6.cfg <- Node 6 en 7 are configured for the trion-7.cfg Nullmodem.device (handy with testing) trionRM.cfg <- Config for the Resource Manager and GUI's unpack.cfg <- Config for the Unpack and Tick program. These files are explained in this chapter. Files configuration files ------------------------- fileareas.cfg <- Config with the FileAreas. filenet.cfg <- Config for the 'Tick' Util. filenodes.cfg <- Nodes and passwords for 'Tick' Util frequest.cfg <- Config for requested files These files are explained in chapter 4. Mail configuration files ------------------------ AKA.config <- All your 'NodeNumbers' for mail transfers. Archive.cfg <- How the mail processor uses archivers. nodelist.cfg <- List with the nodelists to use. origin.list <- for 'origin lines' in echomail. mail.cfg <- Export list with Message Areas. mail.names <- To find a nodenumber with a username. mailareas.cfg <- Config with the MessageAreas. route.cfg <- Netmail route config. systems.cfg <- Passwords for mail exchange. taglines.data <- List of taglines for messages. These files are explained in chapter 5. Groups configuration files -------------------------- Groups.cfg <- Definition of mail and file section groups. These files are explained in chapter 6. External configuration files ---------------------------- AllFiles.cfg <- Configuration file for allfiles util. AreaFix.cfg <- Configuration to the Trion AreaFix crontab <- Config for a (Unix-alike) 'Cron' Util. miscGui.cfg <- Config of this GUI control program. questionair.cfg <- config for the questionair doors scheduler.cfg <- Config of the Trion scheduler program. ttrimlogs.cfg <- Config for the Util to trim the logs A description of the Allfiles configuration file can be found in trion:docs/utils/allfiles.doc A description of the Areafix configuration file can be found in trion:docs/utils/areafix.doc Note that a Cron program is optional and not really needed because of the provided scheduler so no Cron program or description is provided. A description of the MiscGui configuration file can be found in trion:docs/utils/MiscGui.doc A description of the questionair configuration file can be found in trion:doors/quest/quest.doc A description of the Scheduler configuration file can be found in trion:docs/utils/Sceduler.doc A description of the Trimlogs configuration file can be found in trion:docs/utils/TTrimlogs.doc General configuration files --------------------------- Here is a longer explanation of the workings of the general configuration files. They can be edited with every text editor. Most of the configuration files can be loaded in an editor with a button in the TrionRM GUI. The TrionRM configuration file ------------------------------ The TrionRM.cfg is needed to configure all the path's used by the BBS, the definitions of the optional public screen and some definitions needed to configure the TrionRM GUI. These are all the possible entries: SYSOP NAME "Paul Spijkerman" PATH DEFAULT trion: PATH CONFIG trion:cfg/ PATH UTILS trion:utils/ PATH SCRIPTS trion:scripts/ PATH USERS trion:users/ PATH LOGS trion:log/ PATH DATA trion:data/ PATH ICONS trion:icons/ PATH SAMPLES trion:samples/ PATH DOORS trion:doors/ PATH TEMPDIR ram: PATH MENUS trion:menus/ PATH MENUTEXT trion:menutext PATH TEXT trion:text/ PATH FILECAT trion:filecat/ PATH UPLOAD trion:Upload/ PATH KILLED trion:KilledFiles/ PATH MAIL trion:mail/ PATH INBOUND trion:InBound/ PATH OUTBOUND trion:OutBound/ PATH NODELISTS trion:NodeLists/ ICON 80 0 NODES 2 LASTCALLERS 12 USEWB USESCREEN SCREEN WIDTH 640 SCREEN HEIGHT 256 SCREEN DEPTH 3 MONITOR DONTCARE INTERLACE SUPER DEFAULT FONT topaz.font 8 TEXT FONT topaz.font 8 SMALL FONT topaz.font 8 COLOR 0 10 10 10 More lengthy explanation of the TrionRM.cfg entries: ---------------------------------------------------- sysop name ---------- SYSOP NAME Paul_Spijkerman SYSOP NAME "Paul Spijkerman" TrionRM needs the name of the sysop to be able to display the number of waiting messages for the sysop in the TrionRM GUI which is indicated with "Wait:". This counter is always uptodate, it is increased when mail in unpacked. Note that this is one of the few entries where underscores can be used instead of spaces. But this isn't ecouraged. Path definitions ---------------- In earlier version most of the paths were hardcoded. But it was more practical to be able to change a path, also the assign name was changed from "tron:" to "trion:" and all the hardcoded paths had to be changed. Note that a few small programs still use hardcoded paths, but many of them take an alternative path on the command line. All the paths should end in a ':' or a '/' character so the BBS can simply complete the path by putting the file name after it. With an EXEPTION of the MENUTEXT entry. This entry should end in text because the BBS will put a number and a '/' character at the end of the name, so it can have different menutext directories for each language. PATH DEFAULT trion: The default path is were the BBS looks for the BBS key and the startup and down scripts. Note that the BBS will also look in the "L:" directory for the BBS key. PATH CONFIG trion:cfg/ This is were all the editable configuration file are stored. PATH UTILS trion:utils/ This is were all the executables are stored. With an exeption of door programs. PATH SCRIPTS trion:scripts/ This is were the scripts are stored. Note that there are scripts that are executed by the BBS at certain moments like when a mailer has called or a user logs off. PATH USERS trion:users/ This is were all user data is stored. The userdata consists of a list with all usernames and their alias (or nickname) and a unique usernumber. All other files in this directory have names based on the usernumber. There are a number of different files each user can have. The userdata itself, a waitingmail file which contains the information of all messages directed to a certain user. Files with marked files and marked messages, so when a user was logged off because his time was up, he doensn't have to remark files that he wanted to download again. A questionair which contains answers typed by the user in a questionair door. A signature that is put under messages that a user writes. PATH LOGS trion:log/ This is were all log files are stored. PATH DATA trion:data/ This is were binairy data files of the BBS is stored. These are files which are not readable or editable. There are files that contain a database of MessageID's this is needed to be able to reqognize duplicate messages when importing mail. Here go the compiled versions of BBStext configuration files. A file with the number of calls to your BBS is stored here. A file with data on users and mailers that have lately called it stored here. Files with statiscal data on users is stored here. And some other binairy data like the problems in the maintenance module. PATH ICONS trion:icons/ This is were RIPScrip icons are stored, these icons are pictures which can be loaded an saved in RIPscrip menus. Usually they are hires 16 color pictures that can be displayed in a menu, or pieces of the screen that where clipped out and saved to disk to be shown very quick later. PATH SAMPLES trion:samples/ This entry is not in use at this moment because in trion-x.cfg and menus samples are defined with their full path. However this directory does contain the samples used in the BBS. There is a "page sysop" and a "bell" sample, the other samples are used in menus to indicate the sysop audible that a user starts a certain action. PATH DOORS trion:doors/ This is where the BBS program will look for doors, to do questionairs. Note that there is also a "Doors:" assign as a shortcut to the place where doors are stored. A lot of paragon doors need the "doors:" assign to find their data. PATH TEMPDIR ram: Path where files are temporarily stored while the BBS program is active. So the fastest solution would be "RAM:". PATH MENUS trion:menus/ This is where the menu sources are stored, note that there is a subdirectory "bin" in this path where compiled menus are stored. PATH MENUTEXT trion:menutext This is where the screens in menus for each language are stored. DON'T END THIS PATH WITH A '/' !! The BBS will end this path with a number and a '/' character. It will create something like this "trion:menutext/" for language zero, this for language one "trion:menutext1/", and so on. PATH TEXT trion:text/ ; screens for login, logout, etc This is where screens are stored that are not part of a menu, such as login screens, logout screens and screens that are shown from within menus. Like bulletins. PATH FILECAT trion:filecat/ This is where all binairy files that makeup the file catalogue are stored. PATH UPLOAD trion:Upload/ This is where files are uploaded to, and are processed before they are added to the file catalogue and moved to an other directory. PATH KILLED trion:KilledFiles/ This is where deleted files go, this can be files from the file catalogue that are removed or files that are replaced by the tick processor. PATH MAIL trion:mail/ This directory was meant for the data files for message sections, but since they have there own path definition in the mailareas.cfg file it is only used to transfer messages to and from the message editors. PATH INBOUND trion:InBound/ This is where Incoming files are stored by the Trion mailer. PATH OUTBOUND trion:OutBound/ This is where Outgoing mail and files are stored until a remote mailer calls in to pick it up. PATH NODELISTS trion:NodeLists/ This is where the TrionRM program looks for nodelists. TrionRM monitor definitions --------------------------- ICON 80 0 This is the X and Y position on the Workbench screen of the TrionRM icon in the iconized mode. The icon is a little window which you can click to DeIconize the TrionRM monitor. NODES 2 This indicates the number of BBS nodes that are visible in the TrionRM monitor. Note that when you indicate N nodes, that node 1 .. N are shown in the monitor. You can still run node N+1 but it isn't shown in the monitor. LASTCALLERS 12 This indicates the default number of lastcallers on the TrionRM monitor window. However you can get more or less lastcallers by resizing the window. Also it is possible that you get one caller less then indicated because of roundings in calculations when rendering the screen. Also you can browse to hundred lastcaller by using the scrolle gadget. USEWB USESCREEN Use one of these keywords to indicate of the TrionRM window is gonna be displayed on the Workbench screen or on a TrionRM public screen. Note that all other Trion GUI tools also open their window on the TrionRM public screen when it is available. Note that more colors can be used on the TrionRM public screen. Also note that the public screen is closed when you iconize the TrionRM monitor. SCREEN WIDTH 708 ; 640, 800, 1280 708 SCREEN HEIGHT 274 ; 200, 256, 400, 512 274, 548 SCREEN DEPTH 3 ; 2 - 4 These entries are used to define the size and depth of the TrionRM public screen when it is used. Note that a 708 x 274 resolution is the maximum screen size I can squeeze out of my A2000/A1084S. The screen depth can be 2, 3 or 4 bitplanes. Two bitplanes mean that the same color scheme the Workbench uses is used. Three bitplanes mean that extra colors are used to make GUI's more clear. There are only 8 colors used at this time so don't put the depth at 4 planes or you will be wasting memory and slow down the blitter. MONITOR DONTCARE With this entry you can select a monitor, which is usefull if you want to use a VGA monitor. You can choose from the following monitors: NTSC 640 x 200 60Hz 15,72Khz (American 1084 mode) PAL 640 x 256 50Hz 15,60Khz (Europe 1084 mode) MULTISCAN 640 x 480 58Hz 29,29Khz (VGA/multisync monitors) EURO72 640 x 400 69Hz 29,25Khz EURO36 640 x 200 73Hz 15,76Khz SUPER72 448 x 306 71Hz 23,21Khz DBLNTSC 676 x 213 58Hz 27,66Khz DBLPAL 676 x 269 48Hz 27,50Khz DONTCARE 640 x 2xx Should work on every system INTERLACE This is a boolean keyword, if it is in the configuration file the screen will be in interlace mode, put a ';' for the word if you don't want to use interlace. With interlace the resolution will be boosted to 400 - 538 if possible. SUPER This is a boolean keyword, if it is in the configuration file the screen will be in superhires mode, put a ';' for the word if you don't want to use superhires. With superhires the resolution will be boosted to 1280 - 1448 if possible. DEFAULT FONT topaz.font 8 ; Default font TEXT FONT topaz.font 8 ; Button and StringGadgets SMALL FONT topaz.font 8 ; Lists These entries define the fonts that will be used in Trion utilities with a GUI window. COLOR 0 10 10 10 ; Mid Grey COLOR 1 0 0 0 ; Black COLOR 2 15 15 15 ; White COLOR 3 6 8 11 ; Blue COLOR 4 9 9 9 ; Dark Grey COLOR 5 11 11 11 ; Light Grey COLOR 6 9 12 10 ; Beige COLOR 7 9 10 12 ; Light Blue These entries define the colors that will be used in Trion utilities with a GUI window. The first number is the color number, the other numbers are the red green and blue values .. all should be in a range of 0 to 15. Note that colors 0 - 3 are used on a screen with 2 bitplanes, on a screen wih 3 or 4 bitplanes colors 4 - 7 are also used. Colors 8 - 15 are not used at this moment. The Trion-X.cfg configuration files ----------------------------------- For every BBS node you want to run you need a configuration file called Trion-X.cfg where the X is substituted with the number of the node. In the file the information for screen, serial port, modem, mailer information and a few other things is contained. These are all the possible entries: LOCAL NULLMODEM ICON 370 0 FONT cleanibm.font 8 SCREEN WIDTH 640 SCREEN HEIGHT 256 SCREEN DEPTH 4 MONITOR DONTCARE INTERLACE SUPER SERIAL DEVICE serial.device SERIAL UNIT 0 SERIAL BUFFER 16384 DEFAULT BAUD 38400 DEFAULT LENGTH 28 DATA BITS 8 STOP BITS 1 PARITY OFF INIT STRING "ATZ|^5AT &F2 B0W2S95=2E0M1L1#CID=1|AT+FAA=1|" TERM STRING "ATZ|^5AT &F2 B0W2S95=2E1M1L1S2=43|" DIAL STRING "ATS11=50DT" ANSWER STRING "ATA|" RING STRING "RING" CONNECT STRING "CONNECT" FAX STRING "FAX" VOICE STRING "VOICE" RINGS 2 CARRIER DELAY 45 CONNECT DELAY 30 ESCAPE DELAY 2 HANGUP DELAY 25 MAILER ZEDZAP DIRECTZAP ZEDZIP ZMODEM TERM PATH RAM: PAGE SAMPLE trion:samples/startrek-Alert 3 BELL SAMPLE trion:samples/startrek-comm SLEEP WARNING 90 SYSOP NAME "Paul Spijkerman" SYSTEM NAME "Amiga Pet Shop BBS" SYSTEM CITY "Gasselte,Dr,NL,EUR" SYSTEM PHONE "+31-599-564696" SYSOP COMMENTS 1 VALIDATE LEVEL 10 EDITOR Ced GATE 2:284/324.999 SKIPEXISTINGUPLOADS More lengthy explanation of the Trion-X.cfg entries: ---------------------------------------------------- General entries --------------- LOCAL This is a boolean keyword, if it is in the configuration file this node will run in local mode, put a ';' for the word if you don't want this node to be in local mode. In local mode the node can't open a serial port. NULLMODEM This is a boolean keyword, if it is in the configuration file this node will run in nullmodem mode, put a ';' for the word if you don't want this node to be in nullmodem mode. In nullmodem mode you can connect a serial cable to the serial port used by this node and connect it to a terminal or other computer with a terminal program instead of a modem. In this mode the program will not send modem strings and will wait for a press on a return key instead of a RING string. DEFAULT LENGTH 28 This defines the default screen length at 28 lines, so if a new user logs in, until he gets to the screen length question the length is 28 lines. When he just enters return at the screen length question he will get this screen length. ICON 370 0 This is the X and Y position on the Workbench screen of the icon of this node in the iconized mode. The icon is a little window which you can click to DeIconize the node. In the icon you can see the number of the node, the name of the user logged in (or a waiting message) and a '*' if the user online has paged for the sysop. FONT cleanibm.font 8 This entry defines the font that will be used in this node. Note that an IBM type font is normally used/ SCREEN WIDTH 640 SCREEN HEIGHT 256 SCREEN DEPTH 4 These entries are used to define the size and depth of the screen of this node. The screen depth can be 1 to 4 bitplanes. In the BBS node is a pulldown menu entry to switch between numbers of bitplanes. Note that 1 bitplane is a lot faster then 4 bitplanes when reading mail. MONITOR DONTCARE With this entry you can select a monitor, which is usefull if you want to use a VGA monitor. You can choose from the following monitors: NTSC 640 x 200 60Hz 15,72Khz (American 1084 mode) PAL 640 x 256 50Hz 15,60Khz (Europe 1084 mode) MULTISCAN 640 x 480 58Hz 29,29Khz (VGA/multisync monitors) EURO72 640 x 400 69Hz 29,25Khz EURO36 640 x 200 73Hz 15,76Khz SUPER72 448 x 306 71Hz 23,21Khz DBLNTSC 676 x 213 58Hz 27,66Khz DBLPAL 676 x 269 48Hz 27,50Khz DONTCARE 640 x 2xx Should work on every system INTERLACE This is a boolean keyword, if it is in the configuration file the screen will be in interlace mode, put a ';' for the word if you don't want to use interlace. With interlace the resolution will be boosted to 400 - 538 if possible. Interlace can be toggled from a pulldown menu in a bbs node. SUPER This is a boolean keyword, if it is in the configuration file the screen will be in superhires mode, put a ';' for the word if you don't want to use superhires. With superhires the resolution will be boosted to 1280 - 1448 if possible. SuperHires can be toggled from a pulldown menu in a bbs node. Serial port ----------- SERIAL DEVICE serial.device SERIAL DEVICE nullmodem.device SERIAL DEVICE 8n1.device This line defines which serial device this node should use, default this would be "serial.device" but if you want to reach speeds 19200 or 38400 baud on a 68000 you could try the "8n1.device" which can be found on Aminet. For testing you can use the "nullmodem.device", which emulates 2 serial ports, 2 modems and a telephone line between the modems. Note that default node 6 and 7 are configured to use the nullmodem.device. If you use a serial board you need to put the name of the provided serial device at this entry. SERIAL UNIT 0 This is the serial port this node is going to use, when you use the standard serial port this value is ignored, but in the nullmodem device this value is very important. Also if you use a serial board you have to put the port number here you want to use for this node. SERIAL BUFFER 16384 This is the size of the buffer the serial device should make, normally 16K is plenty of room, because with a V34 this gives you 5 seconds of buffering. Plenty of time to stop the datastream with hardware handshaking. DEFAULT BAUD 38400 This is the speed at which the computer "talks" with the modem. This can be a value of 2400, 4800, 9600, 19200, 38400 or 57600 baud. The maximum speed you can use without getting errors depends on processor speed, serial device and if your iconized or not and the kickstart rom. With a only a 68000 processor 9600 baud is about the maximum with the standard device, with 8n1.device you can use 19200 baud. If you have a 25 Mhz 68030 you can use 38400 baud, in iconized mode. If you have the KS 2.04 rom in deiconized mode you may get some errors .. but with KS 3.1 in fastram that is fixed. If you have a zorro board with buffered serial ports you can use higher speeds. DATA BITS 8 STOP BITS 1 PARITY OFF These fields define the way data is send over a serial line. The number of databits can be 7 or 8, the default number is 8 which is also the most used value. The number of stop bits can be 1 or 2, the default number is 1 which is the most used value. The parity can be OFF (no parity), ON (parity Even) or ODD (parity Odd). Parity is sort of a primitive error detection and is not much used these times because modems have a much better error detection and even correction system. Parity means that you count the number or ones in a byte and send an extra bit if the number if odd or even. Sometimes when some one gives you the phone number of system you have to call by modem a 3 character code is given to tell you how to configure your serial port. This code is usually 8n1 which means 8 data bits, no parity and 1 stop bit. Here are a few of the most used combinations. For normal BBS use: (8n1) = 8 DataBits , 1 StopBit , Parity OFF For Minitel terminals (France) use : (7e1) = 7 dataBits , 1 StopBit , Parity ON Modem strings ------------- In this part modem strings are discussed. Note that there are two kinds of modem strings. The first group are strings that are SEND to the modem. For example strings to initialize it or to dial out or answer a call. The second group are strings that are received from the modem, they are handled quiet differently and discussed in the second part. 1. Strings that are send to the modem. INIT STRING "ATZ|^5AT &F2 B0W2S95=2E0M1L1#CID=1|AT+FAA=1|" TERM STRING "ATZ|^5AT &F2 B0W2S95=2E1M1L1S2=43|" DIAL STRING "ATS11=50DT" ANSWER STRING "ATA|" Note that these strings have limited space in memory. The init string can be up to 200 characters. The term string can be up to 100 characters. The dial string can be up to 40 characters. The answer string can be up to 40 characters. Note that a lot of modems only can accept 40 characters at once in the buffer for strings. So if your initialization is longer you probably have to split it up in two or more strings. Something like this: "AT....|AT....|" Also note that these strings are read to memory when you run the 'bbs' executable .. so changing the strings has no effect until you stop and run the 'bbs' executable. Note that if you want to use spaces in a modem string you have to put the whole string between "" characters. Modem strings may contain some special codes that can be interpreted be the code that sends them to the modem. Use a '|' character as a carriage return to end the string. The '^' character is used as an escape character and has to be followed with a special character. "^n" (where 'n' is a number from 1-9) means a pause of n x 1/5 seconds. "^1" is a pause of 1/5 second. "^5" is a pause of 1 second. "^^" means that a '^' character is send to the modem. Note that when you use a '^' for a phone number when dialing the modem will producs "fax" tones. Which can sometimes be needed when a BBS is put behind a "fax selector" box. Note that the BBS expects text result strings after a string is send to the modem, not numerial results !! The init string: The init string is send to the modem when the program is started or after a call to initialize it properly. This is needed so the modem knows what parameters to use or if it is supposed to answer faxes also, or monitor the line for callerID when a call is coming in. With most modems a simple: "ATZ|^5" is enough. This is a command that resets the modem and it will use the default settings from its memory. You might want to add "S2=255" to your init string, to prevent that users put your modem in command mode by sending a "+++" string (with the correct delay times before and after it) .. however if you want to use the modemcommand menu command don't use it because the menu command wont work. Trion expects connect lines in this form: "CONNECT 14400/ARQ" Add something like "W2S95=2" to your init string to accomplish this. If you want CallerID send to the log (the phone number of the calling party) you have to add "#CID=1" to your init string. If you want to be able you have to add "+FAA=1" to your init string. Actually you have to give the modem all kind of information to be able to receive faxes something like the following example but it is far more practical to have these codes send by a fax program so you don't have to find out which codes to send for which papersize and other capabilities. A fax program can init the modem by calling the fax.init script in the logout.X and incoming.X scripts. AT+FAA=1;+FCLASS=0;+FLID="+31-599-564696 ";+FCR=1;+FDCC=1,,0,2,0,0,0,5 Here is some information how to use GPFax with Trion: If you want to use GPFax to receive faxes while the BBS is online you have to edit the trion:startup script. All you have to do is remove the ';' for the lines that startup GPFax. When you now use trion:startup GPFax will startup and init te modem before the BBS nodes get online. You have to add something like 'AT+FAA=1' or '+FAA=1' to your BBS init string, this makes the modem look for faxes also if answering the phone. When a fax call is detected, the 'fax.script' will be executed to spawn a fax receive programm. Most modem also need the folowing in the initstring to receive faxes correctly: '+FCLASS=0' '+FLID='+31-xxxx-xxxxx' (Your phone number) '+FCR=1' '+FDCC=1,,0,2,0,0,0,5' If you have problems receiving faxes or you have only added '+FAA=1' to your init string .. you can use the 'fax.init' script. Most fax problems are caused by previous data calls, if you get a data call after GPFax has init the modem the above mentioned data will be erased from your modem, if you get a fax call after de data call .. you will probably receive nothing. When you call the 'fax.init' script it will use GPFax to init the modem again and fax receiving should be no problem. You should call 'fax.init' after each data call in the 'incoming.x', 'logout.x' and your poll scripts. Note that the fax init is only lost after a data call, an ATZ command to reset the modem is no problem. The term string: The terminal string is the string used to initialize the modem in the build in terminal. This is done because you might want to use a different string then the default init string. If you for instance want to use the "+++" command to put your modem in command mode during a call then you remove "S1=255" from the term string. The dial string: This is the string that will be send to the modem to dial out. DO NOT terminate this string with a "|" (carriage return) because the program will put a phone number and a carriage return after the string. A dial string will be something like "ATDT" .. but you might want to add codes to make dialing faster like "ATS11=50DT" or codes to select ISDN or analog modes of your modem. The answer string: This is the string that will send to the modem to answer after "RING" strings are received. Normally "ATA|" will do fine. Not that you can not put your modem in auto answer mode because the BBS will not work in that mode, it will not know that the modem has answered a call. It is not a good idea to use Auto Answering anyway because you may have put a BBS node in "non answering mode" because you are processing mail. Or if the software is not able to answer the modem, because a write action to a full disk has occured and a requester has popped up .. your modem would still answer every call. 2. Strings that are received from the modem. Note that there are only 4 types of strings defined here and that they can be a part of larger strings. Note that you don't have to configure all the combinations of connect strings that can occur because the BBS uses code to analyse connect strings and tries to recognize each part of it. RING STRING "RING" CONNECT STRING "CONNECT" FAX STRING "FAX" VOICE STRING "VOICE" Note that these strings have limited space in memory. The ring string can be up to 16 characters. The connect string can be up to 20 characters. The fax string can be up to 16 characters. The voice string can be up to 16 characters. Note that the BBS program has also a number of "hard coded" strings. It will recognize a RING when it sees a "RING" string no matter how you define the ring string. It will recognize a normal connect when it sees a "CONNECT" or "CARRIER" string no matter how you define the connect string. It will recognize a FAX connect when it sees a "FAX" or "+FCO" or "+FCON" string no matter how you define the fax string. It will recognize a voice connect when it sees a "VOICE" string no matter how you define the voice string. The ring string: This is the string that is used to recognize if someone is calling. Some older modems may have an alternative to the default "RING". The connect string: You only have to specify the word that indicates the start of the connect line, the BBS while analyse the string for its data contents. During normal data calls, Trion is expecting a connect string in one of the following styles: "CARRIER 14400" "CARRIER 24000/LAPM" "CONNECT 12000/ARQ" "CONNECT 14400 REL/V42" "CONNECT 14400/LAPM/V42BIS" "CONNECT 28800/LAPM/V42BIS" "CONNECT 14400/ARQ/V32/LAPM/V42BIS" "CONNECT 28800/ARQ/V34/LAPM/V42BIS" "CONNECT 64000/ISDN/X75" "CONNECT 64000/ISDN/X75/V42BIS" The BBS will examen the connect string to determine the baudrate, compression, analog/digital, error correction and other information about the connect. It will use the baudrate and the compression indication to calculate the expected transfer times of files. So make sure you get the DTE speed when connecting. The FAX string: This is the string that has to be recognized to spawn a fax program. Note that the important ones are already recognized but some new fax class may have an alternative string. The voice string: This is the string that has to be recognized to spawn a voice program. Note that I havn't had any experience with this yet, so I don't know if there are actuall voice programs you can spawn. RINGS 2 This is the number of "RING" strings the modem is sending to the BBS program before the program answers. A "RING" string is send to the program when the modem receives the signal that makes a normal phone ring. Normally there is 5 seconds between ring's. Normally you set this value to 1, but if you have CallerID (CID) selected in your init string you want to use 2, because between the first two rings caller data is send from the modem the BBS. At this moment the CallerID data is only logged, but in the future I may want to implement a selective answering logic so that the call is only answered when there is mail for the calling party. Also CallerID is usefull the check if someone uses his real name. CARRIER DELAY 45 ;(secs) CONNECT DELAY 30 ;(ticks) ESCAPE DELAY 2 ;(secs) HANGUP DELAY 25 ;(ticks) Note that a "tick" is 1/50th of a second. The carrier delay is the time the BBS will wait after answering the modem until a connect has been made. If no connect is made in this time, the answer code will escape with a timeout and init the modem and resume the wait mode. The connect delay is a little obsolete by now, because modems and the answering code is changed. It was used as a pause between the time first connect data arrived from the modem and the time the program starts to interpret it, because old modems may still be talking to each other to determine error correction and data compression after the connect string was send to the computer. So the /ARQ part may come later. The escape delay is the time between the connect is arrived and the moment that the copyrigth/welcome/press escape text is send. This was added because some mailers may not be listening to the serial line right after the connect and miss it. The hangup delay is the time the "Terminal Ready" line will be dropped to disconnect the modem. MAILER ZEDZAP DIRECTZAP ZEDZIP ZMODEM The mailer entry will tell the BBS which protocols are useable for file transfers in the mailer. During a mailer session this information is exchanged to decide which protocol to use. Basically you want to specify all protocols you are able to use. Protocols that you can specify are: HYDRA ZEDZAP DIRECTZAP ZEDZIP ZMODEM The program will also recognize: HYDRA8 JANUS KERMIT But these have their problems, the HydraCom program has no option to tell it to go to 8192 byte packets. There is no XprJanus library available, and the Xprkermit transfers are to slow, and succesfull transfers are not recognized which causes even more problems. Check the protocol.cfg description for more information about the availability of the protocols. TERM PATH RAM: This is the path where downloads that are done from the buildin terminal are stored. Note that it has to end with a ':' or '/'. This path is also used as default for the filerequester that appears when an upload command is given in a local node. PAGE SAMPLE trion:samples/startrek-Alert 3 BELL SAMPLE trion:samples/startrek-comm These are the definitions for the sound samples used when someone pages the sysop or a Ctrl-G code (Bell) is send or received. The number after the sample name is optional and it the number of times the sample is played. The default value is one. Note that the samples have to be uncompressed IFF files. SLEEP WARNING 90 This is the number of seconds between the last action of a user and the moment that an inactivity warning is shown. If after the warning nothing happens the user is logged off after an other 60 seconds. Note that this also works in chat mode. SYSOP NAME "Paul Spijkerman" SYSTEM NAME "Amiga Pet Shop BBS" SYSTEM CITY "Gasselte,Dr,NL,EUR" SYSTEM PHONE "+31-599-564696" These are fields with information of your system that is presented to the other system when a mailer calls in or someone logs in with an IEMSI terminal. Also it is used in file description files that are created when a user downloads files. Also the sysop name is used for comment's to sysop. Note that underscores are allowed to replace space but even better is putting the text between "". SYSOP COMMENTS 1 This is the number of a local message section where comments to sysop are stored. Note that the value must be higher than zero. VALIDATE LEVEL 10 This is the level that a user gets when you press F4 in a BBS node. This is usefull when you want to upgrade the level of a newuser with one press of a key, when you for instance "looked over his shoulder" when he entered the answers in the Questionair. Note that you can only increase a level with the F4 key, you can't lower (degrade) the level of the sysop for instance. EDITOR Ced This is the name of a local editor that is used when you write mail and have selected a local editor (only in a local node) also this editor is used for message signatures. GATE 2:284/324.999 This is a fido-net style nodenumber of a BBS with an E-mail gate. If you use the E flag in a netmail message section then that section has E-mail support. This means that when you write a message in that section an E-mail address is asked. When you actually give an E-mail address the BBS will not ask for a nodenumber but will send the message to this gate nodenumber. Note that this isn't actually the nodenumber of the BBS itself but a point number allocated to the gate software. SKIPEXISTINGUPLOADS This is a boolean keyword, if it is in the configuration file uploads that exist are skipped, put a ';' for the word if you don't want to skip them. If you use this word an upload is immediatly terminated when a file with the same name is found on the BBS. If you allow "existing uploads" then a new name is asked for the file and it is renamed before it is uploaded. The BBStext-X configuration files --------------------------------- The configuration directory contains a number of BBStext-X.cfg files (where the X is substituted with a number). They contain the text lines the BBS should use for each language. Note that these files are the raw data or source files, they have to be "compiled" by running the BBStext program. The compiled BBStext files are stored in the Trion:data directory. For every language or menuset you have a seperate BBStext file so you can easily add (and obtain) bbstext files for different languages who are constructed by other people. BBStext entries consist of lines needed by the compiler to know which line we are defining folowed by the actual text we want to use in the BBS. In the text lines you can use special characters to get certain effects .. these characters are translated by 'BBStext' to the corresponding ascii codes, which make bbstext files easier to read and change. Also a lot of lines have codes which can be used in these lines and are replaced by the BBS at execution with numbers or text lines. These codes consist of a '%' character folowed by a letter. (%a %b %c %d %e %f etc.) For those of you who can program in 'C' .. it works a little bit like C but there are differences! In C the letter stands for a certain type of variable .. but in BBS a letter has a fixed meaning in every line and can be of different types. There are no fixed types. (note the types are in the comment lines in the BBStext-X.cfg) In other software standard C types are used wich has a major drawback .. that you have to use them in a fixed order, wich isn't the case with trion. Note that a BBStext entry can be about 1000 characters each. Note that tilde codes may be used. Use '|' characters as 'return' characters (End Of Line). Note that the whole entry should be on one line, if the text is displayed as multiple lines in the BBS you should add multiple '|' characters as returns. Comments may be made but only between definitions, comments are lines starting with a ';' Note that underscores have the same effect a spaces !! Which can be convenient to 'see' the end of a line, if a line ends with a space, if for instance input is expected at the end of a line. Also some editors strip the spaces from the end of a line. Codes useable for translation to ASCII code: '\a' -> Bell (alert) '\b' -> Backspace '\r' -> Carriage return '\n' -> Newline '\\' -> '\' BackSlash '_' -> ' ' space ' ' -> ' ' space '|' -> '' Carriage Return folowed by a newline NOTE: Underscores have the same effect a spaces !! which can be convenient to "see" the end of a line also some editors strip the spaces from the end of a line Use '|' characters as 'return' characters (End Of Line) Like in the C language you can add numbers (positive and negative) to the '%' codes to fix the look of the text in the BBS: '%_' -> '_' Underscore '%|' -> '|' '%%' -> '%' '%A' -> 'xxxxx' Line 'A' '%8A' -> ' xxxxx' Line 'A' filled with spaces to fill 8 places '%-8A' -> 'xxxxx ' Line 'A' filled with spaces to fill 8 places Note that the 8 is an example and can be replaced by other numbers. Note that the % fields can be strings, 16 or 32 bit variables, look at the comments in the BBStext files to make sure. You can use most of the format methodes for each kind of field you can use in the C programming language. The language.cfg configuration file ----------------------------------- The language configuration file just contains a list of numbers with language names behind them. Like so: #0 ANSI_English #1 ANSI_Nederlands #2 ANSI_Deutsch Comments may be made by using ';' characters. The list is shown in a sligtly different form when a User selects a language. Note that only the number of the selected language is stored in the userdata. The number is used to select a BBStext-X.cfg file and the determine which menutext directory to use. Note that if there is no menutext directory with the correct number the default directory without a number will be used. The badnames.txt configuration file ----------------------------------- The badnames.txt configuration file is used to prevent users to use certain names. This is done by placing illegal names on separate lines. You could for instance place words like "new" or "test" on a line when you only allow users to log in with their real names. Also you can use wildcards so new users can't choose names with rude words in them. Note that this config is not case sensitive. Note that wildcards *, #? and ? allowed. Note that you can place comments in the file after a ';' character but you can only place ';' characters at the first position of a line. The term.names configuration file --------------------------------- This file is a little phone book for the simple buildin terminal. It contains names and phone numbers of people you call often. You simply place the name(s) of a person on a line, the last entry on the line should be the phone number. You can use the full name and also the first name or nick name of BBS name of a person. The program will try to match one of them and then use the phone number at the end of the line. Note that the first name on a line is used as "nice name" and is written to the log and the screen when a match is made. Here is a little example: paul_spijkerman Paul "Amiga pet shop BBS" ^^05999-64696 "paul spijkerman" Paul 05999-64696 Note that this config is not case sensitive. You can't use spaces in names, you have to replace names with underscores or place the name between "" characters. You can use ^^ for a phone number to send a ^ to the modem for fax tones while dialing (to bypass BBSes with one line and a fax selector). The unpack.cfg configuration file --------------------------------- The unpack configuration file contains information on how to use archivers by certain programs. This configuration file is used by the tick processor to unpack archives wich contain a number of .tic files. Also it is used by the unpack program, which is a frontend for archivers and other programs. The default configuration file is not only configured to show information on archives but also on pictures. Note that more information can be found in the Trion:docs/utils/unpack.doc This configuration is only mentioned here because it is used not only by Unpack but also by tick. This had a reason tick uses this file instead of the archivers.cfg which was especially made for the mail processor. The entries in the archivers.cfg only tries to extract files with a .pkt extension and does this quietly. Which isn't very usefull if you want to SEE what is going on. Maybe in a next version the archivers.cfg will be extended with lines that are not dependable on extensions and can be used with tick. The protocol.cfg configuration file ----------------------------------- The protocol configuration defines how external file transfer protocol programs are to be used. The BBS and the mailer use mainly XPR libraries to transfer files but also the HydraCom module can be used. At this moment only the XPR file transfer libraries are configurated in this file. A sample of a protocol could look something like this: #0 "Zmodem" BATCH RESUME "xprzmodem.library" "TN" "TN" The format used is as follows: number name batch resume libname ReceiveCfg SendCfg Number ----- The number is a number between 0 and 127 for normal BBS file transfers and between 128 and 255 for mailer file transfers. The numbers for the mailer protocols are "fixed", the numbers for BBS protocols can be swapped. Number 0 is default for newusers (preferable Zmodem). number 128 is used for EMSI file transfers (1024 byte Zmodem). number 129 is used for EMSI file transfers (8192 byte ZedZap (or Zmodem)). number 130 is used for EMSI file transfers (1024 byte ZedZip). number 131 is used for EMSI file transfers (8192 byte DirectZap). number 132 is used for EMSI file transfers (Kermit). number 133 is used for EMSI file transfers (Janus). The numbers 200 and 201 are used for modules and can't be configured in this file. number 200 is used for EMSI HYDRA mailer transfer. number 201 is used for EMSI HYDRA8 (max block size 8192 instead of 2048). Name ---- The name is used in logs and displayed on screen or in the user editor to show the current file transfer protocol. Batch ----- Batch indicates of the protocol is able to send or receive multiple files in a session like Zmodem is able to. "batch" can be "BATCH" or "SINGLE" Resume ------ Resume indicates of a protocol is able to resume a previous file transfer that was aborted before the all the bytes where transferred. If a protocol is able to "resume" then partially received files are not deleted. "resume" can be "RESUME" or "RETRY" Libname ------- Libname means the full name of the XPR library that is to be used for this protocol. ReceiveCfg & SendCfg ---------------------- These are strings to configure the library in Receive or Send mode. In these strings parameters can be send to the library. Note that some libraries are able to provide multiple protocols or variants on the same protocol which are slightly different, or use a different block size. With these strings you can tell a library which protocol and which blocksize are to be used. Note: Zmodem uses 1K blocks, no options to send "no files." SZmodem (Zmodem variant) uses 8K blocks (Super Zmodem) ZedZip (Zmodem variant) 1K blocks, option to send "no files.", ftn mode ZedZap (Zmodem variant) 8K blocks, option to send "no files.", ftn mode block size based upon bps rate DirectZap (ZedZap variant), minimum escaping (less bytes send) Zmodem and variants use "XPRZmodem or XPRzedzap library's Kermit Xprlibrary available, but no info how to use, very slow !! Janus Bidirectional protocol (no XPR library available ???) Hydra Bidirectional protocol with chat, max 2K blocks Hydra 8K Bidirectional protocol with chat, max 8K blocks Hydra uses the HydraCom program SModem protocol very much like Hydra, max 1K blocks SModem uses the smodem program (Not supported at this time) (Block size may vary under line quality and baud rate) (Larger blocks increase efficiency a little because of less overhead from block headers) (SZmodem and Smodem are not used by mailers) The templates.cfg configuration file ------------------------------------ The templates configuration file defines all the capabilities a user with a certain user level has. Every level has a "template" in this file to define the access for message and file sections .. and the number/bytes of files can be downloaded each day and how many messages can be written. Also it defines how ratios between uploads and downloads. Or how many files/bytes have to be uploaded before a number of files/bytes can be downloaded. Levels 240 and up have special possibilities and are used for (Co)Sysops. For Instance When you list users with this level you will see also the alias of the Users. Here is an example of a template: Level 10 NormalUser FileRatio 25 ByteRatio 25 DownloadPerDay 1000000 FreeBytes 1000000 FreeDownloads 10 TimePerDay 45 CallsPerDay 5 MaxMsgsPerDay 10 MsgAccess [V-PW--] , 1 , 3 MsgAccess [VR----] , 5 MsgAccess [V-P---] , 10-40 MsgAccess [VR-W--] , 2 , 100-199 , 200-299 , 800-899 FileAccess [VLDU---] , 1 , 3-5 , 6-9 , 12-14 , 20-35 , 60-73 FileAccess [V--U---] , 2 A template consists of 4 parts: -Definition of level number and level name. -Definition of parameters that apply to this level. -Definition of the access to message sections. -Definition of the access to file sections. Parameters for a level ---------------------- FileRatio <= if the ratio between the number of downloaded files and uploaded files is equal or higher then this number then a user has to upload before he can download. disabled when 0 or 'Off'. ByteRatio <= if the ratio between the number of downloaded bytes and uploaded bytes is equal or higher then this number then a user has to upload before he can download. disabled when 0 or 'Off'. DownloadPerDay <= Number of bytes a user can download each day. FreeBytes <= Number of bytes a user can download before ratio's kick in. Note that if zero a new user first has to upload before he can download. FreeDownloads <= Number of Files a user can download before ratio's kick in. Note that if zero a new user first has to upload before he can download. TimePerDay <= minutes a user can be online a day 'Off' = 1500 minutes (a day = 1440 minutes) CallsPerDay <= Number of calls a user may make a day MaxMsgsPerDay <= Number of msgs a user may write on a day Message section access flags ---------------------------- Msg flags: View Read Private Write Attach Special V = View, User sees area in Lists and can go to this area. R = Read, User can Read/Scan all messages in this area. P = Private, User can only Read/Scan messages To and From him. W = Write, User can Write in this area. A = Attach, User can Attach files to messages. S = Special, User can Read/Scan deleted or private messages. File section access flags ------------------------- File flags: View List Download Upload Freedownload Edit Newfilesvisible V = View, User sees area in Lists and can go to this area. L = List, User can Browse and FileList through this area. D = Download, User can Download from this area. U = Upload, User can Upload in this area. F = Freedownload, This area is Freedownload for users with this level. E = Edit, User can Edit files in this area (FI while browsing). N = NewFilesVisible, UnValidated files are visible. with 'Off' you can turn off al field (same effect as value 0) with 'All' you can use all areas with the given flags You can use 'Off' with: TimePerDay, FileRatio, ByteRatio, MaxBytesPerDay, MaxMsgsPerDay