TinyMUX Locks

Locking Things in TinyMUX

There are a LOT of different ways you can lock things in the TinyMUX game system.

What Can I Lock? Players can lock anything they own. This includes: Your characters Your rooms Your exits Your items This is because all of them are technically "objects" as far as code is concerned. Some locks will only work on certain types of objects. See the table below.

Basic Commands

There are, however, two basic commands:

• @lock
• @unlock

@lock

This command locks something in a specific way.

@lock[/<type of lock>] <object>=<key>
@lock <object>/<attrib>

By default, @locking something will stop everyone from going through it. This includes you.

@unlock

This command unlocks something in a specific way.

@unlock[/<type of lock>] <object>=<key>
@unlock <object>/<attrib>

By default, @unlocking something will allow ANYTHING and ANYONE to go through it. The lock you had set on it is completely wiped.

You can find these in game via 'help @lock' and 'help @unlock' respectively.

Types of Locks

You can see the information below by checking the IG helpfile 'help @lock locks' to find the various locks you can set with @lock.

Defaultlock	Exits:	controls who may traverse the exit to its destination.
	Rooms:	controls whether the player sees the SUCC or FAIL message for the room following the room description when looking at the room.
	Players/Things:	controls who may GET the object.
Enterlock	Players/Things:	controls who may ENTER the object if the object is ENTER_OK. Also, the enter lock of an object being used as a Zone Master Object determines control of that zone.
GetFromlock	All but Exits:	controls who may gets things from a given location.
Givelock	Players/Things:	controls who may GIVE the object.
Leavelock	Players/Things:	controls who may LEAVE the object.
Linklock	All but Exits:	controls who may @LINK to the location if the location is LINK_OK (for linking exits or setting drop-tos) or ABODE (for setting homes)
Maillock	Players:	controls who may @mail the player.
Openlock	All but Exits:	controls who may @OPEN an exit.
Pagelock	Players:	controls who may PAGE you.
Parentlock	All:	controls who may make @parent links to the object.
Receivelock	Players/Things:	controls who may give things to the object.
SpeechLock	All but Exits:	controls who may speak in that location (only checked if AUDITORIUM flag is set on that location)
TeloutLock	All but Exits:	controls who may teleport out of the location.
TportLock	Rooms/Things:	controls who may teleport there if the location is JUMP_OK.
UseLock	All but Exits:	controls who may USE the object, GIVE the object money and have the PAY attributes run, have their messages heard and possibly acted on by LISTEN and AxHEAR, and invoke $-commands stored on the object.
DropLock	All but rooms:	controls who may drop that object.
VisibleLock	All:	Controls object visibility when the object is not dark and the looker passes the lock. In DARK locations, the object must also be set LIGHT and the viewer must pass the VisibleLock.

Lock Keys

The true flexibility of locks comes in the number and variety of keys you can use for them.

Since the average player will likely never need anything more complicated than a list of other players or, say, motleymates who know the secret password, we are going to skip over almost all of that lovely variety and only focus on what people will actually be using.

If you want to read more about it, check 'help @lock keys' IG, or the table below. The <object> is the *Name or #dbref of the person/item being used as a key.

Key Type	What to Type in @Lock Command
Normal	<object>
Is	=<object>
Carry	+<object>
Ownership	$<object>
Indirect	@<object>
Attribute	<attribute>:<wildcard-pattern> +<attribute>:<wildcard-pattern> =<attribute>:<wildcard-pattern>
Evaluation	<attribute>/<value>
Compound	<key> & <key> <key> | <key> !<key> ( <key> )

Special Characters

There are some important characters to learn when you are dealing with locks.

Ampersand This is the '&' symbol. It means 'and' in code. If you use it in a list of items on a lock, the code will expect all of those items to be going through the lock at the same time. This means that something like @lock #42=*Derek&*Chad would be an impossible lock. You can't have both you AND Chad going through at the same time. If you had a Key(#3738) object, and wanted to create a lock which you could only walk through if you were holding Key, you could write @lock #42=*Derek&#3738 and thenceforth you could only pass the lock if you had the Key in your inventory. That kind of locking is most often done on MUDs and the like, not MUSHes/MUXes like ours, since MU*s of our variety tend to be a bit more loosey goosey and imaginary.

Pipe This is the '|' symbol. It means 'or' in code. If you use it in a list of items on a lock, the lock will accept ANY of that list of items as a valid key. This is the symbol you use when you want multiple players to be able to access something. Bob OR Sally OR Derek OR Chad are all able to get into my house. You can have fun and make locks a bit more complicated with this one! I own a magical place. My name is Coconut. I can get in because I'm special, but my friend Jeanette can only get in if she's holding a Magic Crystal(#1111). @lock EXIT=*Coconut|(*Jeanette&#1111) See the ( ) around Jeanette and #1111? That tells the code that they are one key, so to speak. The lock looks for Coconut OR Jeanette-and-#1111.

Exclamation Mark This is the '!' symbol. It means 'not' in code. You use this if you specifically do NOT want a certain person or object ever being able to pass your exit. @lock EXIT=!*Chad would keep Chad from walking through into my coffee shop, but everyone else could get through just fine.

Examples of Locks

If this is still confusing, no worries. Here are some examples of what the locking code looks like in action, to try and take the scary out.

Exits

In this section, I will present a scenario in bold text and follow it with the lock code which would accomplish that scenario.

The exit's DBREF is going to be #1234 and its name is Exit <EX>. Its alias is ex (so you don't have to type Exit <EX> every time you want to walk through it).

My character's name is Cupcake. Cupcake's DBREF is #5678.

I will be using its dbref in the examples below, because it is always safest to work with the dbref of an object, in case there are multiple objects nearby with similar names.

• I want to be the only person who can go through my exit.

@lock #1234=*Cupcake

Now, if I know my own dbref, I don't need the * in front. I can just write...

@lock #1234=#5678

The asterisk tells the code that the letters following it are a player's name, and it should look for a PLAYER object in the database named Cupcake.

• I want only yours truly and my friend Sally to be able to get into my secret clubhouse.

@lock #1234=*Cupcake|*Sally

• I want to lock an exit so only approved players can get through it.

This uses the "evaluation" key type. The key will be set to APPROVAL/1, so when someone attempts to go through the exit, the exit will run the code in the APPROVAL attribute. If the code does not return a 1, that person will not be allowed through.

@lock #1234=APPROVAL/1
&APPROVAL #1234=hasflag(%#,approved)

Objects

Same text as above! My imaginary name is still Cupcake. My Object is #99.

• I have a logging object, but I don't want anyone else to be able to pick it up while I'm logging a scene with it.

@lock #99=*Cupcake

Pages

Same text as above! My imaginary name is still Cupcake, but since I'm locking myself, I can just use 'me' instead of my name.

• So, Dirk the Skinflayer has been harassing me via pages, and I can't get him to stop. I want to block him from reaching me that way.

@lock/pagelock me=!*Dirk

Rooms

My name is still Cupcake! My imaginary room is called My Imaginary Room(#5555), but since I'm standing in it, I can just use 'here' instead of its name or dbref.

• I @set here=jump_ok so my friends Sally, Pink and Charles could have a custom command to @tel into my space, but I don't want EVERYone to be able to do it.

@lock/tportlock here=*Cupcake|*Sally|*Pink|*Charles