Variants of this description are generally found in help files on your local muck and in several other places, but I thought I'd go through it anyway, and do it a bit more thoroughly than usual.
First, you need an object. You can either use an existing one or create
one. In the following it is assumed that you call your zombie
"Zombie". (Hey, noone said you have to be original!)
If you want a different name, either substitute it for Zombie (or the
first couple of letters for zo) all the way, or call the object Zombie and
rename it after you're finished.
Note that except for when you create it you generally don't have to write
the name in full - "zo" will do just fine.
To create a zombie object just type
@create Zombie
You should get a message saying
Zombie created with the number
followed by a number (what else?). Write this number down.
If you already have an object, you still need its number. Still assuming
your object is called Zombie, type
ex zo
This should give you a screenful of information which you fortunately only need to bother with the first line of. It should look something like this:
Zombie (#1234) Owner: Your Name
The number will probably be a different one, and "Your Name"
should be your character's name. (You created it, so you own it. Funny
old world, isn't it?) Anyway, write down the number.
Note that you can get an object's number (and other data) any time with the
ex command, it's just convenient to do it right at the beginning.
Okay, you have the object, but so far it's just a plain run-off-the-mill object. Time to make it a puppet/zombie.
@set zo=X
@set zo=Z
@flock zo=me
These commands sets the object controllable, gives it "vision" (so it will report all it sees to you, with some limitations) and "force locks" it to you so it will only obey your commands. It's also a good idea to
@lock zo=me
This locks the zombie to you so only you can pick it up and carry it around. If you don't do this your zombie may end up in all kind of unexpected places. Then again, this may be what you want, in which case you should not lock it.
Okay, Zombie is theoretically controllable. Now how do you control it? How does the server know the difference between orders for your character and orders for the zombie? Simple: You use an action to "forward" orders to the zombie. (If you don't know what an action is, ask someone on your local muck, it's a bit too involved to get into here) The action will be used a lot, so it should have a short name that won't clash with others, so let's call it "z". Note: this has nothing to do with the Z you set above. An action can (and should) be called anything you want.)
@action z=me
This creates an action called z that is "attached" to your
character ("me").If you type "z" at this point you will
get an error message because the action has not been set up yet.
There are no less than three ways to make the action control your zombie,
two of which work everywhere. To take them in order:
@link z=$nothing
@succ z={force:#1234,{&arg}}
The first line links the action to a program that doesn't do anything. This
is just to make the action execute successfully and get rid of the error
message you got the first time.
The second line sets the action's "success" string to a little
bit of code that is executed when the action is successful. The number
1234 should be replaced with the one you wrote down in part one.
For the technically minded who have to know everything, what this code does
is send the action's argument - whatever you type after the action name -
to the zombie. If for instance you type
z look
it will send "look" to the zombie, and it will look at the room it's in and tell you what it sees.
@lock z=!me
@fail z={force:#1234,{&arg}}
The first line will lock the action against you (literally, "!me"
means "not me"), so it will always fail for you. (It may be a bit
confusing that a lock statement specifies who the action is not
locked for, but there you are...)
Most zombie building guides etc. will claim that you have to lock the
action for "me&!me" which means "me and not me"
(causing the action always to fail because neither you nor anyone else can
be you and not you at the same time!), but that is not strictly necessary
with an action attached to you. You are the only one who can get at it
anyway, so it doesn't matter if it is locked to others!
The second line is just like above, only it puts the code in the action's
"failure" string instead, meaning it will get executed when the
action fails. which it always does because you locked it.
Before I continue, a couple of reasons I prefer method 1 to this one.
First, it makes more sense to me to have an action do its thing by
succeeding rather than failing. Second, you will notice that the second
method does not link the action, which is generally not a good idea.
Actions should always be linked somewhere! And if you choose to link
the action to $nothing, you might as well use it...
This method is pretty different because it uses a program to control
Zombie. That's right, instead of using a program that does nothing it uses
a program that does something!
@link z=$zom-cont
Wow, three lines instead of two! The first links the action to the program,
the second sets a property on the action to inform the program which object
it controls (Note: Do not include the # symbol!), and the third runs the
program with the parameter "#setup" which sets up the zombie to
follow you around and take orders. You should get a message saying Zombie
will now follow you around. Move around a bit to check that it works, then
type
z #help
to see what other commands are available. In addition to sending ordinary
commands straight to the zombie you will find that you can also order it to
follow you around, stop following you (which is probably what most people
would want it to do at this point), summon it, send it home, turn its
output on and off, and my favourite: Go into Zombie Remote (zmot) mode
which enables you to play the zombie almost as a character, sending orders
traight to it without typing z and a space all the time.
A zombie/puppet can also be a "pet", that is an object that
follows you around automatically. With $zom-cont (see above) that function
is built into the program, on mucks that don't have it there may be other
separate programs for this. On FurryMuck any object can be turned into a
pet by typing
pmake zo
Once a pet, it can be turned on and off, summoned and sent home with a few
simple commands. Type
pet #help
for further details.
If you just have a plain zombie created by method 1 or 2, there's no
problem - just recycle the object and the action, and Bob's your uncle.
With program-controlled zombies and pets it's a bit more involved. The
#setup command set various properties both on you and your zombie, and they
don't go away just because you recycle the object!
preset
before recycling the object and the action. (preset stands for pet reset
and makes the object no longer a pet. Pmake stands for pet make)
@recycle zo
This recycles the zombie, then runs the #setup routine again, but this time
it will clean up after the recycled zombie rather than set it up. Once you
have done this (you may want to walk around a bit to check first) it's safe
to recycle the action.
What happens if you do it wrong? Well, here's something that happened on
(as far as I remember) SpinDizzy once:
For my next trick I will show you how to do zombie stuff without a zombie!
I have only tried this on Furry and not with $zom-cont, but that may just
work too...
First, don't bother making an object - this time you're going to play with
a character. Preferably an alt, but if you can find another player
willing to let you control his character that will work too. (It may,
however, violate the AUP or some other local rule, so check with a wizard
first!)
ex me
and write down his number as detailed in the first part above. (If they are
two different players Pinocchio must tell Geppetto his number.) Then
Pinocchio does this:
@flock me=gep
This force locks him to Geppetto and sets him controllable. Then all
Geppetto has to do is this:
@action pin=me
This simply creates an action called pin and sets it up to control #1234
(Pinocchio) using method 1 above. Note that there is no point in Pinocchio
setting himself Z - an object set Z (!) will report to its owner, and
Pinocchio's owner is Pinocchio, who already gets normal output when he's
online...
One advanced option in the $zom-cont program is to create a remote control
that will send output from the zombie to whoever is holding the remote.
It's quite possible that this will work with character zombies too...
Now for some more special tricks...
I did this as an experiment with a character who has three zombies. What if
you want to give the same orders to more than one zombie? Create an action
and set it up as in part 2.1 or 2.2, only set its @succ (or @fail) to
{force:#123,{&arg}}{force:#456,{&arg}}{force:#789,{&arg}}
where 123 is the number of your first zombie, 456 is the second and 789 is
the third. (This is for three zombies, you can do the same with just two or
four or more.)
What if you want to give others limited control of a zombie? Well,
an action doesn't have to send its argument to the zombie, it could just as
easily be a fixed string. For instance, I found that a friend of mine -
let's call her Jessie - liked to hug one of my zombies, so I gave her a
"hug button", which is just an object with an attached action
called "hugme", linked and set up as usual, with a success string
that originally looked like this:
{force:#1234,say Hello Jessie!}{force:#1234,hug jessie}
This would send two orders to the zombie, the first to say
"Hello Jessie!" and the other to hug her.
[Another thing I did early on was lock the action to Jessie and set a
failure line that says something like "Hey, you're not Jessie! What
are you doing with her button??"]
It may have struck you by now (WHAM!) that since the ordinary force
statements are generally imbedded in messages you don't have to use an
action to trigger them. You could for instance set a message on your
room that makes a zombie say "Good morning!" to you when you
connect, or a message on your door that tells your zombie to chastice
arrivals for entering without knocking...
The only argument I have heard in favour of method 2 is that it takes a
fraction of a second to load and execute the $nothing program. Personally I
think that if the Powers That Be were concerned about that, they would not
have installed the program in the first place!
2.3: The advanced method
More precisely, you use a program referred to as $zom-cont (for Zombie
control). If you are not on SpinDizzy, FuzzyLogic or FoxMuck your first
step is to make sure the program is available - either
"ex $zom-cont" or ask a wizard about it. If the program is not
available you have to either use one of the first two methods or start a
petition to get the program installed.
@set z=zombie:1234
z #setup
As you start experimenting you will also find that things have been set up
so that the zombie gets deactivated and stops following you when you pick
it up, and gets activated and starts following you when you drop it. (This
assumes that you don't change its @succ and @drop strings, because that is
where the program is called from!)
3: How to get followed by one
4: How to get rid of one
Actually I've never tried recycling a zombie, but with pets on FurryMuck
all you should need to do is type
With $zom-cont it's a bit more involved.
z #setup
@recycle zo
A player, let's call him Frank,
decided to make a zombie and followed the instructions until the zombie
started following him around. After a while he either got tired of the
whole experiment, or he got tired of getting followed around and hadn't
read enough of the instructions to know how to turn the pet function
off. In any case, before someone could tell him what he was supposed to do,
he had recycled both the zombie and the action - and then he found that
what appeared to be the ghost of the zombie was still following him
around! At least both he and the others received messages that the zombie
was following him, even though the object was nowhere to be seen. Spooky,
huh? Then something really weird happened. Another player, let's call him
Joe, tried making a zombie, and it worked fine.... only it was following
Frank around!
My guess is that the program does not bother to check if an object exists
and belongs to you once it is set up, so even though Frank's zombie did not
exist any more, he still had a setting on his character that said
"when I move, run $zom-cont to make object X follow me". So even
though the object did not exist, the program still gave the messages. And
when Joe made his zombie right after Frank recycled his, it got the same
number as the old object, and the program didn't bother to check who owned
it but moved it anyway.
5: How to become one!
Okay, you have two characters, let's call them Geppetto and Pinocchio. As
you may guess, Gepetto wants to control Pinocchio, and Pinocchio either
trusts Geppetto or is his alt (in which case the trust is implicit.). First
you need Pinocchio's db number, so let him type
@set me=x
@link pin=$nothing
@succ pin={force:#1234,{&arg}}
6: How to annoy the h*** out of someone
This action wil now send &arg to ALL your zombies, causing them to do
the same thing almost simultaneously. Be very careful about this - it gets
spammy very fast and can be really annoying (which explains the heading!)
7: Limited control for others
Jessie assumed ownership of the button, but the action remained mine (a
necessity beause the zombie is still force locked to me, so it can only be
controlled by actions I own), so after a while I decided to modify the
action a bit. At first I would just change the hug verb and what the zombie
said, then I got more advanced...
8: Control without actions