Rescueing Lost props

A guide to how props work and what you can do to rescues them, first published on the Finchnest Palace website by Dr. X. A few simple facts explained and the simple truth about props. This guide is a must read for anyone who loves his or her props and wants to enjoy them for as long as possible.

There are few facts of Palace life more frustrating than the absolute certainty that somehow, some time, you are going to lose all of your props. It will happen. You can get them back.

There are a few different ways you can get them back, and we're going to take a swipe at them all.

 

• Backing up the .prp file
• Parasitizing your friends as living hosts
• Using your own server as a "bank"
• Using someone else's server as a "bank"
• Keeping the original images

The .prps Yours, Your Pals', & the Mother of All .Prps

The image at right gives you an overview of how the Palace handles props. Each of the green circles represents an individual user, and user has their own prop file (the rectangle), called "Palace.prp" on their own computer the central server (i.e., the palace itself: The Palace Inc., Cybertown, Finchy's, or your own personal server) also has its own prop file, called "PServer.prp," that resides on the server computer.

Each time that a user changes or displays props, the following chain of events occurs:

1. Their client program tells itself to change props.
2. It tells the server to change props.
3. If the server has never seen those props before, it asks the client for a copy of each new prop.
4. If needed, the client sends the props to the server, and the server stashes a copy in its own "PServer.prp"
5. The server now tells all connected clients in that room about the new props.
6. Each client tells the server if it needs its own copy of the prop(s).
7. The servers sends out copies of any needed props and the clients stash them in their own "Palace.prp" files (the files aren't displayed on the prop suitcase, but they are placed into the prop file).
8. All clients display the props.

If everybody already has a copy of all the new props, nothing gets sent across the net but the prop ID numbers each client just yanks-out its own local copy. This can really reduce lag, even in rooms where lots of people are using (and changing) large props. As long as the props aren't new to anyone in the room, the whole affair goes pretty quickly it's just a grab from your local disk.

The significant (and surprising, to many people) ramifications are these:

1. Any server where you have used a prop has a copy of that prop in its master prop file
2. Everyone who has ever seen your prop also has their own copy of that prop, hidden-away in their own prop file.

Normally, we don't see those hidden props because our individual prop files are internally split into two parts: the "favorites" part and the "hidden" part. Only the faves are displayed when you open your prop satchel window. A good indication of the existence of hidden props is when your prop file blossoms from one to eleven megabytes and you never use more than a couple of simple props for yourself (BTW, when you press the "Delete" button in the satchel window, all it really does is move the prop from the favorite to the hidden part of the prop file when you "purge" you are actually deleting (hidden) props).

Backups

So the props are in the Palace.prp file. We know that. You should make regular backups of this file. Use the method you like best, but keep a backup it's by far the easiest and fastest way to get those props back (Personally, I use Stuffit Deluxe, but you can use any archive/backup utility).

You should always make a backup whenever:

 

• You're upgrading your client software
• You're making significant changes to your Cyborg.ipt
• You're about to purge big-time
• You've added a lot of new personal props
• You're bored

Each prop has two ways of being identified: either by name, which you can set (via the name box in the prop-edit window), and by an internal number ID, which is set automatically by the software. Palace itself uses the number id for building macros and so forth. Multiple props may have the same name (particularly "NewProp" and "" i.e., no name at all), but props will almost never have the same near-random prop ID number. Names are handy for people and script tools like "setface" so here's Emergency My-Backup-Is-Gone Rule #1:

Name Those Props

Once you name them, it's possible to call props up by name at any time and for others to call them up by name, if they know the names. So the next time you lose your favorite Thunderbird 2 prop, just go to the last friend who saw it and have them type the following in their text window:

    / [ "Thunbd2-1" "Thunbd2-2" ] setprops

and boing! you pal has dressed in your supposedly-lost-forever prop, retrieved from their .prp file! A prop they can now handily give back to you. Of course, this would never have worked if you hadn't had the foresight to (1) make friends and (2) carefully name both halves of the Thunderbird prop "Thunbd2-1" and "Thunbd2-2," Mr. Tracy.

Copy Your Faves to Your Own Server

By running your own local copy of the server, you can drop copies of all your faves in almost any room and use it as a warehouse. The server will keep track of any dropped prop, and writes it right into the mansion.script, (aka "PServer.dat" on some machines) like this:

  PROP PROPID 0xAD527B51 CRC 0x76077F6C LOC 76 ,171 ENDPROP
  PROP PROPID 0xAD527B32 CRC 0x64B2C1DB LOC 123,124 ENDPROP
  PROP PROPID 0xAD827B24 CRC 0xECC755A5 LOC 74 ,124 ENDPROP
  PROP PROPID 0xAD328D19 CRC 0xAC13F95B LOC 106,314 ENDPROP

(a handy tool for saving props this way is the botbot "hang" script...)

We don't have to really decode all these internal ID numbers, but here's an important thing to remember you can shut down the server for a minute, make a tiny backup copy of the mansion.script along with PServer.prp, restart the server and then go back into the palace and "clean" the room you can always restore the mansion.script if you need to get the props. Now that's a hidden treasure chamber.... so hidden, the treasure's not even there except when you call for it.

Further thought will tell you that since entering such a room ensures that you have seen all of these props, they will automatically be present in your Palace.prp file, even without dragging them back into the satchel. So once you've entered a prop room that contains your missing props, you should be able to use any scripts or macros that use those props instantly.

Copy Your Faves to Other Servers

You can do the same thing by dropping props into (possibly hidden) rooms on other peoples' servers, but you run a couple of risks that way the risk that people might either take the props or accidentally clear the props, and the risk that the remote server's mansion.script or PServer.prp might be purged without your knowledge. It's a working solution for some folks, but a riskier one than just using your own little bank.

The Downside of Prop Names

Scripts that use prop names can be "spoofed." Since many props can have the same name, there's no guarantee that when you call up a prop with a generic name like "heart" that you'll really get what you expected. For this reason, it's always a good idea to name props with pretty obscure labels, that only you (and your cyborg) know.

Cloners

So what does all this have to do with cloning? It's simple, if you read the above description of the prop-transmission process. Every time your client sees a prop, your client has a copy of that prop, already tucked away in your .prp file. All a "cloner" does is figure out which of those props to wear. That's every prop every prop you see is in your local file, and every prop your wear that is seen by anyone else is now in their local prop file.

This is important to remember because it means that cloning cannot be stopped by a server operation. Cloning is a local operation. The cloner isn't really taking your props, the cloner has already been given the props the moment he sees you wearing them. The only thing the cloner has done is identified them and worn them himself.

Of course, this is unethical. And the "cloner client" found in obscure places on the web and traded-around by some snert feloows is an illegal hack that will get you kicked off any site run by Communities.com and can even get the distributors in a pile of legal trouble. But that's not a technical issue, so I'll leave it at that.

 

Add to: del.icio.us | Digg