-------------------------------------------------------------------------------
                           MACROPHILE/MICROPHILE HOWTO
-------------------------------------------------------------------------------
 
Voregotten Realm offers a few aids for macrophile/microphile RPs !   :-)
 
The macrophile.muf program implements a set of three commands which give the
opportunity to affect the environment and the interactions with the objects (in
the largest acceptation of the term, from "things" to "players") of the MUCK.
 
Didn't you dream of being able to setup areas or create objects that only
macros or micros would be able to use, depending on their size ?  Didn't you,
as a macro-fur, longed for being able to stomp down entire areas of a MUCK and
show your strength to the small ones ?  Wanna squish someone, or be squished ?
Well, all the above can be achieved with just three commands. Here they are:
 
1.- The 'size' command:
 
This one allows to perform two different things. First, it entitles you to set
your vital statistics and to check for the ones of the other characters.
 
Let's say you are Herman, a macro-wolf (anthro), 100 feet tall... and type:
  size #set height=100'       (or 100ft)
Now, you can check for your size:
  size me
will print:
Character________Weight_________Height_________Length_________Width__________
Herman            -              30.5m          -              -
 
Yep, that's right, macrophile.muf uses the metric system, and so should you be
doing. :-P
 
Now, let's calculate your weight and set it... Let's see... At 1.80m, a strong
man weights around 80kg... 30.5m is almost 17 times taller, so the weight
should be 80 x 17^3 (yes, the volume increases as the cubic power of the size,
and so does the weight...). That's 393040kg... Let's say 390 metric tons
(yeah, that's quite a weight... When do you start your diet ?). Just set it:
  size #set weight=390t
and let's check with 'size me', which returns:
Character________Weight_________Height_________Length_________Width__________
Herman           390t           30.5m          -              -
 
You could set the length and width parameters in the same way, but for an
anthro they are rather irrelevant... Of course, for a non-anthro snake you
would like to set the length instead of the height, and a taur would better
have to set all of the three dimensions (a taur would find it difficult to pass
through a small door, for example, while an anthro would manage to bend or step
latterally to pass through the door).
It is however recommended that at least the weight and one of the three other
dimensions are set. You will see later why...
 
If you want to check for the size of all the characters (players and puppets)
in the room, just type 'size' without parameter. Should I be in your only
company, you will get (beside a worried angel-boy):
Character________Weight_________Height_________Length_________Width__________
Herman           390t           30.5m          -              -
Henri            45.0kg         1.57m          -              -
 
You may even check for a <player>'s size from afar with 'size *<player>'
(it works only with players, not with zombies), or of all connected players,
with 'size #all'.
 
Note that the 'morph' command does save your vital statistics together with the
other properties of your character, so a 'morph #update' will update your
current morph with the statistics you just entered...
 
Now, let's see what is the second use for 'size': it's to create size locks. It
means that you will be able to lock objects and exits/actions so that only the
folks with the right size may use them !  Here is how to do that:
 
Let's say that John built a house. John is your average and boring human, and
as such, he built a house in which humans can enter, as well as any creature
around his size... The house got a door (and to make it very original, the MUCK
exit for the door will be called... "door"... doh !... what an impressive
creativity effort...).
So, let's define who can pass through that door... Hmm... The door is 2.20m
tall and 1m wide... Anyone taller than 4m would find it very difficult to pass
through it, and anyone wider than the door would not pass through either (but
perhaps for anthros as they might step sideway through it, but they won't set a
width, as it is irrevelant in most cases). Let's explain this to the MUCK:
  size #max door=height:4m
  size #max door=width:1m
Of course, we could as well set #min values... Should the door have stairs in
front of it, anyone smaller than half the height of a step (let's say 6" for the
height of each step) would be unable to climb the stairs, even by jumping... So,
for this case, let's add:
  size #min door=height:3in
  size #min door=length:7"   (a snake would have to be a bit longer than the
                              step is high...)
 
Looks good... Let's activate the lock:
  size #lock door
(to remove that lock, just use the classical '@unlock' command)
 
