Decompiling your MUSH Stuff:
Another quality MUSH tutorial brough to you from the makers of SPAM. Well, one of the many makers of SPAM, at least.
This Tutorial is Public Domain -- Feel free to Copy, Republish and Distribute Freely
The purpose of this tutorial is to help MUSH users save their own buildings and stuff offline. Relying on the God and Wizard staff of any MUSH to save your buildings for you is risky, and can result in you losing precious hours of code and building.
The process of saving your MUSH code offline and bring it back online is a three step process.
Sounds easy, doesn't it?
DISCLAIMER: Since every client and telnet system is different, how you make your text log file may vary. I will cover the two types of logging I know personally - TinyFugue and logging through a Telnet client off a SLIP/PPP line. This should cover most users, but for best results -
REFER TO YOUR TELNET CLIENT'S DOCUMENTATION FOR BEST INFORMATION ON HOW TO OPEN OR SEND A LOG FILE.
Font and Color Key to this Tutorial:
Things you can type are shown in preformatted text in red or bright red. There is no difference between things shown in red or bright red - I was just feeling colorful.
Things the MUSH will type as a result are shown in preformatted blue.
OPENING A LOG FILE
A log file is a text file (like you'd have on a word processor). When you're on a MUSH, and you open a log file, everythign you see in text on the game will be saved to the file.
Opening A Log File on Most Telnet Clients
On clients specific for MUSHes (TinyMUTT, etc), and on telnet clients like NetTerm, Ewan and others, you can open the log file with a command located in the menus. On Ewan, it's located in the File menu in the heading 'Open Capture File'. In Hyperterminal, which is shipped with Microsoft Windows '95, it's called 'Capture Text', located in the TRANSFER menu item. With programs like these, the capture file will place the text it sees onto your hard drive on your home computer.
Opening a Log File with TinyFuge
With TinyFugue, a unix MUSH client, logging is a bit easier. You just type:
If you type /suspend, and then type ls, you'll see your new log file in your unix file directory:
If you type %, you can return to your TinyFugue sesson.
First, it's handy to see an example of @decompile output to understand why it's so powerful.
Here's what I got when I decompiled my character on TinyCWRU:
If I was to log into a new MUSH, and I wanted to have all the same flags, locks and commands on me as I have on TinyCWRU, all I'd have to do is "play back" this recording of the commands it takes to make Kirra on TinyCWRU.
I have a basket object on TinyCWRU which I use to carry around junk I'm working on. I can decompile that, and if I want to remake my basket exactly as it is on TinyCWRU, I just have to play the recording of the @decompile back.
Here's what my basket's @decompile looks like:
Obviously, doing objects one at a time is difficult when you want to decompile tons of stuff quickly.
If you want to chug *every single thing* owned by a particular character all at once into a Decompiled form, the command you can use is:
@dolist [search(me)]=@decompile ##
(Tinyfugue users - be sure to type /more off to avoid having to hit TAB a zillion times.)
Every single thing that character owns will scroll by your screen in a wave of SPAM the likes of which you've
Once you've captured all the @decompiled information you want, you can close your logfile.
With Ewan Telnet, you just return to the File menu and select 'Close Capture File'.
With HyperTerminal, you return to the File Transfer menu and select the options under Capture Text again. You'll be able to Stop, Pause or Resume your capture from here.
With Tinyfugue, you just type /log off.
NOTE: If you have more than 100 objects, this simple @dolist [search(me)]=@decompile ## won't work! See Troubleshooting Decompile for more information
Notes about Logfiles:
You can edit your stuff offline with a word processor if you want to check for spelling errors or improve descriptions. Logging is also a great way to preserve records of your time on a mud - meetings, roleplaying sessions, code tests...anything.
Also, you can @decompile ANY object set 'Visual' (with a V after it's name) regardless of who owns it. This allows people to share code with each other. If you'd like to see some code, Kirra's Salvation Army on Living Fiction has some code items set Visual that you are welcome to copy and use for yourself. To reach here, type +Cr, 3, and KSA.
REBUILDING YOUR STUFF
Once you've got your @decompile files all set, and you want to rebuild, you need to figure out how to pipe a text file from your home system or Unix account back through your Telnet or MU* Client to the game. The text file is a recording of all the commands you'd need to type to remake your items, so you need to play it back from the character you'd like to use to own all the things you're remaking.
With Ewan and some other telnets, you may have to manually cut and paste each command from the file into the program. Ewan has a command called 'Show File' in the File menu, but it doesn't actually write that output to the mush as commands - it just displays the files.
With HyperTerminal, you can use the 'send a text file' option under the transfer menu.
With TinyMUTT and other MU* Specialty clients, you should consult your documentation. They undoubtedly have an easy way to pipe text back to the MUSH. They have an easy way to do just about anything with a MUSH, and I recommend them highly.
With TinyFugue, all you do is quote back your file. Example:
Note: It's \quote then ' then "<filename>"
You should see a message such as:
Process #1 started.
(There may be a few commands in the MUSH's queue after TinyFugue thinks it's done with the file. It's a good idea to type @ps to see if you still have commands waiting before you proceed with anything else.)
NOTES ON RECOMPILING ROOMS
Unfortunately, because all the Database Numbers for your newly recreated rooms will be different from their original ones, the @decompile command cannot @link exits to their proper destinations. It can open them where they belong in each room, but you'll need to manually go through after the recompile and link exits. Because an unlinked exit can be @chowned by anyone who finds it, it's a good idea to lock off the recompiled area until you've finished recreating it entirely.
On places without quotas, like Living Fiction, it's easy to run up more than 100 items. If you try to @decompile more than 100 things at a time, generally the MUSH will shut you down. This means you have to break the decompile into more manageable chunks.
To do this, you can @decompile your items by object type. There are four types of objects in a MUSH: Rooms, Exits, Things and Players.
So, to do a four part decompile, you can type:
@dolist [search(TYPE=Room)]=@decompile ##
@dolist [search(Type=Thing)]=@decompile ##
@dolist [search(type=Exit)]=@decompile ##
@dolist [search(type=Player)]=@decompile ##
But, I've found with some Living Fiction players, that even this is not enough. They can sometimes have more than 100 exits or rooms!
You can alter the above commands to search only a certain number of Database objects (like from Object #0 to Object #1000, etc.), and break down the search even further that way:
@dolist [search(type=Exit,0,10000)]=@decompile ##
@dolist [search(type=Exit,10001,20000)]=@decompile ##
@dolist [search(type=Exit,20001,30000)]=@decompile ##
The key is to do an @search me before you start, and *plan* your large scale decompiles carefully. If you know you have 150 items that are all numbered #200 up to #350, this is more than 100 items, and will cause the MUSH to stop your @decompile. Split that set up.
and text (c) 1996-2008 Dee Dreslough unless otherwise noted.