Virtual Landmarks: solving an age-old problem?

On July 24th, Toysoldier Thor posted about an idea he calls “virtual landmarks” in the Merchant’s forum. It’s a potential solution to an age-old problem most of us in SL face at one time or another: making sure all landmarks relating to your location in Second Life are always up-to-date.

Whenever we move in SL, we’re faced with the fact that every LM we’ve ever given out for our old place is now worthless, and we have no choice but to start issuing new ones. For some, this isn’t a problem – but for others it very much is.

Merchants, for example, are faced with the fact that every single landmark they’ve ever placed within a package contained in a vendor server or magic box or in a Marketplace folder or used within landmark givers they’ve placed around the grid (at malls, satellite stores and so on), now needs to be individually replaced (and in the case of Marketplace folders, each folder manually re-linked to the relevant listing). For some this can run into several hundred items and many hours of additional work. Nor are merchants alone – the likes of role-play groups, clubs, and so on, can face similar issues, both in terms of updating landmark givers, etc., and in terms of ensuring patrons get updated LMs.

In short – it’s a nightmare.

The issue: change your SL location and old LMs no longer work – click to enlarge (credit: Toysoldier Thor)

Toysoldier Thor’s idea is so elegant and (in some respects) obvious, one is tempted to ask why such a system wasn’t developed for Second Life from the outset. He calls it Virtual Landmarks (VLMs), and it essentially works in a similar manner to how we navigate the web. He describes the idea thus:

The concept of a VLM would be identical to the critically important Internet service of DNS (Domain Name Services) in that Internet users can create and use easy to understand HOST NAMES to access all Internet services where the HOST NAME actually masks the underlying required IP Address that is needed to actually route and connect their computer to that respective host.

Well the same would hold true with VLMs.  A VLM would be the equivalent to a DNS HOST NAME and the LM that is configured to be associated to this VLM would be equivalent to an IP ADDRESS.

One Change

In his proposal, rather than creating and distributing a landmark, a store-owner (or whomever) would create a user-friendly VLM (e.g. “My Wonderful Store”) which is then associated with the actual landmark for the store itself. This association is stored in a new service Toysoldier calls the “VLM Mapping Service”, and it is instances of the VLM – not the original – which are given to people or placed product packages, landmark givers, etc. When someone uses the VLM, their viewer sends a request to the Mapping Service, which  looks-up the physical landmark associated with the VLM and sends the information back to the viewer, enabling the user to be teleported to their desired destination.

The beauty here is that if the underlying landmark is subsequently changed (because the destination store moves, for example), all the creator of the VLM has to do is associate the VLM record stored in the Mapping Service with the new landmark – and every instance of the VLM in existence will automatically route people to the new location when used. There is no need to pass out new LMs, replace existing LMs or anything else; one change, and that’s it.

The solution: VLMs and the Mapping Service – click to enlarge (credit: Toysoldier Thor)

There are further benefits of the idea, as Toysoldier points out:

  • The system could be developed such that a single VLM could be associated with multiple landmarks (such as a primary store location, a secondary store location, etc.). Then, should the primary location be unavailable for any reason, the person using the VLM would be automatically routed to one of the alternate destinations
  • A round robin capability could be included, such that a single VLM is linked to a number of arrival points at the same destination (such as a club or an event that is liable to be popular, etc.). People using instances of the VLM are then automatically delivered to the different arrival points in turn, helping to prevent overcrowding at one particular point
  • Duplicate names could be supported for VLMs through the use of asset UUIDs (so there could be many VLMs called “My Beautiful Store”, and asset UUIDs could be used to ensure a VLM sends a user to the correct destination
  • As with LMs at present, VLMs held within peoples’ own inventories can be renamed without affecting their function
  • The system does not prevent the direct use of landmarks.

While there is some potential for griefing within the proposed system (people maliciously creating an VLM with the intention of flash-mobbing a venue or mis-directing people to a location, for example), the risk is probably no greater than is currently the case with the use of landmarks. Griefing via the use of VLMs might even be easier to limit, as LL would have control of the Mapping Service and so could effectively remove / disable VLMs shown to have been created with malicious intent.


In order to be properly implemented, this idea will obviously require considerable work on LL’s part, including:

  • The definition and coding of the The VLM Mapping Service
  • An update to to support a VLM-generation interface
  • The development of a mechanism by which a generated VLM is delivered in-world to the creator as a usable asset
  • The viewer and other SL services would have to be updated to correctly accept and interpret VLM data such that, for example:
    • If a user clicks on an in-world VLM asset, the viewer recognises it as such and request the Mapping Service supply the associated LM
    • If a VLM contained within a user’s profile (e.g. within Picks or Classifieds) is clicked from within the viewer, the viewer is able to request the LM from the Mapping service and display it on the world map
    • If a VLM contained within a user’s profile is clicked while displaying their web profile at, the service must be able to recognise it, request the LM from the Mapping service so that the user is logged-in to SL at the required destination after starting the viewer via the Launch Application request
    • Script functions which operate on landmarks are able to correctly process VLM

This is a considerable amount of work for LL to undertake, even given the obvious benefits to users and the platform as a whole. Therefore, Toysoldier has, by way of offering-up an incentive for LL to do so, suggested several options by which the Lab could charge for the service and / or use it to as a premium membership benefit. These include:

  • Limiting basic members to creating just two VLMs each, and charging them a “set-up” fee of L$100 and a monthly “maintenance” fee of L$15 per VLM
  • Allowing premium members to create up to 5 VLMs free of charge, and a further 10 for which only the monthly “maintenance” fee is levied.

The idea of charging fees is liable to be one of the more controversial aspects of the proposal, so it’s worth remembering Toysoldier puts it forward as an option, not a recommendation. However, the idea of LL charging for a service is not without precedent (the commission levied on sales through the Marketplace being an example). Additionally, the idea of levying charges is perhaps made less onerous by the fact that VLMs would not prevent the continued use of LMs, so users would have the choice as to which they use. Nevertheless, the idea has already been the cause of some debate.


The VLM promotional poster – click to enlarge (credit: Toysoldier Thor)

Toysoldier has put a considerable amount of thought into the proposal, and has encouraged further discussion and ideas to be put forward via the forum thread. In addition, he had raised a JIRA on the idea – SVC-8082). For merchant who support the proposal and wish to raise awareness of it, he has produced a special poster which can be obtained by IM-ing him in-world or from his in-world shop.