Now, Herman can't pass any more through John's door... :-P  Note that the size
lock parameters of the door are only checked against the character's statistics
whenever the latter are set (so someone without a "length" or "width" set will
still be able to pass through the above door).
 
Of course, Herman is not very happy... The big guy is even angry and wants to
stomp down John's house, and perhaps even to squish down John himself !
 
Hey, no problem, Herman... There is precisely another command which name is...
surprise, surprise... 'stomp' !
 
 
2.- The 'stomp' command:
 
OK, let's see... For obvious reasons, you can't stomp everything: the owner of
the object must first set it up so that it is "stompable" and, in the case of
characters, the said characters' players will have to agree OOCly to be stomped
by you... Let's first deal with inanimate objects. Here is how to set them up:
 
John's house may be either described in the @desc of the room in which the
"door" exit is, or the description may be set on the "door" exit itself... or
John could use an object named "John's house", put the description of the house
in the @desc of the object, and drop the object into the room where the "door"
exit is...
All three methods have advantages and inconvenients:
- The first would be better used for outdoor areas in which, for example, a
micro-city would be described: 'stomp here' would then allow a macro to destroy
the micro-city and, as we will see later, the damages to the city could appear
in the description of the room itself, making them obvious for everyone
entering it.
- The second method is probably the best in most cases, or at least when an
exit leading to a stompable building already exists: it allows to have several
such stompable buildings in the same room (unlike the first method) without
having to create more objects like in the third method. Of course, to see the
damages, you would have to either add some MPI in the @desc of the room (it
implies that you are the owner of the room as well as of the exits), or to at
least put some clues in it so that people entering the room know that they can
look at the exits to see the damages.
- The third method is better used when the stompable object is a "dummy" one,
i.e. does not allow any other interaction. For example, in a room representing
a normal city, we could put a "cars" object to represent the cars in the
streets: this object could then be stomped upon by macros, but it would not be
meant for any other purpose (e.g. it would not be a vehicle object). This
method yet consumes more space in the database than the others, in which we use
an already existing object (either the room itself or one of its exits).
 
Of course you may as well mix up the three above methods (e.g. in an outdoor
area with a micro-city, an isolated, normal sized house to which an exit of the
room leads, and a highway with cars on it, represented by a dummy object).
 
For the examples used hereafter, we will adopt the exit solution. Should you
choose to use the room itself, you would have to replace the "door" parameter
in our examples with "here", and should you choose to create a "John's house"
object, you would have to give this name instead of "door".
 
Yet, before we start, it would be better if other aliases were added to the
"door" exit, such as:
  @name door=John's house [door];John's house;door
