To answer the ops original question, I think that the programmers manual might help, though Ironcross also explained it nicely. Remember, the bits for objects are programmer, wizard, R (read), W (write), and F (fertile). On properties the bits are R (read), W (write), and C (change). Finally, on verbs the bits are R (read), W (write), X (execute), and D (debug). These are described below:
The ‘wizard’ and ‘programmer’ bits are only applicable to characters, objects representing players. They control permission to use certain facilities in the server. They may only be set by a wizard.
The ‘r’ bit controls whether or not players other than the owner of this object can obtain a list of the properties or verbs in the object. Symmetrically, the ‘w’ bit controls whether or not non-owners can add or delete properties and/or verbs on this object. The ‘r’ and ‘w’ bits can only be set by a wizard or by the owner of the object.
The ‘f’ bit specifies whether or not this object is fertile, whether or not players other than the owner of this object can create new objects with this one as a parent. It also controls whether or not non-owners can use the chparent() built-in function to make this object a parent of an existing object. The ‘f’ bit can only be set by a wizard or by the owner of the object.
Every defined property (as opposed to those that are built-in) has an owner and a set of permissions for non-owners. The owner of the property can get and set the property’s value and can change the non-owner permissions. Only a wizard can change the owner of a property.
The initial owner of a property is the player who added it; this is usually, but not always, the player who owns the object to which the property was added. This is because properties can only be added by the object owner or a wizard, unless the object is publicly writable (i.e., its ‘w’ property is 1), which is rare. Thus, the owner of an object may not necessarily be the owner of every (or even any) property on that object.
The permissions on properties are drawn from this set: ‘r’ (read), ‘w’ (write), and ‘c’ (change ownership in descendants). Read permission lets non-owners get the value of the property and, of course, write permission lets them set that value. The ‘c’ permission bit is a little more complicated.
Recall that every object has all of the properties that its parents do and perhaps some more. Ordinarily, when a child object inherits a property from its parents, the owner of the child becomes the owner of that property. This is because the ‘c’ permission bit is “on” by default. If the ‘c’ bit is not on, then the inherited property has the same owner in the child as it does in the parent.
As with properties, every verb has an owner and a set of permission bits. The owner of a verb can change its program, its permission bits, and its argument specifiers (discussed below). Only a wizard can change the owner of a verb. The owner of a verb also determines the permissions with which that verb runs; that is, the program in a verb can do whatever operations the owner of that verb is allowed to do and no others. Thus, for example, a verb owned by a wizard must be written very carefully, since wizards are allowed to do just about anything.
The permission bits on verbs are drawn from this set: ‘r’ (read), ‘w’ (write), ‘x’ (execute), and ‘d’ (debug). Read permission lets non-owners see the program for a verb and, symmetrically, write permission lets them change that program. The other two bits are not, properly speaking, permission bits at all; they have a universal effect, covering both the owner and non-owners.
The execute bit determines whether or not the verb can be invoked from within a MOO program (as opposed to from the command line, like the ‘put’ verb on containers). If the ‘x’ bit is not set, the verb cannot be called from inside a program. The ‘x’ bit is usually set.
The setting of the debug bit determines what happens when the verb’s program does something erroneous, like subtracting a number from a character string. If the ‘d’ bit is set, then the server raises an error value; such raised errors can be caught by certain other pieces of MOO code. If the error is not caught, however, the server aborts execution of the command and, by default, prints an error message on the terminal of the player whose command is being executed. (See the chapter on server assumptions about the database for details on how uncaught errors are handled.) If the ‘d’ bit is not set, then no error is raised, no message is printed, and the command is not aborted; instead the error value is returned as the result of the erroneous operation.
Note: The ‘d’ bit exists only for historical reasons; it used to be the only way for MOO code to catch and handle errors. With the introduction of the try-except statement and the error-catching expression, the ‘d’ bit is no longer useful. All new verbs should have the ‘d’ bit set, using the newer facilities for error handling if desired. Over time, old verbs written assuming the ‘d’ bit would not be set should be changed to use the new facilities instead.
"On two occasions I have been asked [by members of Parliament!]: 'Pray, Mr. Babbage, if you put into the machine wrong figures, will the right answers come out ?' I am not able rightly to apprehend the kind of confusion of ideas that could provoke such a question." — Charles Babbage.
My Github