Those supporting the proposal are strongly urged to WATCH the JIRA, and if there are any additional use-cases that can be added to it, please do so. While there has been some general discussion on the topic on the JIRA itself, such discussion is perhaps better directed towards the forum thread, given Linden Lab prefers JIRA items are not used for debate  / general discussion.

7 thoughts on “Virtual Landmarks: solving an age-old problem?

  1. As you say, it’s so obvious. Much like item shortcuts in inventory (I take a modicum of pride in being one of many people who proposed these years ago), although I confess I never made the leap to extending the idea to Landmarks!
    Bravo to Toysoldier Thor for a good idea!

    (Thor? I wath in thodding agony)


  2. Oh gosh this is an amazing idea. Quick! Where is the JIRA for it?! 🙂

    I think that an alternative idea is to implement landmarks with URLs. After all, these days, landmarks expand to URLs which the viewer interprets as places to jump to. Well, all you would need to do is to subscribe to one of the many “URL minifying” services, add your personalised URL to that, pointing to…/ and change the link wherever the location changes.

    In terms of implementation and architecture, it would be much simpler. And it would work for OpenSim too.

    In terms of elegance, of course, Thor’s suggestion would be far better 🙂 But it requires a lot of implementation details, new servers, etc. on LL’s side.


  3. First, just read this blog & thanks Inara for the well written article. As with any good idea that is brought forward to LL, in order for LL to really notice it & take it serious for dev consideration, it has to be mass socialized. LL has to see overwhelming public support & demand for the idea. Articles like this surely help.

    One clarification in the article, the entire “service fees” aspect of my proposed solution was ONLY an added optional suggestion in hopes of putting a bigger carrot in front of LL. The fees arnt a root part of the solution & should not be a factor that diminishes support of the solution. In fact, adding a fee structure to the solution would only add to the complexity of the design.

    @beccapet: 🙂 thanks for the support. A small clarification, a VLM is not actually a “shortcut” – its actually a new advanced function LM with the intelligence to ask the VLM-MS service for LM coordinates (& in the future even additional info) for it to execute on. A shortcut is simply a pointer to an actual asset or entry. Subtle but critical to understand for VLMs.


    1. Toysoldier,

      Yup – understood the fees element was intended as an optional “carrot” for LL. Apologies if that didn’t come across as being clear enough – I’ll do a quick little tweak to amend.

      Let me know if there is anything further I can do to help spread the word.


      1. I was not trying to be critical at all. When I initially proposed the idea to the Merchant forum group, the fee structure was the ONLY sore sport in my initial blog. So you were 100% correct in that it would have been the only majore resistance by the community. And you correctly mentioned that since VLMs would be a new additional asset to the current LMs, users would not be forced to use VLMs if they had no need for the advanced features that VLMs offer. In the JIRA I made sure it was made clear that the fee structure was only a possible arbitrary value-add to LL to generate more revenue but had ZERO impact to the solution.

        Your article was excellent! Thanks!


        1. Toysolider,

          Didn’t take your comment to be in any way critical :). It’s actually valid, inasmuch as I’d hate for people to be coming after you with pitchforks! I’ve made a couple of small amendments within the text that make it clear the fees option are intended as an additional incentive for LL to act on the JIRA. :).


Comments are closed.