in which case the exit will appear as "John's house [door]" in the list of the
room exits (indicating that "door" is the shortcut to use in order to enter
John's house) while it will also be possible to 'stomp John's house' instead
of the less obvious and less realistic 'stomp door'...
 
To be "stompable", any object (and this includes characters) must have at least
two parameters set on it: the first one tells how big the "stomper" must be in
order to be able to damage the object by stomping on it. The second parameter
tells how much damages would result from a stomping by the said stomper (i.e.
by the smallest stomper). Let's give an example for clarity: John's house is
your average house for humans. It got only a ground floor and the top of its
roof is 10m above the ground... Anyone as tall or taller than the house is high
will be able to inflict significant damages to it. Let's explain this to the
MUCK (still keeping our "door" exit as an example):
  stomp #min door=size:10m
Now, the MUCK knows that anyone taller, longer, or wider than 10m will be able
to damage the house... We could also set a minimum mass (it's sometimes more
relevant, depending on what the object is), for example:
  stomp #min door=mass:50t
which means that anyone with a weight of 50t or more will be able to damage
the house. Note that when both the minimum size and minimum mass are set, the
comparison with the stomper succeeds if either of the stomper size or mass is
larger (i.e., someone 8m tall but weighting 60t will be able to 'stomp' the
house).
The second parameter, the stomp rate, tells how much damages (in percents) the
house will take when someone 10m high/long/wide or 50t heavy stomps down on
it. The bigger the stomper, the more damages will be done to the house (i.e.
someone twice as big as the minimum size will do twice the damages to the
house). Example:
  stomp #rate door=10
Which means that someone 10m or 50t big will damage the house by 10% at each
'stomp'. Someone either 20m tall or 100t heavy will damage at twice that rate
(20%), etc...
 
OK, cool... Herman can now destroy completely John's house in just two
'stomp's... Yes, but how can we "see" this happening, and how one would be able
to know what happened to the house once Herman is gone ?... Well, for a start,
'stomp' will issue a message each time Herman 'stomp John's house'... this
message may be configured by John with (still with our "John's house;door" exit
example):
  stomp #succ door=stomps down on what was John's pretty house... How mean !
which will give:
  Herman stomps down on what was John's pretty house... How mean !
whenever Herman types 'stomp John's house'...
The second, more exciting feature is that the house description can be made to
reflect the damages it endured so far. Example (note: the text prefixed with
"> " is the reply of the MUCK server):
  stomp #desc door
  > You will now be presented with the line editor in order to edit the damages
  > descriptions for <objet>. Each line represents one description, and each
  > description will be used in turn, depending on the amount of damages the
  > object will have endured. For example, if you enter 5 descriptions (5
  > lines), the first will be used when the object is undamaged, the second
  > when it got 1-25% of damages, the third for 26-50%, the fourth for 51-75%,
  > and the last for 76-100%.
  >
  > < Entering editor. Type '.h' on a line by itself for help.  >
  > < '.end' will exit the editor. '.abort' aborts the edit. To >
  > < start a line with a '.' just start it with '..' instead.  >
  > < Insert at line 1 >
  The house is pretty and well kept.
  It looks like the roof of the house endured some damages...
  The roof is destroyed, the door broken, the walls half shattered.
  The house is alas nothing but a ruin, now...
  .end
  > < Editor exited. >
  >
  > Done.
 
Now, whenever someone stomps on the house, the cumulative amount of damages
will determine which line to use in order to set the _details/damages property
on the house. Reflecting the damages in the description of John's house is
therefore a breeze, and may be achieved with something like:
  @desc door=This is John's house. {prop:_details/damages}
and 'look John's house' will report any damage after the constant part of the
description (example: "This is John's house. It looks like the roof of the
house endured some damages...").
 
But there is even more to it... In the case where the stomped <object> is an
exit (which is the case in our example) leading into another room (here,
Jonh's house), then:
- For a start, the characters (players and zombies) standing inside that room
will be notified when someone stomps on it (actually on the exit) outside.
In the case of Herman above, someone inside John's house would see:
"Outside, someone stomps down on what was John's pretty house... How mean !"
- It is also possible to set a default reaction for all the occupants of the
room, triggered when the damages reach 100%. You could perhaps make everyone
exit the house (taking an "out" exit in the room). This would be achieved
with:
  stomp #reaction door=out
Note that the reaction parameter (right member after the "=") may only
designate an action/exit which is set on the room to which the stompable exit
leads (this is to avoid abuses via the use of global commands).
- Once 100% damaged, and provided it was size-locked, the exit is locked
against anyone trying to use it, till it gets "fixed" (see chapter 3).
 
Finally, 'stomp <object>' works a bit differently when <object> is a
character (player or zombie). While you still need to set the #min and #rate
parameters, the #succ message is rather poor a way of describing all what
could happen to a victim when it is stomped upon by a macro, and the predefined
#desc does not make it much fun for the involved parties either (#succ and
#desc are yet still usable with character objects).
It is therefore possible for the stomper to describe what is the result of
their action in term of damages. The description may either replace any
previously described damages, or be added to them.
Moreover, and in order to respect the OOC consent principle, the victim must
consent to the stomp action and is presented with the damages it would result
into. Here is an example of a stomping session, between big Herman and poor
John:
 
  Herman (simple stomp with predefined damages, if any #desc was set):
  stomp John
  > You try and stomp down on John. An OOC request for agreement was sent to
  > his player.
 
  John:
  > Herman tries to stomp you down - Type 'stomp #ok' to accept or 'stomp #no'
  > to refuse and escape.
  stomp #ok
 
  Seen by everyone (if no #succ was set on John):
  > Herman stomps down on John.
 
  Herman (let's get meaner...):
  stomp John=The poor human got his legs crushed down.
  > You try and stomp down on John. An OOC request for agreement was sent to
  > his player.
 
  John:
  > Herman tries to stomp you down, attempting to achieve the following
  > damages: The poor human got his legs crushed down. - Type 'stomp #ok' to
  > accept or 'stomp #no' to refuse and escape.
  stomp #ok
 
  Seen by everyone:
  > Herman stomps down on John. The poor human got his legs crushed down.
  lookat John's damages
  > The poor human got his legs crushed down.
 
  Herman:
  stomp John=+His arms have been reduced to a pulp as well.
  > You try and stomp down on John. An OOC request for agreement was sent to
  > his player.
 
  John (the player does not agree here):
  > Herman tries to stomp you down, attempting to achieve the following
  > damages: +His arms have been reduced to a pulp as well. - Type 'stomp #ok'
  > to accept or 'stomp #no' to refuse and escape.
  stomp #no
  > You escape the attack.
 
  Seen by Herman:
  > John escapes in time to avoid being stomped down by you.
 
  Herman (new attempt, with less visible damages):
  stomp John=+His left arm has been reduced to a pulp as well.
  > You try and stomp down on John. An OOC request for agreement was sent to
  > his player.
 
  John:
  > Herman tries to stomp you down, attempting to achieve the following
  > damages: +His left arm has been reduced to a pulp as well. - Type 'stomp
  > #ok' to accept or 'stomp #no' to refuse and escape.
  stomp #ok
 
  Seen by everyone:
  > Herman stomps down on John. His left arm has been reduced to a pulp as
  > well.
  lookat John's damages
  > The poor human got his legs crushed down. His left arm has been reduced to
  > a pulp as well.
 
Of course, just like for what we did with John's house description, John may
perfectly add a {prop:_details/damages} MPI command in his @desc so that any
damage appears in it.
 
Well... Now that Herman squished everything and everyone, it would be time to
repair the damages... The third command implemented by macrophile.muf is 'fix'
and allows to perform such a repairing.
 
 
3.- The 'fix' command:
 
Let's first take care of poor John... In fact, John can take care of himself
and simply has to type 'fix me' (you now see why he refused to have his right
arm crushed... He needed it to type the command !  :-P)
This command immediately repairs any and all damages on a player or zombie.
 
The objects are another matter... To make it fun and as realistic as possible,
there are several factors to take into account:
- first, anyone may try and 'fix' a damaged <object>, regardless of who is its
  owner.
- second, not anyone will manage to fix a given object: just like you must be
  strong enough to damage something, you must also be agile enough to repair
  it (with his big fingers, a 100ft tall macro would be too clumsy to repair
  properly a small human house...).
- the repair rate per 'fix' is determined by the size of the one doing the
  repair (it's only logical that a 1" tall micro can't repair as fast as a
  normal human).
 
To make an object "fixable", you therefore need to set the #max and #rate
parameters. In our example, let's define these parameters for John's house:
  fix #max door=size:4m
  fix #max door=mass:1t
  fix #rate door=20
Which means someone bigger than 4 meters or heavier than 1 ton would be
unable to properly repair the house, and that at this maximum size, they
would repair at a rate of 20% per 'fix'.
 
Like for 'stomp', you may define a #succ message for 'fix'. Example:
  fix #succ door=helps repairing John's house.
 
There is yet another feature exclusive to 'fix'. It is meant to simulate a
repair by the "little ones" over time, and can be set as a number of percents
per hour (each hour, macrophile.muf will update all auto-repair objects and
reduce their damages by that amount). Let's say that John, unable to fix his
house fast enough alone, hired the services of a repair company. We could use:
  fix #auto door=5
which would result in a decrease of 5% of damages per hour.
 
Should you want to disable the auto-repairing later, you could use:
  fix #auto door=0
 
 
This ends our tutorial on macrophile.muf. For a full syntax of the commands,
simply type:
  size #help
  stomp #help
  fix #help
   
I hope you will have fun with this program !  :-)