# unaliasing macros (room names, URLs, etc)

Michael Brundage (anomaly@u.washington.edu)
Fri, 1 Mar 1996 15:30:32 PST

- Messages sorted by:[ date ][ thread ][ subject ][ author ]

    >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