Stupid Zombie tricks

1: How to make one

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.

2: How to make it work

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:

2.1: The "success" method

@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.

2.2: The "failure" method

@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...
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

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!
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.

@link z=$zom-cont
@set z=zombie:1234
z #setup

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.
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

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.

4: How to get rid of one

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!
Actually I've never tried recycling a zombie, but with pets on FurryMuck all you should need to do is type

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)
With $zom-cont it's a bit more involved.

@recycle zo
z #setup
@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:
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!

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!)
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

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
@set me=x

This force locks him to Geppetto and sets him controllable. Then all Geppetto has to do is this:

@action pin=me
@link pin=$nothing
@succ pin={force:#1234,{&arg}}

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...

6: How to annoy the h*** out of someone

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.)
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

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.
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...

[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??"]

8: Control without actions

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...


© 2000 by Ragnar Fyri. All rights reserved.