& bbs.tcl & bbs BBS.TCL, Copyright 1999, Jonathan A. Booth (kamikaze@imsa.edu). BBS.TCL is a TCL script that implements a bulletin board system (BBS) in TCL code rather than MUSH code. It has been designed differently from all the BBSes I have seen code posted to the net for. The following topics about BBS.TCL have helpfiles: (help bbs ) attributes changes compatibility install intro quickref security BBS.TCL defines the following commands: (help ) @bbs & bbs attributes & bbs attrib The following two attributes are used by the BBS, and should be restricted to deny players the ability to modify them: (use '@attribute/access/retroactive BBS_READ=wizard mortal_dark') BBS_READ posts the player has read BBS_IGNORE posts the player is ignoring If players are allowed to modify them, strange behavior may result when a player has read the BBS, and so has one of their attributes cached by it, modifies it, then reads more BBS, and the BBS overwrites how the player modified it. Instead, players should use @bbs/forget to "forget" that they have read certain posts. See also: 'help bbs' & bbs changes Version 1.0.7 beta: * Typo caused $larg to be "larg" not the value of it. Report by Lichten@M*U*S*H * Suggestion for '@bbs/basepost =<text>' to change post 0 by Lichten@M*U*S*H implemented. Version 1.0.6 beta: * Yet another dumb bug for the inital post, it's parent should be set to 0, not -1! Report by Lichten@M*U*S*H * 'help bbs version' moved to 'help bbs changes' Version 1.0.5 beta: * MUSHes without my connect/disconnect patch to TCL won't have the script fail to load anymore. * /autoseq renamed to /new Version 1.0.4 beta: * Some switches were missing from @bbs/help -- fixed * CacheWrite doesn't end up getting rid of dupes, it does now. * Extended the Cache to BBS_IGNORE not just BBS_READ * Compressing and various other operations order the player's BBS_READ variable. Version 1.0.3 beta: * Fix where non systemadmin got lots of errors doign @bbs because of the systemadmin-always-passes-locks check fixed, report by Maestro@M*U*S*H Version 1.0.2 beta: * Cacheing added * @bbs/forget added * helpfiles updated Version 1.0.1 beta: * Corrected a dumb bug (inital post 0 missing expiration threshold!), report by Maestro@M*U*S*H Version 1.0 beta: * Inital public release & bbs compatibility & bbs compat As you may have realized, BBS.TCL is not compatible with Myrddin's BBS. That is because of the way that data is organized in this BBS, where it is organized as a tree, rather than an array (each board in Myrddin's is a row, posts go down each row). Because of these structural differences, I decided against making an importer for boards from Myrddin's BBS -- the structure they have does not make sense in a threads-oriented system. Take for example a situation I found myself in: I had a 'Admin' and 'Projects' board, both restricted to roy/wiz. Admin was for general Admin discussion, Projects was for us working on the MUSH's systems to update each other as to how things were going. Projects was really a specialized admin discussion, and made much more sense when as a child of Admin than as a main discussion thread. Continued in 'help bbs compatibility2' & bbs compatibility2 & bbs compat2 Continued from 'help bbs compatibility' Importing from Myrddin's BBS, both would have been created as top level discussion forums, which goes against the way this BBS was designed. Hence, the decision not to make an importer for Myrddin's board format. Not that it is not possible to make an importer, it would actually be relatively easy to write MUSH code to import from Myrddin's to my BBS -- but it breaks the ideas behind my BBS and makes it try to be just a clone of Myrddin's, which it is not. See also: 'help bbs' & bbs install Unlike a lot of my other code, installation of the BBS is about as simple as can be -- simply change config(path) at the top of the header file to point to whatever path you want the bbs's save files to go in relative to the directory that holds the 'bbs.tcl' script, create the path to that location and the 'savefile.txt' using 'mkdir' and 'touch' (to touch the file into existence), then load the bbs (as god!) via: @tcl/load/master <path to bbs.tcl> Example: - my bbs.tcl script is in pennmush/game/tcl/bbs.tcl - I use the default config(path), so I run + mkdir pennmush/game/tcl/bbs + touch pennmush/game/tcl/bbs/savefile.txt - I run '@tcl/load/master tcl/bbs.tcl' to load the bbs You need to restrict the BBS_READ and BBS_IGNORE attributes so they are not player settable -- see 'help bbs attributes' for more information on this. After that, you're done, it's up and running. Read the helpfiles to get a gist of the commands and commence playing with the BBS. See also: 'help bbs' & bbs intro The structure of this BBS is likely to be foreign to many of you, totally unlike what you have used before. Well actually that's not true. This BBS is designed as a tree, each post having any number of children, who can have any number of children and grandchildren and ... themselves. And if you've worked much with a computer, you've already worked with trees; the files on your disk drive... they are stored as a tree too. But why does this matter, you ask. Well, say there's a bulletin board you aren't intersted in, you can ignore all posts to that board. "Great," you say, "I can do that already." True, but can you decide to ignore this one particular thread debating the size of a space 'unit' on the discussion board when you don't really care? Not with most BBSes out there, but the tree structure of this one allows it. Continued in 'help bbs intro2' & bbs intro2 Continued from 'help bbs intro' That's all well and good, but I'm sure most of you still don't understand this "reply" thing, so think of it this way: * Each "reply to post 0" is just like a "group" or "bulletin board" * Each "reply to a reply to post 0" is just like a post to a "group" Unfortunatly the analogy breaks down here, because there is no analogy for a reply to a reply to a reply, and so fourth, other than board spam (you know, where a board has over 100 posts on it, half of them new). The structure of this board organises them so that you don't have to see them if you don't want to, or so that at least one really active thread won't overwealm anything else being discussed on that board. See also: 'help bbs' & bbs license The script's license information is now listed under '@bbs/version'. Please use that command to see the license. See also: 'help bbs' & bbs quickref Quick reference to the BBS, in terms of a more traditional bbs: -- Reading @bbs list groups @bbs <groups> list posts in groups @bbs <posts> read posts and list their replies @bbs/scan scan the bbs for new posts @bbs/autoseq read all unread posts @bbs/autoseq <groups> read all unread posts filed under <posts> -- Writing @bbs/post <reply to> post a response to <reply to> @bbs/title <title> change the title of your response to <title> @bbs/write <text> adds <text> onto the end of your response @bbs/wipe wipes out all the text (only) of your response @bbs/stop stop responding, delete response totally @bbs/edit <old>=<new> changes <old> to <new> text in your response @bbs/show displays your response, formatted as if posted @bbs/post post your response Note that just using commands out of this quickref, you lose much of the power of the BBS. They do make a good starting point, through. See also: 'help bbs' & bbs security This BBS is more secure in many ways than much other MUSH code, but also has one glaring security hole: Any player who passes the systemadmin check (stored in config(systemadmin), changeable via @bbs/config systemadmin=<stuff>) can get an exact copy of your BBS's text and configuration via @bbs/debug. However, if you can't trust your wizards (those who by default are system admin), you have bigger problems than them stealing the BBS. Just be aware that anyone who can @bbs/debug can do that and you'll be okay. On the flip side, because the data for the BBS is not stored in MUSH based objects, but on disk and in TCL's memory. This means that players who have the see_all power can't browse any of the bulletin boards they want by exing objects. The BBS also never evaluates any text given to it, so players can pass in MUSH code or TCL code galore, without having any information stripped out of their post and still maintaining security. See also: 'help bbs' & @bbs @bbs[/<switch>] [<larg>][=<rarg>] @bbs is the command interface to the BBS.TCL script. All interaction between the script and players occurs in this command. The values of <larg> and <rarg> vary from switch to switch of this command, and are listed below in the table if they are applicable, or are filled in with 'none' if not applicable. []s indicate an optional argument as usual. When called with no switches and a list of posts in <larg>, @bbs will display the requested posts if the player can see them. Continued in 'help @bbs2' & @bbs2 @bbs[/<switch>] [<larg>][=<rarg>] Continued from 'help @bbs' A quick (but long) reference of the switches and their arguments can be found in 'help @bbs switch list', or each switch's description can be seen with 'help @bbs/<switch>'. Parens indicate an alias to another switch, don't type the parens when asking for help. SWITCHES: BASEPOST BEGIN (POST) CATCHUP COLOR COMPRESS CONFIG DEBUG DELETE (CLEAR) EDIT EXPIRE FINISH (POST) FIX IGNORE LOAD LOCK MOVE NEW (READ) SAVE SCAN SHOW STOP (QUIT) TIMEOUT TITLE TOUCH UNLOCK WIPE WRITE & @bbs/basepost @bbs/basepost <title>=<text> Admin-only command that will change the title, text, and author of the base post of the BBS's tree of posts (post 0) to be by you, titled <title> with text <text> rather than the default text, etc. See also: 'help bbs' & @bbs/begin & @bbs/post @bbs/begin [<post>][=<title>] (additional alias: @bbs/post ...) @bbs/begin starts a reply to another <post>. If the title argument is unspecified, a title of 'Re: <title of <post>>' will be selected for your post (but won't be 'Re: Re:', it will only have one 'Re:'). Note that if <post> is unspecified, it defaults to post 0. See also: 'help @bbs' & @bbs/catchup @bbs/catchup [<posts>] Post-sequencing command that marks every subtree in <posts> as read. Useful if you reset your BBS_READ, or if there was a problem with the bbs that messed up your BBS_READ, or if you've been away for a while and don't want to read 10,000 bbs posts from people complaining about nothing. Note that if <posts> is unspecified, it defaults to post 0. See also: 'help @bbs' & @bbs/color @bbs/color <designation>=<ansi codes> Admin-only command that sets one of the colors listed in @bbs/debug. Note that <ansi codes> needs to be fully explicit; don't assume that it goes back to 'n' after anything else; it likely doesn't! The <designation>s should be pretty much self-explanatory, but when in doubt, remember the old one, change it, and @bbs to see the difference! See also: 'help @bbs' & @bbs/compress @bbs/compress Admin-only command that 'compresses' the numbers of posts in the BBS to fill in holes created by deleting posts. This updates every player's BBS_READ, and takes a long time to complete. Best done when the MUSH is either down for maintenance, or has a very low player count while you do it. It's also wise to announce you're going to lag the mush in a big way. It is possible that if you have too many players and the CommandLimitPatch, this could fail because of how huge the task of updating every player's BBS_READ is. If this happens, recompile your MUSH with a higher TCL command limit defined and try again. You /may/ have to clear every player's BBS_READ and have them regenerate it by @bbs/catchup and @bbs/autoseq, but that's just the way things go. See also: 'help @bbs' & @bbs/config @bbs/config <parameter>=<value> Admin-only command that configures one of the config(<parameter>) values shown in @bbs/debug to be set to <value>. This is really only useful for turning 'color', 'debug', and 'systemadmin' to different values, changing other parameters is probably a bad idea (especially 'path' unless you happen to want to duplicate the BBS but then not be able to reload changes.) See also: 'help @bbs' & @bbs/debug @bbs/debug Admin-only command that prints some useful debugging information on the bbs -- it prints exactly the contents of the config(path) save location, but from within the bbs. This is useful to me, the author, cause it means I can confirm what's in memory. If you really hate it you could delete it from the script. It is a security hole; anyone who can @bbs/debug can steal the contents of your bbs. Of course they are probably a wizard and could be trashing the database instead, or could decompile it, or other nasty things. If you can't trust your wizards (who are Admin by the bbs's definition), you have bigger problems. See also: 'help @bbs' & @bbs/delete & @bbs/clear @bbs/delete [<posts>] (additional alias: @bbs/clear <posts>) Admin/owner command to remove <posts> and all their children from the bbs. Note if you remove something you didn't mean to, you can try to @bbs/load to reload from an older version of the bbs, but you will lose anything between that save and your current bbs state. Note that if <posts> is unspecified, it defaults to post 0. The bbs won't allow you to remove this post either, so you'll just get an error if you don't specify <posts>. This may change in the future. See also: 'help @bbs' & @bbs/edit @bbs/edit <old text>=<new text> Changes all occurrences of <old text> to <new text> in the current reply. There is no 'undo' function, so be careful that you don't foo it up. See also: 'help @bbs' & @bbs/expire @bbs/expire [<posts>][=<days>] Shows you all posts pending to expire, either at their inherited expiration date in the tree, or after the supplied number of days argument. Note that if you provide something other than a number for <days>, you will probably confuse and upset the BBS, don't be suprized if you get back garbage. (garbage in, garbage out) Note that if <posts> is unspecified, it defaults to post 0. See also: 'help @bbs' & @bbs/finish @bbs/finish (additional alias: @bbs/post) Finishes editing a reply, and posts it to the BBS. @bbs/post also does this if provided with no arguments. See also: 'help @bbs' & @bbs/fix @bbs/fix [<posts>] Attempts to fix up <posts> -- fixes include: - relinking a child to it's parent post if it is unlinked - removing nonexistent children from a post - deletetion if its parent does not exist Obviously you can also attempt fixes by hand by editing config(path), but I don't suggest that unless you really know TCL pretty well. Note that if <posts> is unspecified, it defaults to post 0. See also: 'help @bbs' & @bbs/ignore @bbs/ignore [<post> ...] [!<post> ...] @bbs/ignore is a command to allow you to filter out threads of conversation that you just don't care about. To ignore a post and all responses, you specify it's number. To unignore a post and its responses, place a ! before it (just like you were setting flags). Ignored posts do show up in '@bbs' but not '@bbs/autoseq', so you can still see what you're ignoring, you just skip them when you read all new posts. Note that if no arguments are specified, a <post> type argument is assumed to be 0. See also: 'help @bbs' & @bbs/load @bbs/load Admin-only command that will load the BBS database from disk, losing any changes between now and the last save to disk. Useful if you deleted something you didn't want to delete, if it was real recent, @bbs/load can recover it. See also: 'help @bbs' & @bbs/lock @bbs/lock <posts>/<lock>[=<code>] Probably the most difficult of the BBS commands, @bbs/lock acts just like the MUSH's @lock function, with a few exceptions. The only valid locks that @bbs/lock recognizes are: admin Who can use admin commands on the post read Who can see/read the post touch Who can 'touch' the posts' posted-on date write Who can write a response to this post The real hard part of the command is the fact that <code> isn't MUSH code as you may expect; instead it is TCL code, and evaluates under the TCL interpreter. 'help @bbs/lock2' describes in more depth how to construct some good <code> that you can use to lock the BBS if you don't know TCL. If you don't provide <code> to lock to, it will unlock instead. See also: 'help @bbs' & @bbs/lock2 Continued from 'help @bbs/lock' If you don't know TCL and don't want to learn it to write code, there is a solution for you! All you need to know is that you should write MUSH code which would accomplish the lock you want, and then do these replacements on it: %# => #$player and then wrap it inside 'mushfunc "<your code here>"', so if you wanted to check for wizard or royal powers, you'd use: mushfunc "orflags(#$player,Wr)" If you're writing TCL code to put in as the lock code, all you need to know is that $player is the player's number (no # in front of it) who's trying to pass the lock. See also: 'help @bbs' & @bbs/move @bbs/move <post>=<dest> Owner/admin command that will relocate <post> and all of it's children from their current location to <dest>. To do so, you must be able to write to <dest> and delete <post>. Note that this does not change the date last modified of the post, simply moves it about in the BBS. It is a good solution to off-topic posts, allowing them to be moved somewhere where they are on topic. You cannot move post 0. See also: 'help @bbs' & @bbs/new & @bbs/read @bbs/new [<posts>] (additional alias: @bbs/read [<posts>]) Reads all unread posts who are children of (or are) <posts>. This allows a quick but spammy catchup of all the goings on in the bbs since you last read it. Note that if <posts> is unspecified, it defaults to post 0. See also: 'help @bbs' & @bbs/save @bbs/save Admin-only command that forces the bbs to dump it's database to disk; good to use in the case that you think you might crash the MUSH testing something, or if you are going to reload the tcl script -- if you reload the script without first dumping the bbs you will lose ALL MODIFICATIONS TO THE BBS BETWEEN THE LAST SAVE AND NOW. Saves are automatically done every time the MUSH dumps it's database, and at MUSH shutdown/reboot, so you don't need to worry about saving then. See also: 'help @bbs' & @bbs/scan @bbs/scan [<posts>] Reports the number of unread children of each post in <posts>. Note that if <posts> is unspecified, it defaults to post 0. See also: 'help @bbs' & @bbs/show @bbs/show @bbs/show gives information about the current reply, it's title, the post it is in reply to, and any text currently written for it. See also: 'help @bbs' & @bbs/stop & @bbs/quit @bbs/stop (additional alias: @bbs/quit) Terminates the current reply begin edited, discarding all information about it. See also: 'help @bbs' & @bbs/timeout @bbs/timeout [<posts>]=<timeout> Sets the timeout/expiration threshold of <posts> to be <timeout> days. All children of <posts> will now show up on @bbs/expire after <timeout> days, unless there is another timeout modification in the tree of posts. Note that the timeout value of a post is noted publically in it in @bbs <post>. Note that if <posts> is unspecified, it defaults to post 0. See also: 'help @bbs' & @bbs/title @bbs/title <title> Sets the title on the current reply to <title>. It does straight replacement, not appending as in @bbs/write. See also: 'help @bbs' & @bbs/touch @bbs/touch [<posts>] Touches <posts>, sparing them from the dreaded @bbs/expire list. Note this doesn't mean they won't be deleted if one of their parent posts expires and an admin deletes the parent post, it just keeps those specific <posts> off the to-expire list. Technically, @bbs/touch updates the date posted-on of the post; this does not force players to re-read your post, it only spares it from deletion. Note that if <posts> is unspecified, it defaults to post 0. See also: 'help @bbs' & @bbs/unlock @bbs/unlock <posts>/<lock> Unlocks <lock> on <posts>. The <posts> list can contain repeats, but it will simply cause the lock to be unlocked multiple times. The default locks available are: admin Who can use admin commands on the post read Who can see/read the post touch Who can 'touch' the posts' posted-on date write Who can write a response to this post See also: 'help @bbs' & @bbs/wipe @bbs/wipe Clears all text written into the current reply, as if you had stopped the reply and then started a new one with the same title. See also: 'help @bbs' & @bbs/write @bbs/write <text> Appends <text> onto the current reply. Note that <text> is not parsed, so if you're trying to '@bbs/write [v(text)]' you'll need to '@fo me={@bbs/write [v(text)]}' to get the [v(text)] evaluated before @bbs/write runs. After <text> has been appended, @bbs/write will echo the current post written so far. See also: 'help @bbs' & @bbs switch list @bbs[/<switch>] [<larg>][=<rarg>] Category Switch larg rarg ------------------------------------------------------------------ Admin BASEPOST text text Admin COLOR text text Admin COMPRESS Admin CONFIG text text Admin DEBUG Admin LOAD Admin SAVE Maintainence DELETE (CLEAR) [posts] Maintainence FIX [posts] Maintainence LOCK posts/lock [TCL code] Maintainence MOVE post post Maintainence UNLOCK posts/lock Editing BEGIN (POST) [post] [text] Editing EDIT text text Editing FINISH (POST) Editing SHOW Editing STOP (QUIT) Editing TITLE text Editing WIPE Editing WRITE text Sequencing CATCHUP [posts] Sequencing FORGET [posts] Sequencing IGNORE [posts] Sequencing NEW (READ) [posts] Sequencing SCAN [posts] Monitoring EXPIRE [posts] [time] Monitoring TIMEOUT [posts] time Monitoring TOUCH [posts] Info HELP Info INFO (VERSION)