Useful Macros and Properties

From Redwall MUCK Wiki
Revision as of 18:38, 19 November 2017 by Aeysin (talk | contribs)
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)

MPI Locking Macros

We use locks in the game to have the computer allow/disallow certain characters to use certain commands or pass through certain exits.

lock_to_species

This macro returns true only if the invoker's species is included in an lsedit-style list which is passed in as the argument.

An example usage is: +lock climb=action=&{lock_to_species:~lists/climbers}

Note that the following pre-defined lists are available:

  • ~lists/climbers -- those beasts which can climb well
  • ~lists/diggers -- those beasts which can dig well
  • ~lists/flyers -- those beasts which can fly (NOT just glide!)
  • ~lists/jumpers -- those beasts which can jump well
  • ~lists/swimmers -- those beasts which can swim well

Admin note: these lists are stored on $~env/ic, and as new species are added, they need to be kept current. Players, if you think an entry is missing from one of these, please notify a wizard! Thanks!

Build your own lists of species-names if you want using lsedit. One species name per line.

lock_to_name

This macro makes it easy to maintain an lsedit list of names of players or zombies that a lock allows.

Use this as an alternative to a long series of or-conditions. For instance, instead of doing this:

+lock door=*otter|*nicodemus|*vaticus|*rhys|*naco

Consider this:

lsedit door=who

otter

nicodemus

vaticus

rhys

naco

.end

+lock door=&{lock_to_name:who}

The advantage is this: when it comes time to add or remove a member, the list is easily updated with lsedit. The first version with the or-conditions requires re-entering every name from scratch. (Note the & at the beginning of the lock. This is required for locks that use MPI, the MUCK’s scripting language.)

If you have a skill-group for your names, you can lock with that quite easily by just:

+lock door=~skill_list/group-name:*

The down-side of +skill lists for this is that they have to join and be approved. You can't just add/remove members at whim.

You can also use a +list instead of an lsedit list, which has the advantage of being global. It also has the disadvantage of allowing people to know you've +listed them. They don't know why, but ... they know they are listed.

Useful Properties for Special Effects

Current Season

The current season is stored in a prop named ~season stored on $~env/ic. Thus, if your room is built in the IC area, you can always detect the season with @mpi {prop:~season}.

This means your MPI in your room descriptions can take season into account.

Name on the where list

The property wherename on a room controls the name that shows up in the "where" program for that room.

This lets you control how much information remote observation can show. Since where is considered OOC anyway, it would be perfectly fine to set all your rooms in your area to a wherename of "Hiding from where".

However, before you do that, keep in mind the where is also a great way to let people see that your group has lots going on.

A common use of this is to let the room name be very detailed, and the wherename be more generic. A wherename might be "A Pond in Mossflower Woods" but the room name might be "North Bank". Thus, people in the room see the detail that is useful, people on where get the idea without being bombarded. And an area that has many rooms would show everyone in all of them as being basically in the same place.

See Also