Useful Macros and Properties
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.
