Re: unaliasing macros (room names, URLs, etc)

• Date: Fri, 1 Mar 1996 15:30:32 PST
• From:
  Michael Brundage <anomaly@u.washington.edu>
• Cc: moo-cows@parc.xerox.com
• Content-Transfer-Encoding: 7bit
• Content-Type: text/plain; charset=US-ASCII
• In-Reply-To: <v02130500ad5ce553caee@[128.42.5.110]> from "Bolie Williams IV" at Mar 1, 96 09:42:11 am

>The big problem with this [keeping a central database of room names for use
>with @go], which I noticed on BayMOO, is that you have
>to have a unique name for your room.  This is great for players, but
>it can be a pain if you want to make a beach and every variation on
>beach has already been taken.  So for a while, I lived in 'not a beach.'
>You could also run into problems if you want to have hallways and the
>like...
>Bolie Williams IV                                             ( ^ )

When my MOO serves up an HTML document, the on-the-fly conversion process
includes mapping aliased names to real URLs (for example,
link:LambdaMOO might map to telnet:\\lambda.parc.xerox.com:8888)

The method I use is this:  If the document knows the alias, let it decode it.
If it doesn't, check to see whether the author does.  If it doesn't, check
to see whether the alias is in a central "yellow pages."  If not, the
unaliasing fails.

This could easily be applied to this @go business:  First, check to see
whether the location is known to player.location, then player, then
$some_central_room_name_database, and if none of these three catch it, tell
the player "I don't know of any such place."  In this way users can override
system defaults without having common aliases like {"start", #11} be in four
hundred users' .room_names_for_@go property.


michael

• Re: really stupid newbie question
• From: bolie@io.com (Bolie Williams IV)

• Prev: Re: Tracebacks
• Next: Unknown opcode in disassemble()
• Index: MOO-cows
• Thread: MOO-cows