Writing:Assorted Features

This section documents miscellaneous features which don’t fit neatly anywhere else.

Portal URLs
A portal URL is a URL that acts as a linking page. It’s an ordinary URL, which may be put on any web page or distributed however you like. When a player clicks it, the page is added to the player’s linking booklet (if necessary) and the page is displayed as the current focus.

(The player is not automatically linked into the Age; the link is just offered.)

Example: http://seltani.net/portlink/522f776d6b3d3010e9c46a18 is a link to the global Korvichtav instance.

The exact behavior of the link:


 * If the player is signed in and playing the game (in another browser window), the link will display a message that the page has been added. The page will then appear as the focus in the open game window.


 * If the player is signed in, but does not have Seltani open, the link will enter the game. When the game world appears, the page will be focussed.


 * If the player is not signed in, the link will go to the sign-in page. The player will see an footnote about having found a linking page. Once the player signs in (or registers a new account), and enters the game world, the page will be focussed.

To create a portal URL, you must create a portal list in the build interface, and set its  flag to. (It doesn’t matter which world you build the list in, or whether it’s publicly accessible.) Add portals to the list in the usual way. Each portal will display a URL which you may copy and use.

"Note that the URLs refer to, not . The server will be transitioning to   at some point, so we’re using the future-proofed address for portal URLs."

"It’s a bad idea to put a portal URL into an Age as an external URL. It will launch an unnecessary browser window and generally confuse the player."

The portal’s instance acts in the usual way – you may create a URL that links to the global instance, or the player’s personal instance, or your personal instance. However, portal URLs may not use the “player’s current” instance option. (The player is entering the game from the outside, so there is no current instance!)

Because the URL copies the link, it will not work for uncopyable worlds. If a world is marked, you may extract a URL for it, but it will not be usable.

The portal URL will remain valid as long as the portal remains in the list, and the list is marked. If you change  to , the URL will stop working temporarily. If you delete the portal from the list, the URL will stop working forever. (Adding the world back to the portlist will generate a new URL.)

If you change the world (or instance) of the portal, the URL will remain valid, but will silently change to refer to the new world (instance).

Cross-Age property access
When you access properties directly, or using the  or   accessors, you are always reading (or writing) properties of the current Age. They may be world-level or instance-level versions of the property, but they are associated only with your Age. Different Ages normally never affect each other.

But sometimes you want them to. For example, you might want to imitate the “Relto pages” of MOUL -- artifacts (in various Ages) which modify your Relto Age when you touch them.

We can accomplish this via the  function. However, it is only possible between your Ages. It is not currently possible to pass information between Ages of different Writers.

"(Planned feature: a way to pass information to any Age, if the Writer has given you access permission.)"

To make this work, create a portal list in your world, containing exactly one portal, which leads to another of your worlds. Then, in the code of the first world, you may refer to, where “key” is the identifying key of the portal list.

This returns a realm proxy object for the target Age. You can use this just like the  object, except that it contains realm properties for that world rather than the current one.

worlds.realm("key").prop += 1 if worlds.realm("key").flag: ...

(There is no accessor for location properties of the target Age. We may add that feature if it seems important.)

The portal specifies its destination instance in the usual way. You may make a property reference to the global instance, the personal instance of the acting player, a specific personal instance, or the “current” instance (the scope of the acting player).

If the target world (and instance) has never been visited by anybody, the property reference will create the instance. This will invoke its  hook if one exists (but not  ).

Note that the portlist you use for property access does not have to be available to players as a linking book. It just has to be part of the world definition.

What if the portlist contains more than one portal? will always use the first one. You can refer to other entries by writing  where   is a (zero-based) index number. However, this is an error-prone technique, because ordering a portlist is a nuisance. It’s easier to use a singleton portlist.