Help (#161)
====================
accents @idioma ml-mail @quicksend
acentos @idiomas ml-prog @show-guest-ids
@all-languages @idiomes ml-strings tema
behavior irc ml-tell @tempo
behaviour @join ml-text theme
@client-options @language modales @time
comportamento @languages MOOsaico-index @todos-idiomas
comportamiento @lenguas multilingual @twitter
@descreve @lookfor multilingue uvl
@describe manners @name uvls
@descriptions @mcp @name-swap @ways
events @measure @names @weather
@go ml-commands @nome
guest-features ml-data programmer-policy
ACCENTS/ACENTOS
===============
Accents
=======
For better visual consistency in our texts, we request that you use proper
accents in all words where it is orthographically required. To do this, place
the accents after the letter that you want to accent except for accent grave,
which should appear before the letter. For example:
Rojo~es `a moda do Minho / Corac,a~o (Portugue^s)
Ojala' que este pequen~o ejemplo basta. (Espan~ol)
ku_ko_ basu wa doko desu ka? (Nihongo)
@ALL-LANGUAGES/@TODOS-IDIOMAS
=============================
Syntax: @all-languages
Shows a list of all languages defined here in the MOO.
@CLIENT-OPTIONS
===============
* charset
There are three types of text visualization:
latin1 UTF-8 french-notation
which can be set by:
@client-options charset=latin1
@client-options charset=UTF-8
@client-options -charset
* noresizeinfo
If you don't want a MOO confirmation of the window resize you should activate
this option: +noresizeinfo
The client must support MCP/2.1 and the package dns-nl-vgmoo-client
* loginonstatus
Send the connection messages of features Login Watcher (#896) to the status
bar of your MCP client. It must support dsn-com-awns-status.
Also see 'help @mcp'.
@DESCRIBE/@DESCREVE
===================
Syntax: @describe <object> in <language> as <text>
Sets the description of <object> in the specified <language> to be the given
<text>. (Descriptions of <object> in other languages are unaffected.)
For a list of defined languages, do "@all_languages".
@DESCRIPTIONS
=============
Syntax: @descriptions <object>
Shows the descriptions of an object in each language that it is available in,
not just in your selected language.
EVENTS
======
EVENT-REPORTING ROOMS
The default room has been replaced with the event-reporting room.
Whenever something "interesting" happens in such a room, messages
get sent to objects (in the room or not) which are interested in such
events. This sort of system makes it very simple to program, for
example, a dog that barks every time someone enters a room, or a
security system that beeps every time someone leaves the jail.
DEFAULT EVENTS
There are four events which have been built into the generic
event-reporting room: enter, exit, connect and disconnect. Whenever
someone or something performs any of these actions, the room will
notify any interested objects. For information about how to signify
interest in these events and how to program objects to respond, see
the section below entitled, "EVENT-AWARE OBJECTS".
It is worth noting that dropping an object in a room and entering a
room are both equivalent, since in both cases something is "entering"
the room. Correspondingly, the "enter" event will be triggered in
both cases, and it is up to the programmer to distinguish between
them.
CUSTOM EVENTS
If you wish to add or remove additional events on an event room, use the
commands:
addevent <event name> to <room>
rmevent <event name> from <room>
The effect of these commands is to modify the .event_list property on
the room and the list of listeners. Essentially, adding an event to
a room signifies that you anticipate the event happening in that room.
However, event-reporting rooms can handle events of any name -- they
just happen to be much more efficient when handling expected events.
EVENT-AWARE OBJECTS
Creating event-aware objects is simple. To have an object respond to
"enter" events, create a verb on the object named on_enter (this none
this). The :on_enter verb will be called every time something enters.
Similarly, verbs named :on_exit, :on_con, :on_dis, or even :on_bark
may be added to ordinary object to make them event-aware. In fact,
any verb beginning with "on_" will act as an event-handling verb.
The event-reporting room will usually call the :on_* verbs with one
argument: args[1] is a list of objects which are affected by the
event. By default, args[1][1] is the "direct object," or what
object triggered the event and args[1][2] is the "indirect object,"
or what object was affected by the event. For "enter" and "exit"
events, args[1][1] will be the player that did the moving, and
args[1][2] will be the room moved to/from. For "con" and "dis"
events, args[1][1] will be the player doing the (dis)connecting, and
args[1][2] will be the room in which it happened.
Using the value of args[1] is more accurate than trying to use
"dobj" or "iobj," since they will probably be undefined for some
events. The args list is (by default) guaranteed to contain relevant
information.
EVENT REGISTRATION
The event-reporting room keeps a list of objects interested in each
event (in the .event_listeners property). When objects enter the room
(or, equivalently, are dropped in the room), they are registered for
any events they are interested in. This is done by checking for :on_*
verbs and registering the object for the corresponding events. For
example, if a "security box" had an :on_enter verb, it would be
registered for "enter" events. If a "front gate" had :on_enter and
:on_exit verbs, it would be registered for both "enter" and "exit"
events. If an object has :on_* verbs which aren't in the list of
events recognized by the room, they are ignored (if any of those
custom events are triggered, though, the :on_* verb WILL be called).
When an object leaves the room or is picked up, it is automatically
unregistered for events in that room.
EXPLICIT EVENT REGISTRATION
If you wish to have an object explicitly registered for events in a
certain room, use these commands:
register <object> in <room>
unregister <object> in <room>
Explicitly registering an object for events in a room prevents it from
being automatically registered and unregistered if it moves into/out
of the room. This allows for remote objects to be aware of events in
the room. An example of this would be a centralized security system
that keeps track of all the rooms in a house, or a counter that
tallies the number of people entering a given room.
EVENT AWARENESS
There are situations where it becomes desirable to turn off
event-awareness for certain objects. This may occur if there are too
many people walking through the room, or more importantly, if the
event-handling verb is causing errors and distracting innocent
bystanders. If the object is a descendent of the generic event-aware
thing, the command to toggle event-awareness is:
toggle <thing>
If the object is NOT a descendent of the generic event-aware thing,
then it suffices to create and set the .events_off property to 1 and
to do:
update <room>
which updates the event_listeners list. Note that if there is no
events_off property, the object is assumed to be event-aware.
To toggle event-reporting in a room, the command is:
toggle <room>
When events are turned off for an entire room, no events will be
reported at all.
EVENT ERRORS
The event code does its best to trap errors. However, it cannot catch
errors made by other programers, in their :on_* verbs. If the
:on_enter on a dog in the E&L Garden is broken, for example, it is
going to spew error messages at everyone that enters. Needless to
say, this can become distracting and annoying; it is always a good
idea to test out your event verbs privately before dropping your
object in a public area. If the event code happens to successfully
catch an error, the owner of the object will be paged (if online) or
MOOmailed about the error. The object will also be deregistered for
events in the given room.
MORE DETAILS
Generic Event-Reporting Room (#1737)
verbs:
update <room> update listenesr
reg*ister <what> in <room> explicitly register something
unreg*ister <what> in <room> explicitly unregister something
toggle*events <thing> toggle event-awareness
addevent <what> to <room> add custom event to room
rmevent <what> from <room> remove event from room
stat <room> info on room
properties:
event_list supported events
event_listeners listening objects
event_listeners_explicit explicitly registered objects
event_active reporting events?
Generic Event-Aware Thing (#1740)
verbs:
toggle*events <thing> toggle event-awareness
properties:
events_off ignoring events?
@GO/@JOIN
=========
Syntax: @go <location> - teleport yourself to a given location
@join <player> - teleport yourself to a player's location
`@go #82' will teleport you to Central Hall.
`@join Ziggy' will teleport you to Ziggy's location.
GUEST-FEATURES
==============
Guests cannot add arbitrary features. Only features approved for guests can
be added. The programmer of the feature is normally responsible for
controlling this, but the wizards will intervene if policy is violated. The
following kinds of features are not acceptable for guests to use; people using
these kinds of features must log in so that they can be accountable for
their own actions:
(a) Spam. Features that draw big pictures or otherwise do a lot of output.
Guests do not need these. Our admissions policy is quite liberal. Let them
get a named account.
(b) Sexually explicit. People should not be using sexually explicit
communication with anyone they do not know well. A guest is not appropriately
accountable for any unwanted actions, so should not use these tools.
(c) Spoofing. Spoofing is not a nice activity anyway--it especially not nice
when done by anonymous people.
(d) Generally impolite. It's enough of a problem that guests can be impolite
with the mere use of `:' or `page' without adding the ability for them to be
rude in a programmatically-enhanced way.
See also "help manners".
IRC
===
The following table will help those users with an IRC background.
IRC MOOsaico
--- --------
<falar> say
/msg page
/nick @rename
/join @go
/kick @eject
/part @quit
/who @who
/names look/@who
/memoserv send @send/@quicksend
/memoserv read @read/@next/@mail
To know how to use them please type the 'help' command followed by the
MOOsaico's command.
@LANGUAGE/@IDIOMA
=================
@language [portuguese|english|...] - Changes or tells you the language
interface you are using.
`@language portuguese' starts showing you all the description in the language
of Magellan. Note: If a description in one language is missing the object
will appear described on another language. Please also check '@all-languages'
@LANGUAGES/@IDIOMAS/@IDIOMES/@LENGUAS
=====================================
Syntax: @languages
@languages <who>
Tells you a list of what <who> speaks. By default the <who> is yourself.
Syntax: @languages = <lang1> <lang2> ...
@languages <who> = <lang1> <lang2> ...
Declares that <who> is capable of speaking the specified languages. By
default, the person is yourself. (Only a wizard can change this information
for another person, but anyone can change the languages spoken by their own
puppets.)
@LOOKFOR
========
Syntax: @lookfor <user>
@lookfor! <user>
At the time of log in, you will be informed about the users in your personal
list that are connected. Use @lookfor to add a user to the list and @lookfor!
to remove a given one.
MANNERS/BEHAVIOR/BEHAVIOUR/COMPORTAMENTO/COMPORTAMIENTO/MODALES
===============================================================
Manners
=======
First of all, any action that threats the functional integrity of the MOO, or
causes any trouble to the people who support the MOO, will lead to the
expelling of the responsible user by the wizards. If you should find a hole or
a bug in the core, tell a wizard, don't try to make it work for you. Cracking
the system is out of the scope of behaviour. A good behaviour is about letting
the MOO run and not bothering the other characters.
o Be polite. Avoid being rude. The MOO is worth using if it is a pleasant
place for all the people. When people are rude and sordid to each other,
it stops being pleasant. The MOO is a place for people to socialize,
program, have fun and comunicate; as long as they mantain a certain
degree of education between them.
o If someone is rude to you, ignore her/him. Please don't try to get even;
that will only increase the rudeness and make the people involved loose
their interest in the MOO. If someone is bothering you, there are several
options. The first step is usually ask her/him/they to stop. If this
doesn't work, and avoiding that person/s isn't enough, some verbs that
might be useful are @gag and @eject. There is help available for both.
o Respect the sensibilities of other people. The users of the MOO come from
a wide range of cultures and environments. Each one's idea of what is an
offensive speech or description is probably unique. Try to keep potentially
offensive expressions out of texts people can casually see. If you intend
to create objects or build zones that may cause controversy in a segment
of our comunity, provide sufficient warnings to the casual explorers, so
that they can choose not to interact with those objects or zones.
o Don't shout. It's simple to create a MOO verb that displays a message to
every user logged in. Please don't do this.
o Only teleport your things. By default, most objects (including users) can
be moved freely from one place to another. This allows the easy creation
of some handy objects. Unfortunately it also allows bothering other people,
by moving them and their objects without consent. Don't do it.
o Don't fool people (`spoofing'). Don't produce messages that aren't
attributed to you. `Spoofs' can be fun and expressive when used carefully.
If you program a `spoof', use a nice version that announces itself as a
`spoof', and use it moderately.
o Respect other people's privacy and the right to control their objects,
including the right to decide who can enter or stay in their rooms. Don't
create or use spying devices.
o Don't teleport yourself silently or in secrecy. It's easy to write MOO
verbs to move yourself instantaneously from one place to another. Remember
to include in those programs a clear and understandable message that is
seen both by all the people in the place you're leaving and in the place
you're going to.
o Don't crash the server. The server is carefully shared by all the users
on-line, in such a way that anyone has the chance to execute his/her
commands. This sharing is, by necessity, more a less aproximate. Please
don't overload the server with tasks that run for a long time without
pausing. If you're working on a program which is going to run for a long
time, try to make it wait at least 5 seconds between each iteration (use
`fork (n)' our `suspend (n)', where `n' is at least 5). Thus you'll allow
others to have a chance of executing their commands in the middle of
yours. The more commands the users type in, the more loaded becomes the
server, leading to a greater wait time for the users.
o Don't waste object numbers. Some people, in a urge to own objects with
`interesting' numbers (like #1111, #2000, etc.), wrote MOO programs with
infinite loops, creating and recycling objects until the `good' numbers
showed up. Please don't do this.
o To help the growth of the database to be kept at a low level, create
thoughtfully (@create), recycle objects you don't use anymore (@recycle),
delete old mail (@rmmail), use features ($feature) instead of copying
a load of verbs. Don't forget that, for the time being, the machine
where MOOsaico survives is a low-resource one.
o If you are genuinely unsure, conduct yourself as you would if your
job depended upon it. Yours might not, but someone else's might.
Some people MOO from work, and we do not want to discourage that.
Through our linguistic efforts here, we are trying to show that
there is a potential for important value to the academic and
business community of using MOO. Unmannerly conduct on your part
could mean embarrassment or perhaps even loss of a job to someone
else! Be sensitive to how actions you take can affect others!
o On all matters of what behavior is acceptable or not, the wizards
reserve the right to have the final say. If you do not trust or
respect the wizards judgment in these matters, it is considered
good manners to contact the wizards saying so and asking to have
your account turned off.
------------------------------------------------------------------------------
If you couldn't read the above text due to it rolling out of your display, and
your client doesn't have a text-capture mechanism, type in `help @pagelength'
and `help @linelength' to learn how the MOO can help you to read texts of
these dimensions.
@MCP
====
Syntax: @mcp
Shows the MCP/2.1 supported packages by the client you are using and MOOsaico.
This list shows the ones that were negotiated between them, during your
entrance.
@MEASURE
========
Syntax:
@measure object <object name>
@measure summary [user]
@measure new
@measure breakdown <object name>
Normally, objects in the MOO are measured approximately once a day, and the
usage tally as reported by @quota is updated. You may wish to measure an
object specially, however, without waiting for the automatic measurement to
take place. @measure has some subcommands to handle this.
@measure object will measure an individual object right now, update the usage
of that object in your usage as reported by @quota, and update the date of
that object's measurement.
@measure summary will go through your or another user's objects and produce
the summary information that is printed by @quota. Normally this will be just
the same as @quota prints out, but occasionally the addition/subtraction done
to keep @quota in sync will get out of date, and @measure summary will be
needed.
@measure new will go through all your objects, measuring exactly those which
have never been measured before (that is, are too newly @created to have any
measurement data). This is necessary as you are only permitted to own 10
unmeasured objects, or object creation will not be permitted.
@measure breakdown will give you full information on where an object's size is
coming from. It will offer to moomail you the result. Caution: don't forget
to delete this message, as it is large and takes up a lot of space!
ML-COMMANDS
===========
These commands are useful when dealing with languages at MOOsaico.
@language <lang>
Changes your current language.
@languages <person>
Tells you what languages someone speaks.
@languages = <lang1> <lang2> ...
Tells the system what languages you speak.
@describe <object> in <language> as <text>
Tells the system what <text> to use as <object>'s description
in <language>.
@name <object> in <language> as <text>
Sets the <object> name in <language>.
@all-languages
Shows a list of all languages defined here in the MOO.
ML-DATA
=======
There are two kinds of encodings of text for multilingual purposes. Please
see the appropriate help topic:
help ml-strings Information about simple one-line strings.
help ml-text Information about lists of lines.
ML-MAIL
=======
You can send mail in multiple languages by adding multilingual markers to the
text of your outgoing mail. For information on how to do this, do `help
ml-text'.
In the mail editor, you can use the command
print in <language>
to see the text of your outgoing message in the indicated language.
When reading mail, your selected language (controlled by @language) controls
the language in which you will see mail.
Mail that is sent in multiple languages will have a "Languages" field in its
header. To see mail in another language, you can do
@language <language>
@peek <n> on <list>
where <n> is the message number and <list> is the name of the recipient you
were reading when you noticed its availability in another language. (Don't
forget to set your language back when you are done.)
Some day we will make a command to let you read the mail directly in another
language without switching your language, but right now we don't have such a
command. It is not possible to translate a message to another language after
it has been sent. We know this is a problem and hope to fix this some day,
too.
ML-PROG
=======
Several facilities of interest:
:portugues() This is a better way to find out if someone speaks
portuguese, but even this is obsolete as we move
into a multilingual world. Instead of
x:portugues()
you should probably use:
$language_utils:speaks(x,$standard.language.por)
to test what they speak or
x.language == $standard.language.por
to test what language they have selected.
.language A player's standard language.
:languages() All the languages a player speaks. (A false value
does not mean they speak no languages--it means they
have not set a value for this.)
.languages This property exists and supports :languages() but
you should NEVER refer to this property in code. It
is stored encoded for compactness, and the encoding
may change from time to time without warning. Always
use :languages() instead.
$standard.generic.language
This is the generic language.
$standard.language.eng
$standard.language.por
..etc.
These are the languages MOOsaico has pre-defined.
See also these other help topics:
$language_utils
$translator
ml-data
ML-STRINGS
==========
MULTILINGUAL STRINGS.
These are encodings of simple one-line strings. They correspond exactly to the
MOO datatype STR but are represented as lists. (See also "help ml-text".)
{{lang1, lang2, ...}, str1, str2, ...}
This can be used to encode a single string, where str1 is in lang1, str2 is in
lang2, etc. There must be the same number of langs as strings. The languages
must be descendants of $standard.generic.language.
Because the first list is not storage-efficient and occurs a lot, common sets
of languages are defined and can be accessed by numeric indexes, as in:
{integer, str1, str2, ...}
To find the meaning of these integers, you can use the @lsets command on
feature #2662 (Language Maintenance Feature).
ML-TELL
=======
The following verbs may be especially useful:
$language_utils:announce(...)
$language_utils:announce_all(...)
$language_utils:announce_all_but(...)
These are like player.location:announce(...) and friends,
except that their arguments can be multilingual strings.
See `help ml-strings'.
e.g., $language_utils:announce(player,{2,"enters.","entra."});
$language_utils:tell(...)
This is like player:tell, except that the arguments can
be multilingual strings. See `help ml-strings'.
e.g., $language_utils:tell($translator.permission_denied);
$language_utils:tell_lines(...)
This is like player:tell_lines, except that the arguments can
be multilingual texts. See `help ml-text'.
e.g., $language_utils:tell_lines(this:description())
There are also a number of useful special-purpose verbs on $translator.
Do "help $translator" for more information.
ML-TEXT
=======
MULTILINGUAL TEXT.
In multilingual text, lines can be identified as belonging to a given
language. The identification occurs when a marker such as "*ENG*" occurs on a
line by itself. There must be NO other text on the line (not even spaces).
When this happens, subsequent lines are interpreted as text in the specified
language (or languages). For example:
*ENG*
This is a test
that has two lines.
*POR*
Isto e' um teste
que tem duas linhas.
specifies "This is a test" (line 1) and "that has two lines" (line 2) in
English, and "Isto e' um teste" (line 1) and "que tem duas linhas" (line 2) in
Portuguese.
People reading in other languages will see the text in the first language
specified (which should usually be English, since it is most widely spoken
internationally).
Each language has associated with it a three letter name which can be used to
identify the language in this mode. At some point, this will be more
extensible but for now these names will work:
ENG English ESP Spanish DEU German
POR Portuguese FRA French NIH Japanese
The actual notations possible are:
*ENG* <- English
*POR,ESP* <- Portuguese and Spanish
*ANY* <- ANY language (This marker is handled specially.
ANY does not name a language.)
MULTILINGUAL/MULTILINGUE
========================
MOO technology was originally all in English, but at MOOsaico we have changed
many facilities to be multilingual. There is help on several of these:
Do... For information on...
----- ---------------------
help ml-text multilingual text (using markers like *ENG* and *POR*)
help ml-mail multilingual mail
help ml-commands commands related to languages
For a complete list, do "help ml".
The following mailing lists may also be useful:
*multilingual Discussion about our multilingual project.
*what Send letters here for help with translations.
@NAME
=====
Syntax: @name <object> in <language> as <name>
Sets the <name> of <object> in the specified <language>. The object aliases
are updated accordingly. Also check 'help @names'.
For a list of defined languages, do "@all-languages".
(the old @name is now @name-swap)
@NAME-SWAP
==========
Syntax: @name-swap <name>
Set your name from one of your aliases.
@NAMES
======
Syntax: @names <object>
Shows the name of an object in each language that it is available in, not just
in your selected language.
@NOME
=====
Deprecated. Use 'help @name'.
PROGRAMMER-POLICY
=================
Programmer Policy
We hope that our programmers will contribute significantly to our multilingual
world. Before asking to be a programmer, please at least create multilingual
descriptions for yourself, and preferably also for some of the objects you
have created. That way, we can know that you understand what kind of
participation we we need here.
Do `help theme' for more information about the theme of MOOsaico.
Being a programmer is a privilege, not a right. We do not tolerate the use of
programming to cause others distress or harm. If you abuse the privilege, you
will lose it.
Do `help manners' for more information about proper behavior.
@QUICKSEND
==========
Syntax: @quicksend <recipient(s)> [subj=<text>] [<message>]
@qsend
A quick form of the @qsend command.
@SHOW-GUEST-IDS
===============
Syntax: @show_guest_ids [yes/no]
Enables/disables showing of guest id numbers in pages and remote emotes.
With no arguments, shows the present state.
THEME/TEMA
==========
MOOsaico Theme
The theme of MOOsaico is one cultural connectivity. MOOsaico, like the world,
is woven together out of the individual fabrics of a variety of local
cultures. Although real world cultures vary from one to another, they are
forced by circumstance to co-exist in the tiny confines of the globe, and
whatever they collectively form comes to define the world as we know it. So,
too, with MOOsaico.
What is important in MOOsaico is not what you build, but that you take a sense
of pride in it and that you work to integrate it well with its local
surroundings in order to create a MOO world that all can explore and learn
from.
To help you in your effort to contribute to our community, we offer the
following as examples of desirable qualities that we would like to see
reflected in works made here at MOOsaico:
MULTILINGUAL. An important part of the work of MOOsaico is to experiment with
multiligual aspects. Where appropriate, use of the multilingual facilities to
accomodate interactions in a comfortable way for the user are encouraged.
CREATIVE. The things you build should be interesting. Functional objects are
encouraged over static ones in order to encourage participation. Objects that
encourage social goals such as education are also encouraged.
CONNECTED. The more spaces in MOOsaico that connect, and the more gracefully
they do so, the better the sense that we are all one community. It isn't
necessary that every room be connected, but thinking about how your space
connects to one or more other places may be a useful source of ideas.
OPEN. We encourage the production of spaces that are accessible and inviting
to people. Not every space needs to be open. Most people need both public
and private spaces. But there do need to be public spaces here, and somebody
has to build them.
Most of all, please remember that this is a community, and whatever you try to
do, please try to make sure that you put back into the community the kinds of
good things you expect to get out of it.
@TIME/@TEMPO
============
Syntax: time
Shows the current date and MOOsaico's local time, ie, what's the time in
Portugal right now.
@TWITTER
========
Sintaxe: @twitter <mensagem>
@twitter-set <utilizador> <senha>
Envia uma mensagem para o seu perfil no Twitter (http://twitter.com).
Naturalmente ja' deve ter um utilizador no sistema. A segunda forma define as
credenciais de autenticac,a~o a usar no twitter.
UVLS/UVL
========
UVLs (Universal Vocabulary Locators)
====================================
Vocabulary fragments (words, phrases, and whole sentences) can be created that
can be referred to by an integer key, called a UVL (or "Universal Vocabulary
Locator"). The maintainers of each language can then separately, and at their
discretion, associate a translation with any such UVL key.
A key is computed by $language_utils:make_uvl(object,index) where object is
any object that has a .vocabulary property and index is the position of the
vocabulary item in the .vocabulary property. The inverse operation is
$language_utils:parse_uvl(uvl) which takes an integer as an argument and
yields a list of {object, index, failure_reason}. If the failure_reason is
false, then the object and index are valid; otherwise, it is string explaining
what was the matter with the given UVL.
NOTE WELL: Once you put an item into the .vocabulary property, you must NEVER
move it. If you remove an element, the other elements will have different
positions and things will be horribly messed up! If you even change the
contents of an element, you must update ALL references in the MOO and since
there is no mechanism for finding all such references, this is virtually
impossible.
The specific encoding of a UVL key as an integer is bit-encoded:
[ 12 bits (0-4095) index ] [ 19 bits (0-524287) objnum ]
This means that no number smaller than (or equal to) 524287 is valid as a UVL
since the index part must always be 1 or greater. It also means that no
vocabulary index may have more than 4095 words.
A language object can be `trained' to know about the UVLs for any object that
has a .vocabulary property by using `train <language> for <object>'. To
assure quality and avoid mischief, however, only the authorized maintainer of
a language may do such training.
@WAYS
=====
@ways - Show the obvious exits of the current room.
If Ziggy was in Central Hall, '@ways' would show him:
Obvious exits: down, gate, south, and north
@WEATHER
========
Syntax: @weather [ICAO-code]
AirportWeather service. Giving a ICAO (International Civil Aviation
Organisation) code it reports the weather condition from the meteo station. To
find the code of the station near you check
http://www.airrouting.com/content/airportloc.html
Some popular codes:
LPPR Porto LSZB Bern Belp KJFK New York JFK
LPPT Lisboa EGLL London Heathrow KLAX Los Angeles Intl.
LPFR Faro EGKK London Gatwick
LPBG Braganc,a EHAM Amsterdam VHHH Hong Kong Intl.
LPMA Funchal EIDW Dublin, Ireland RJTT Tokyo Intl.
LPHR Horta LFPG Paris CDG YSSY Sydney Intl.
LEBL Barcelona HECA Cairo
LEMD Madrid Barajas
Copyright © 1994-2024 MOOsaico, Multilingual Virtual Community
All Rights Reserved. Todos os direitos reservados.
30 years of MOO (1994-2024)
All Rights Reserved. Todos os direitos reservados.
30 years of MOO (1994-2024)