8.2 Getting More Capabilities

Note that this section is quite likely to vary depending on the design on the specific MOZ in question. This is simply from the perspective of the base MOZ server.

So, you're a newly created player in a MOZ, with the capablities listed in the previous section. You (or rather, the code underlying the actions) want to say something. Here are the steps involved:

• Call listContents on the current room. This returns a list of requestCapability capabilities for all objects in the current room.
• Call each of those capabilities, requesting a 'tell' capability. Some of them will refuse. That's fine; if they don't want to talk to you that's their business.
• Run the tell capability on each of them with what it is that you have to say.

Note that talking is _not_ handled by the room, in contrast to most MUDs. This is because in a capability based system, we want to avoid testing as much as possible, the testing in this case being whether the object wants to hear your tells or not. This way you can cache the capabilities for all the objects in the room you're in, so the test only gets run once (when you request the capability). Note, again, that certain things are glossed over, like retries for failed cached tell calls: the object may have revoked that capability, but may not mind giving it to you again.

Note further that although there are capabilities given to you for every object in the room, this gives you no information other than that an object is there; not even the name of the object or any description information can be given to you if the object does not allow it (unless the room has been coded to 'cheat' and store capabilities it is passed and give them away freely). This is how 'invisible' objects can be implemented, although you can still inform the user that an 'invisible' object seems to be in the room.

Another example: you want to move to a roomed joined to this one by an exit.

• Call the listExits capability, use the capabilities provided to request name capabilities, check the names, figure out which exit you want.
• Request the use capability on the exit. If you don't get it, well, you can't go that way.
• Call the use capability, pass it a capability on yourself allowing updating of your location information (i.e. the capablities on the current room). Note that the updater in question should test whatever it gets passed, to make sure the capabilities it was given actually work!
• The exit should already have an update capability on the room it's attached to, which it uses to remove you from the room's contents list, and add you to contents list on the other side. It then calls your update capability with the information from the new room. Any error causes everything to be changed back.
• Revoke the update capability you passed the exit, stopping further updates. In fact, the update capability shoud do this itself.

There is one other, rather different, way to get new capabilities: creating a new object returns a list of all available capabilites on that object.