|
||
Unzip it into a working directory. Make sure that python is in your path (or that you give the python files executable permissions if your OS supports it)
From the working directory type:
python moopdirect.py
If your OS permits, you can mark moopdirect.py executable and type:
moopdirect.py
From this point on, the examples assume that you are using the first method. Assuming everything worked, you should see:
Loading database...
1. Enter MOOP
2. Edit help database
3. Read commands from a file
4. Set the treasury amount
0. Quit
>
the > is the prompt, which will change depending on context. Type 0 to exit.
A common problem is a traceback that looks something like this:
Loading database... Traceback (most recent call last): File "moopdirect.py", line 133, in ? if startup(): File "moopdirect.py", line 32, in startup moop.initialize() # load file File "moop.py", line 2032, in initialize else: gLoad() File "moop.py", line 1878, in gLoad (gObjlist,gProps,gContents,gCmdDefs,gTreasury) = pickle.load(file) File "/usr/local/lib/python2.0/pickle.py", line 896, in load return Unpickler(file).load() File "/usr/local/lib/python2.0/pickle.py", line 516, in load dispatch[key](self) File "/usr/local/lib/python2.0/pickle.py", line 682, in load_inst klass = self.find_class(module, name) File "/usr/local/lib/python2.0/pickle.py", line 739, in find_class raise SystemError, \ SystemError: Failed to import class MatchObject from module re
The important part of this is the reference to pickle.py. This error seems to be caused by an incompatibility between the pickled (saved) data format when the data was pickled in Python 1.5.2 and attempts to unpickle the data using Python 2.0 or later. The solution is to delete moop.dat and recreate it as described in the following section.
To start with a brand-new, clean database, do the following:
Delete moop.dat from the working directory
Run moopdirect.py
When prompted to create a new database from scratch, type Y
You will see the following text (your responses in bold. <CR> indicates you hitting the Enter key):
Creating new database... #0 : root #1 : object #2 : Implementor #3 : place #4 : directory 1. Enter MOOP 2. Edit help database 3. Read commands from a file 4. Set the treasury amount 0. Quit >1<CR> [file connect.txt] If you've already got a MOOP character at this site, enter your username and password below. If you don't have a character yet, send email to the administrator and ask for one. In the meantime, try logging in as "guest". Name:Implementor<CR> Password: (not needed in direct mode) >@quit<CR> Save database? [Y] Y<CR> 1. Enter MOOP 2. Edit help database 3. Read commands from a file 4. Set the treasury amount 0. Quit > 0<CR>
There should now be a new moop.dat file in the directory
The steps described above in Starting from Scratch create a minimal MOOP database, with very little functionality. You can begin to implement a MOOP directly from there, but most people will prefer to begin from a database that already has some useful objects, verbs, and helper functions. This common starting point is contained in a file called bootstrap.txt that ships with the software. Bootstrap consists of a series of moop commands, issued as if from the interactive prompt, which set up the basic objects and commands in the database. It progresses from raw MOOP Python commands through the setting up of users (Users, Builders, Coders, and Wizards), then creating the coding and building commands (such as move and dig), and using the new commands to create useful action "verbs" (such as page, take, drop).
In order to load the bootstrap, select option 3 (Read commands from a file), from the main MOOP menu. You'll see a lot of text scroll by as each command in the bootstrap is executed in turn. There's actually nothing special about the bootstrap commands, if you had the patience and typing ability you could achieve the same thing by typing the entire contents of bootstrap.txt in at the interactive prompt once you enter the MOOP as Implementor.
Run moopdirect.py and choose option 1, Enter the MOOP.
type
@password newpass
where newpass is your new password. You should see
Password changed to: newpass
Some people have objected to MOOP echoing the new password in that way, but honestly, unless you're connected via a secure version of telnet there's no security gained by not echoing. If this is a real issue for anyone, let me know and I'll address it (in the meantime you can address it yourself by adjusting the $user.passwd function in the boostrap.txt file and recreating the moop.dat).
The command to create a new user is
@newuser usertype as username
where user type is one of the types defined in the boostrap ($sys.usertypes.User, $sys.usertypes.Builder, $sys.usertypes.Coder, or $sys.usertypes.Wizard) and username is the login name of the new user. Initially the user password will be the same as the user name. E.g.:
@newuser $sys.usertypes.Wizard as Joshua<CR> Wizard Joshua created as object 25. Password set to Joshua $usr.Joshua set to #25. User moved to #13 >
The actual number of the object created may vary, depending on how many other objects have been created in the MOOP. The location number that the new object is moved to will not vary, unless you have changed the default home from the Newbie Room created in the bootstrap. $sys.usertypes.Wizard can be abbreviated to $wiz (similarly, $user, $builder, $coder); this isn't a result of a general-purpose abbreviation mechanism, these are aliases set up in the boostrap.
Create a new user of type $builder as Monty, and a new user of type $user as luser then exit the MOOP with @quit (remember to save), and log back in as Monty. (From here on, I'll omit the <CR>)
>look me
You see nothing special
>@set me.desc = "Oooh, a naughty boy!"
>look me
Oooh, a naughty boy!
>@set luser.desc = "Oooh, a naughty boy!"
PermError in line 1 of <at_set> : Can't modify desc
>
A builder has insufficient privileges to set properties on other users. @quit and re-enter as luser:
>@password yippee Password changed to: yippee >@set me.desc = "A handsome lad" Huh? (Verb "@set" not found.)
Although he has sufficient privileges to alter his own properties (as @password proves), a mere user can't run the @set verb. This means, for instance, that if you want mere users to be able to alter their own descriptions, you'll have to provide a more specific verb that they can use for that purpose (or just make all your users builders-- but that may make enforcing the rules in a more MUD-like MOOP difficult).
The boostrap set up a function and some verbs to make it easier to build rooms and connect them with exits (which are themselves objects in MOOP, opening interesting possibilities for inheriting properties and behaviors, but we'll get to that later). The basic function for creating a new room and connecting it to the current one is @dig. To @dig, you must be at least a builder.
Here's an example, after having logged in as a Wizard (e.g. Implementor):
>@dig n to Antechamber Antechamber created as object #30 and moved to #12 (Universe) Exit north created in Newbie Room as object #31 Exit south created in Antechamber as object #32 >
Note that in the current incarnation of bootstrap the @dig command requires directions as lower-case letters from the set (n, ne, e, se, s, sw, w, nw).
>north You go north. Antechamber You see nothing special.
Note further that although dig would only recognize n, MOOP itself recognizes n or north. Frankly, I think this case-sensitivity is a pain, and I intend to fix it by the next release, at least for direct commands like north or look. At commands such as @dig will probably have to remain case-sensitive for technical (Python) reasons.
>@set here.desc = "An elegantly furnished little room, in Louis XIV style." >look Antechamber An elegantly furnished little room, in Louis XIV style.
 Moop Home
|
 Moop Home
|
 Moop vs. Moo
|