SolSyS

"Dyle's MUD Manual"



1st page: badic command vocabulary
2nd page: locks and beyond
3rd page: groups, flags, etc.
please report disfunctional links


Topic: Lock

Locks are powerful (but somewhat complicated) tools. Exits and groups can be locked to and from players and other groups, visibility and accessibility can be restricted or expanded, or various combinations of conditions can be arranged. For specific help with locks, see the following files:

see also: locks, @lock, logic, operators, @hint, @warn

Topic: Operators

Operators used In locks:

& means AND @lock gate = key & passport means BOTH are necessary.
| means OR @lock gate = Key | Passport means one of them is enough.
! means NOT @lock gate = !gun means that you can't pass with a gun.
( ) declares precedence @lock Gate=(key|passport)&!gun means a key, or a passport (or both) as long as there's no gun.
: means MEMBER_OF @lock gate = passport:+stamped_by_immigration means that passport has to be a member of group +stamped_by_immigration.
; splits command phrases doh

 

see also: @lock, lock, locks, @effect, logic

Topic: Locks

Boolean operations are allowed. Recognized operators are:

& | ! (   ) : ;
AND OR NOT PRECEDENCE MEMBERSHIP SPLITTER

 

For example to restrict use of an exit to people carrying the Red Key, type: @LOCK Door=Red Key

If you want to create a complex set of criteria for using an exit, you can use boolean operators, for example:

@LOCK Door=Red Key | +Door_breakers & !+Done_quest | me

Which means only people with the red key, OR those that have been added to the group of +Door_breakers and haven't yet been added to the group +Done_quest, or yourself can pass through the door.

AND has higher precedence than OR, but when in doubt, use parenthesis, ie: @lock THING=(A|B) & (C|D)

see also: @lock, @succ, @fail, logic, operators, using, @hint, @warn

@lock

Boolean operations are allowed. Recognized operators are:

& | ! (   ) : ;
AND OR NOT PRECEDENCE MEMBERSHIP SPLITTER

 

For example to restrict use of an exit to people carrying the Red Key, type: @LOCK Door=Red Key
If you want to create a complex set of criteria for using an exit, you can use boolean operators, for example: @LOCK Door=Red Key | +Door_breakers & !+Done_quest | me
... Which means only people with the red key, OR those that have been added to the group of +Door_breakers and haven't yet been added to the group +Done_quest, or yourself can pass through the door.
AND has higher precedence than OR, but when in doubt, use parenthesis, ie: @lock THING=(A|B) & (C|D)

see also: @lock, @succ, @fail, logic, operators, using, @hint, @warn

Topic: Logic

Lock building can be tricky. Here are some transformational rules you can follow to try to word locks more concisely.

!Key & !Axe (---) !(key|axe) (can't have either one) !key | !axe (---) !(key&axe) (can have none, one, but not both) !dog&key | !dog&axe (--) !dog&(key|axe)
      Be careful: !dog|key & !dog|axe is the same as: !dog | (key & !dog) | axe NOT the same as: (!dog | key) & (!dog | axe) (!dog|key) & (!dog|axe) (---) !dog | (key & axe)

see also: @lock, locks, operators, @LOCK

@EFFect (exit)[= (Add|Remove|Toggle) ((group)) [:(target)]],
... or @EFFect (exit) = Delete (Effect Number) Causes an (exit) to Add, Remove or Toggle a group on the player using the exit by default, or on a specified (target).
Several effects can be associated with an exit. @EFFECT (exit) by itself will display an exit's existing effects.
The ":" operator can be used in locks to verify that (target) is a member of (group).

see also: @add , @lock , @remove, groups, membership, operators, targets, toggle

Topic: Membership Locks

Membership is checked in locks with the : operator, and set by applying @EFFECTS to exits. When checking for lack of membership the syntax should be: !x:y implies something, not X, is a member of Y, x:!y implies X is a member of something that isn't Y. both are meaningless things to test for. !(x:y) is the correct way to check if X is not a member of Y.

see also: locks, logic, operators, @effects

 

Jopsy says:

Jopsy says "for your room: set one of the entrances STICKY."
Jopsy says "@LOCK the room itself to that entrance. ie: @LOCK HERE = #432 (where #432 = the entrance in question)"
Jopsy says "Then @SUCC here = What you would see if you used entrance #432."
Jopsy says "and: @FAIL here = What you would see using the OTHER entrance."
Jopsy says "and then for each exit in the room do this: @EFFECT exit = remove #432"
Jopsy says "(so if they come back by the other exit, it won't show them the wrong thing)"

 

    *

Dyle poses a problem of, "two rooms, with an 'open wall' (whatewver THAT means) between them, separating them"
Jopsy says "well, make the center of the level one room, and the perimeter another room."
Jopsy says "and then @ADD room1 = room2"
Jopsy says "if the perimiter is #75 and you're in the center... type @ADD HERE = #75"
Jopsy says "it connects the two rooms making them act more like one big room with multiple areas."

 

 

(object) = (first-key) ; (second-key) ; (third-key)

see also: lock, locks, logic, membership, operators, @hint, @warn

Topic: Control

There are 7 rules governing the control of objects:

Flag: COPY

The COPY flag turns (things) into non-unique "copy objects". A copy object is exactly like a group except it appears in "contents" instead of on the "[ Titles and Memberships: ]" line. You can GET or DROP copy objects, AND, you can use exits to give and take copy objects, just like you would have them add and remove normal groups. Copy objects can have multiple homes as well as multiple carriers. @ADD HERE = +Copy Object, will add HERE to its list of HOMES. @add me = +Copy object, will give yourself a copy at any time, unless you are otherwise unable to pick up the copy object. @link Copy Object = here, usually works. Copy objects must have unique names.

see also: @set, groups


1st page: badic command vocabulary
2nd page: locks and beyond
3rd page: groups, flags, etc.
please report disfunctional links

GLOSSARY

sticky
copy
drop-to
homes
sacrifice
owner-group
@toad
flags

Connectivity     ||     MUD Tutorial     ||     MOO Resources
EduMU*s     ||     MU* Research

SolSyS
SolSyS FAQ     ||     Guide to Teams     ||     Adjunct Faculty

last updated 03.02.01

This page is maintained by:
Reed D. Riner
Prof / Anthro
Northern Arizona University
Flagstaff -- on Rt66

  email: Reed.Riner@NAU.edu