The There standard teleport system allows for the following functionality:
These facilities are all always available to a given avatar wherever they are in the world, and form a partially personalisable set of locations unique to that avatar. You can't give such locations to your friends outside the context of going somewhere and summoning people there (if you have the explorer pack) for them to bookmark (if they have the explorer pack).
People got pretty bored with this setup pretty fast, and apparently quite early on made use of the There web application services to provide two facilities invoked by specially constructed URLs:
These URLs were provided on map sites, and can be embedded in document objects like scrolls. This latter path means that you can place an object in-world that provides a unidirectional teleport link to another location. Anyone at the first location can teleport to the second without requiring a bookmark, and without any need for the explorer pack.
Of course, this was such a flexible and useful facility that There have largely eliminated it: it is no longer possible to teleport to an absolute position at all, and the list of classes of object to which one may build teleport links has been dramatically reduced. However, it is still possible to do some interesting things, and the Transit System is based on the remaining functionality There, Inc. have left us with.
To see a little beneath the skin of the world, press the key combination Ctrl+Shift+D while using the There client. You will see that most objects in the world (including your avatar) are painted with a string of digits such as 278845028; this is the object's identifier and is something you'll need to know in order to make an in-world object participate in the Transit System. When you get bored with the numbers, press Ctrl+Shift+D to return your view of the world to normal.
Most objects in the world have an object identifier of their own: for example, each different scroll has a different object identifier, as does each different bottle in a bottle adventuremaker kit. The main anomaly you need to be aware of is that "add on kit" objects dropped in a portazone are all labelled with the object identifier of the portazone, rather than each having a separate identifier. It follows that the contents of a portazone are irrelevant; only the portazone itself is of interest to the Transit System.
Objects like scrolls and signs always have their own identifiers, even if they are dropped within the bounds of a portazone. You'll note that they don't take up any "drop slots" in the zone, either; I think this is just the same thing said differently.
The transit system knows about two kinds of object:
Depending on the type of object, it may be possible for it to participate in either of these categories, both or none.
You can use any in-world object that supports a web link as a Transit System source:
To make such an object into a Transit System source, you should write its object identifier down somewhere, fill in the object's link text as "Community Rapid Transit" and fill in the URL field with the following:
http://www.iay.org.uk/there/app/transit.phpNote that every Transit System source uses exactly the same URL; this in turn means that none of the in-world objects ever need to be changed if the Transit System changes. Believe me, this is A Good Thing.
If you set up a document object (scroll, book, script) you are given the (default) option to list the object in the library. I strongly suggest you do not do this as if there are large numbers of such objects in the world people might see this as spamming the library. I have listed one of these objects (the master scroll at Oasis Central) in the library independently. I don't think that signs are ever listed in the library, so you probably don't need to worry about this for them.
Your ability to drop the most obvious kinds of Transit System source object (scrolls and books) is controlled by your Author skill level as follows:
| Level | Jan 2004 | Feb 2004 | May 2004 | |||
|---|---|---|---|---|---|---|
| Drops | Time | Drops | Time | Drops | Time | |
| (none) | 3 | 1d | 3 | 1d | 1 | 30m |
| Casual | 5 | 3d | 5 | 1d | 2 | 2h |
| Avid | 7 | 5d | 7 | 3d | 3 | 4h |
| Expert | 10 | 7d | 10 | 3d | 4 | 8h |
| Renowned | 15 | 14d? | 15 | 3d | 5 | 12h |
| Legendary | 20 | 21d? | 20 | 3d | 6 | 24h |
You can see that with the current arrangements, you now need to skill up to Legendary in order to get anything half useful.
Your ability to drop signs is controlled by your Event Host skill level as follows:
| Level | Jan 2004 | Feb 2004 | May 2004 | |||
|---|---|---|---|---|---|---|
| Drops | Time | Drops | Time | Drops | Time | |
| (none) | 1 | 1d | 1 | 1d | 0 | 1m |
| Casual | 2 | 3d | 2 | 1d | 0 | 1m |
| Avid | 3 | 5d? | 3 | 3d | 1 | 2h |
| Expert | 5 | 7d? | 5 | 3d | 2 | 2h |
| Renowned | 7 | ? | 7 | 3d | 3 | 2h |
| Legendary | 10 | ? | 10 | 3d | 3 | 2h |
In the case of this skill, you can see that even Legendary is currently useless for Transit System purposes.
The only solution to the problem posed by the current skills regime is to place Transit System related objects within your own 24/7 PortaZone, inside your own house (just outside won't do), or inside a FunZone or FrontierZone you own. This normally exempts the objects from being retrieved when they run out of time, except in the case of PortaZones where an intermittent problem sometimes causes them to be retrieved anyway.
My experiments indicate that only the following kinds of object can be used as Transit System destinations:
Please let me know if you find other exceptions; I know for sure that scrolls, books, scripts and general bits of There landscape all do not work.
You don't have to do anything special to a destination object, just write down its object identifier.
The transit system works in terms of locations. One characteristic of a location is that it has a name consisting of three parts:
At any given location, you can drop a Transit System source, destination, both or neither. To make the location part of the operational system, I will need the following information:
In principle, I'd love to set up the entire Transit System myself just for the laughs, and of course the Author skills. This is impractical, however: I don't have the Event Host skills required to drop more than two signs, and those for only 24 hours at a time. Similarly, my Author skills don't allow me to drop as many scrolls as would be required.
In practice, then, I can help you set up a Transit System location but I can't do much about maintaining it, and you will have to own the Transit System objects for your location. I can sell you a standard Transit System source scroll already set up for the bargain sum of 399T, just ask me in-world.
In building the Transit System, I will want to exercise some editorial control: location names are at my discretion, for example. In addition, I will want to be assured that any Transit System location that is set up is with the (initial and continuing) agreement of the residents of that location, if any. I'm not sure how to handle that, but suggestions are welcome. Some of the locations in the current system should be regarded as for testing only, and will have to be confirmed before we "go live". I may also want to reject some locations outright: the idea, for example, is at least for now not to provide links to every portazone in a village, but to link the villages. The maintenance of a directory of individual houses would be a lot more work for me, and I'd probably want to invent some way to charge for inclusion. Similarly, I'm not currently in the business of providing newbie links to Tyr and Saja (unless there are communities there).
Here are some example configurations for Transit System locations.
Somewhere like Oasis Central might have a sign naming the place, with a transit system link. For people who never read signs, an additional source scroll could be dropped next to it. I've done this at Oasis Central and Kob Hill for now.
The destination object can just be a portazone, with no source scroll or any other way to get back into the system. They can walk back to the local *Central location! I 've done this for rstanton's fortress and the pub for now (the Fortress destination object is the portazone, at the pub I've used the Kilroy sign someone left there).
The destination object can be a portazone, with a source scroll placed next to the teleport-in point so that you can get back out.
[This functionality has been disabled.]
All the talk above about a single source object per location is a bit of a fudge. Really, there is a notion of the primary source object in a location; I need to know what the object identifier for this object is in order that the Transit System can tell you where you are when you enter it. You can have as many additional secondary source objects lying around as you like; this will work, the Transit System just won't know at which location the object is emplaced at and thus won't tell you where you are.
This behaviour can be overridden by changing the standard URL for the Transit System to include a parameter "here" whose value is the object identifier of either of the primary objects for the location. For example, add "?here=278845028" to the URL to tie a secondary source object to the sign at Oasis Central and have the source object be considered part of that location.
Similarly, there is actually no technical requirement to register a source-only location with the Transit System at all; just emplace a standard source scroll anywhere in the world and you're done. Of course, the system won't know where you are but that's something you might already have some idea of. You can carry a standard scroll round in your gear and just take it out when you need it: remember to retrieve it after you've teleported out, of course.
[You can read the scroll directly from inventory without taking it out. There may one day be a requirement to register Transit System sources.]
Finally, if you manually go to the standard hub URL with a browser (perhaps by putting a link to it in your home page and opening the in-client browser) the transit system will still work for you even without having an in-world object attached at all.
[There may one day be a requirement to use the transit system only from an in-world object, like the drinks system.]
The original (let's call it V1) Transit System was essentially a dynamic mock-up: a simple web page with some scripting behind it generating the text from fixed data held in the script. It was done that way so that the majority of the code in the new version (V2, now in operation) could be debugged before I had written the back-end code.
The V2 Transit System relies on a MySQL database hosted at my web site; this holds information about the locations and objects participating in the Transit System, and provides an administrative interface separate from the main script so that the database can be updated without needing to hack web pages. The administrative interface will not be made public; contact me if you need changes made to the system.
The database used is also shared with my Drink-o-Matic system; it allows a Drink-o-Matic to know where it is placed in the world, and provides the ability to restrict the use of the Drink-o-Matic system to in-world objects (plus a link from the in-world library for the truly desperate).