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:
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.
There are, however, two basic commands:
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.
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.|
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|
|Compound|| <key> & <key>|
<key> | <key>
( <key> )
There are some important characters to learn when you are dealing with locks.
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ບ 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.
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!
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.
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.
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.
Now, if I know my own dbref, I don't need the * in front. I can just write...
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.
- 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)
(It is worth noting that 'approved' is not a standard TinyMUX flag. This game has been configured to use it as one of the ten MARKER flags included with TinyMUX for custom adjustments.)
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.
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.
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.