/str1/str2/.../strn. The text can be an arbitrary string.
The types of messages are organized into a hierarchy, much like the structure of files and directories. There are several predefined types of messages.
/visual
/audio
/smell
/invisible
/visual messages generated
by invisible objects, such as ghosts and invisible wizards.
Audio events generated by invisible objects have type
/audio.
/psycho
/system
/$group
/$group. For example, an audio event that is only
detected by wizards would have type /$wizard/audio.
/!name
/!name, where name is the name
of the object that should receive the message (as returned by
query_name()).
There are also message types specific to classes, races, clubs, etc. See the following sections:
Composite messages
The two main functions that deal with messages are
receive_msg() and
request_msg().
Function receive_msg() takes either one or two arguments.
When it takes two arguments, they are type and
text. When it takes just one argument, the argument 
is a composite message.
A composite message is a list of the form
 ({ "type1", "text1", "type2", "text2", ..., "typeN", "textN" })
When an object receives a composite message, it goes through the
mapping, and receives only the first message for which it has
a defined handler. It ignores the other messages.
Consider the following composite message:
({ "/!frege/audio", "Dino tells you: Hello.\n",
   "/!dino/audio",  "You tell Frege: Hello.\n",
   "/audio",        "Dino tells Frege something.\n"
})
When this message is emitted in the room which contains
Frege and Dino, Frege will hear "Dino tells you: Hello.",
Dino will hear "You tell Frege: Hello.", and everybody else
will hear "Dino tells Frege something.".
Note: It would seem more sensible to define a composite message as a mapping. However, in a mapping the order is not necessarily preserved. Here, the order is crucial.