Porting Algorithm

1. Make sure that your client doesn't wrap lines (@wrap off)
2. Try to figure out exactly what to port and how much work it might involve, then dump the objects you need.
   • First glance at the parents of the object you want to port: Type: @parents <object>. If the parents don't exist on your MOO you have to port them too. Reconsider porting or start porting the parents first.
   • Check if the parents needed are the same. Often parents that have the same name are slightly different. In this case, either fix the parent (or ask a wizards help if you are not allowed to). A quick way to compare the parents is to compare the number of slots and verbs. (See section 11.2.2). Also note that some extra slots inherited from very high level objects (e.g. #1 alias $root_class may not be needed on your moo).
   • Finally, try to find out if the object you want to port needs other objects (not parents) to work with. E.g. a ``video camera'' might need a ``recorder'' and a ``tape'' in order to be really useful. If you can't figure it out by reading the help or the description, dump the object as below. In any case, plan to port those objects too and even some parents of those.
   • Apply the instructions below iteratively for each object you want to port. Starting porting the parents first (if needed) and then port the more important objects first.
3. Next, create an object with the right parent on your own MOO using the @create command. E.g. if you want to port a fancy room with parent $room (#3) type: @create $room named ``Mike's Fancy Noisy Room'' or something like that. Write down the number, you will need it in the next step.
4. Next, dump the object on the MOO from which you port:
   • Type: @dump #obj with create id=#new-obj
   • #obj is the object you want to dump and #new-obj is the empty new object number you just created before.
   • Now save the code (if you can) on your local machine.
5. Edit the code (dump) you recorded (good luck with a bad MOO client!):
   • Remove the create from the first line of the dump since you allready created the object
   • Now scan the code for references to other objects (see above). Replace all the hard-coded numbers #... by correct ones on your MOO. The same applies for MOO using ``local cores'', e.g. the ``&'' objects on TecfaMOO.
   • Scan the dump for junk that is unwanted, e.g. inserted page or shout messages, truncated lines etc etc. and fix those.
   • Important: Fix things that won't work on your MOO. Consult your local documentation! E.g. on TecfaMOO we use (a non-LambdaCore compatible) multi-ownership scheme. Please have a look at chapter 9 for details on what is really different at TecfaMOO.
   • If you feel that most of the code is more or less acceptable go to the next step.
6. Uploading code to your MOO:
   • First of all you need to decide whether uploading the whole code or doing it piece by piece. I prefer doing it as a whole first and then fix things that didn't go well.
   • Consult the documentation of your MOO client on how to upload. Uploading basically means dumping text into the moo. With the rmoo/emacs clients, you just copy the code you want to upload and then you type ctrl-c ctrl-y or under X-Windows you can also select the code and then use ``Send X-Selection'' from the menu. Some clients also may have an ``upload file'' button or command (E.g. on Tinyfugue read /help upload. In the worst case you may try to connect to the MOO via a simple telnet and somewhat paste your code into it.
   • Now careful ! DON'T UPLOAD TWICE verb definitions, or you will have 2 definitions of the same verb! (guess that applies to most MOOs). To avoid defining verbs twice while uploading the same code several times comment out all those lines after your first uploading: e.g. change @verb #xxxx:"a_verb'' this none this to "@verb #xxxx:"a_verb'' this none this, i.e. add a " in front of the line.

A word of warning: Some objects (e.g. small social features or some kind of pets) can be ported quite easily, others do need good understanding of MOO programming. Still others need at least some wizard permission, though many objects that run under wizard permissions actually would run without if programmed in the right way.