Before we get to the serious code commands in 4.4, we need to get to some of the minor stuff on the 'help commands' list that we've missed.

Locks
So far, we've basically only described how to @lock yourself. If you're going to put code on objects, you'd better know how to @lock them so that nobody can walk away with them. Or, if it's a kind of object someone is SUPPOSED to walk away with, you should know the right lock for that too.

The format of the lock command is fairly straightforward. @lock (object)=(key) sets the default lock, which decides who can 'succeed' with something - picking it up, if it's an object or player, or going through it, if it's an exit. (Rooms have their own definition of 'success' which makes no sense and seems to be an artifact from MUSH 1.0.) There are other locks, such as EnterLock, which you set with @lock/enter (object)=(key).

It's not necessary to describe all the different kinds of locks, because they're all explained in the rather redundantly-named 'help @lock locks'. It's amazingly straightforward for a help file.

Anyway, the hard part is coming up with the (key). So far the only one that this guide has mentioned is me, which means you pass the lock, and nobody else does. A lock can also be a player name with an asterisk before it [this refers to the player no matter where they are, like a DB# does for an object (The asterisk is implied in commands like 'page' (nested parentheses are fun (until you have too many of them in your code)))], or the DB# of an object, or just the name of something that's in the same room as you. It doesn't matter which you use, they're all converted to DB#s internally.

If you just have the dbref/name/whatever alone without a symbol before it's a normal key - someone who either is that thing, or is carrying that thing, passes the lock. [So for '@lock me=me', theoretically an object that you're carrying could pick you up, except it can't because you're carrying it, so it can't carry you at the same time.]

There are other key types - the 'is' key (putting an = before the dbref/name/whatever) only works for things that ARE the thing the key refers to, the 'carry' key (putting a + before it) only works on things that are carrying the thing the key refers to, and the 'own' key (putting a $ before it) works on anything owned by the player that the key refers to.

You can separate two keys with |, which means that anyone passing either passes the lock, or &, meaning that anyone who passes BOTH keys passes the lock. Also, if you put ! before a key (including before the symbol for the key type, if it has one), then anyone who does NOT pass that key passes the lock. Examples:
To set yourself so that anyone carrying #2784 can pick you up: @lock me=$#2784
To stop Twinkazoid and everything he owns from going through a certain exit to the north: @lock north=!$*Twinkazoid
To stop any object from picking you up unless it has a DB# made entirely of threes and is also not owned by Twinkazoid: @lock me=(=#3|=#33|=#333|=#3333) & (!$*Twinkazoid)

Moving objects around
When you @create an object, you are holding it in your inventory. If it's an object like the "greeter" example I keep coming back to, you probably want to leave it in one place instead of carrying it around.

The first thing to do, of course, is @lock it! You don't want someone picking up your greeter and walking away with it. @lock greeter=me

So what you probably want to do, after locking it, is go to the room you want it in and drop it there. There, that wasn't too hard.

What if you want to move it to another room? You could, of course, pick it up, go to the next room, and drop it. But maybe you want the object to travel between rooms on its own. Here we can use a new form of @teleport: @tel (object)=(destination)

Instead of teleporting you, this code teleports the object to the room whose DB number you used as (destination). That wasn't too hard either.

There's one more thing you can do to make sure it stays put - set its home. In case something happens such as someone 'killing' the object, which is an expensive way for Joe Random Player to get someone else's object out of a room (this is very unlikely on SluggyMUX, considering how prohibitively expensive the kill command is - other MUXes may have it disabled completely), or some other unforseen circumstance, the object may decide to go home. So you set its home, the same way you set your own home. @link (object)=here in the room you want the object's home to be.

(You may notice that @link does different things in different situations - it sets the home for players and objects, it sets where an exit leads to, and it does various weird stuff on rooms.)

Finding lost stuff
Once you start building enough objects, you're bound to lose track of a few. If you know an object's DB#, there are many ways to get it back. Say that you know the object is #425 - you could type:

#425 @tel %#

This makes this object run the command '@tel %#', except that %# has already been replaced with your own DB# since you were the one causing the command to be run. The end result is that the object teleports from wherever it is into your inventory.

A similar situation might occur with rooms - you may have dug a bunch of rooms, linked them up so they weren't floating, and completely forgotten where they were. If you know the DB# of the room, you can @teleport into it.

There's two commands that will help you here - @find and @search. If you type '@find (name)', you will see a list of all the things you own with (name) as part of their name, and their DB#s. So if I left my bazooka lying around somewhere, I could type '@find bazooka' and find out about all the bazookas I own. Similarly, if I happen to have misplaced a room called 'Bobo's Junk Room', I could type '@find junk room' and see its DB#.

@search is a more powerful version of find. You can use it to look for objects with certain flags, or certain attributes, or whatever, and it shows you the locations of the things it finds as well. It has a more complicated syntax, though, and this isn't the place to describe it. You'll just have to type '@help @search'.

WARNING! If you're on another MUX besides SluggyMUX, these commands could cost you a lot of money. The MUX code used to use an extremely inefficient searching method to find stuff, and the entire MUX would lag for a bit while a @find or @search was going on. Thus, a player who uses one of these commands is charged $100 in MUX money. On MUX 2.0, @find and @search run in practically no time at all, yet the default is STILL for them to cost $100. SluggyMUX is more enlightened than that, and only charges $1 to use these commands.