Virtual Landmarks: offering a solution to the age-old problem

Update: June 2020: following the sad passing of Darrius in late 2019, his VLM product is no longer available. 

Update, February 2013: The number of VLM packages has been reduced to two, an Unlimited Version and a free Business Promo Version (30-day trail period with 5 VLMs. The details of this post have been updated to reflect these changes and the associated pricing restructure.

Update December 9th, 2012: Darrius has now produced an online Quick Reference Guide (QRG) to getting started and using VLMs.

Update December 6th, 2012: In order to make VLM management even easier, Darrius has now introduced the VLM Location Beacon as a part of all VLM packages. You can read more here.
VLMlogo2I first reported on Virtual Landmarks, Toysoldier Thor’s revolutionary idea for bringing the likes of SL landmarks into the 21st century, back in August 2012.  The idea started as a post in Toysoldier Thor’s blog before it moved to a forum thread post he started, and which generated a good deal of discussion, finally moving to a JIRA on the idea – SVC-8082.

The idea initially received favourable feedback from “front-line” LL staff at various User Group meetings, but appears to have been stuck in the “Someday / Maybe” category of things to do on the Lab’s side of the fence. However, things have now started to move elsewhere – but before we get to that, a brief recap.

Virtual Landmarks – What Are They?

The VLM promotional poster by Toysoldier Thor
The VLM promotional poster by Toysoldier Thor

It’s a problem we’ve all faced one way or another; as a user, we’ve opened inventory and double-clicked on a landmark to a store to find it has moved elsewhere; as a merchant, we’ve moved location only to realise that every landmark in every one of out magic boxes, vendor packs, Direct Delivery folders, recorded in every Marketplace listing now needs to be updated, not to mention every LM we’ve ever given out is now invalid; as a role play group we’ve relocated or revised our regions so that all previous teleport points and their associated landmarks are obsolete… The list goes on.

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 can be associated with one (or more) landmarks people can teleport to. The association(s) between a VLM and the landmark(s) are stored in a dedicated database (Toysoldier called it “VLM Mapping Service”). Copies of the VLM can then be created in-world and distributed exactly as landmarks are currently distributed. 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 power of VLMs is that should one of the underlying landmarks associated with a VLM subsequently change, all the creator of the VLM has to do update the VLM record stored in the VLM database 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.

Toysoldier also proposed a range of other capabilities as well, and it is worthwhile reading his blog post on the subject; but the above is enough to give you a flavour of the idea’s potential.

Sadly, and as noted, while the idea received initially favourable feedback from LL, there has been little or no movement on the idea. Until now.

Enter VLMs for Virtual Worlds

VLMVW  – VLMs for Virtual Worlds has been developed by Darrius Gothly, the man behind DGP4SL, one of the most respected brands in Second Life, and who has been a strong supporter of the idea since Toysoldier Thor first proposed it.

VLMVW is primarily a subscription-based service designed to provide a powerful and integrated implementation of the VLM concept. Highlights of the service include:

  • The ability to create VLMs which can be linked to up to eight in-world locations
  • The ability to create as many copies of a VLM as desired. Note that:
      • Copies can be distributed in exactly the same ways as “traditional” landmarks
      • Copies of a VLM take the form of an in-world scripted attachment which is worn in order to faciliate teleporting
  • The ability to create “VLMurls” for use in webpages and in SL Marketplace listing. These function in the same way as SLurls, but with the advantage that if the location they refer to within a VLM is updated, all instances of the VLMurl will automatically point to the new location
  • A publicly viewable web Listing page for all VLMs a subscriber has created
  • A private (key-protected) web page  displaying statistics on VLM usage
  • An optional “Store Kiosk” system which can be placed around a store / location and provide visitors with a means to quickly teleport between departments / locations.

The service is provided in two packages:

  • A free Business Promo Version which allows you to create up to 5 VLMs and provides a 30 day trial period. This allows you to test out the VLM system free of charge to see if it works for you. It is also available from the SL Marketplace
  • An Unlimited Version which allows for an unlimited number of VLMs to be created and has no account expiration date. This now sells for L$499 and is available from the SL Marketplace.

Both packages is supplied with comprehensive documentation and an optional info / demonstration pack using the DGP4SL stores.

Please use the page numbers below to continue reading this article

3 thoughts on “Virtual Landmarks: offering a solution to the age-old problem

  1. You know, when LL started to mix SLurls with landmarks — these days both are “almost” interchangeable, in terms of the viewer — I thought that a very simple solution would be to use some sort of URL shortener like or any of the myriads of such services. Developing a shortener service is incredibly easy, there are plenty of open-source, ready-to-deploy solutions — you just need to add the server and the bandwidth 🙂

    So all that LL would need to do is to change the asset associated with a Landmark to store a shortened URL. When creating a new landmark, the viewer would contact the shortening service with the full SLURL and create a shortened version, which would be added to the Landmark asset. When clicking on a landmark to teleport to it, all the viewer would need to do is to use the shortening service to replace it by the full SLURL.

    That’s it. Then we’d have a page, authenticated with our login/password, to get access to all shortened URLs and be able to modify them. Since all landmarks out there would only store the shortened URL, this would work always, and forever.

    It’s so easy that a prototype could be developed over a weekend 🙂

    But no. I’m sure that the LL dev team is imagining an ultra-super-complex system with lots of complex database tables, linking and re-linking to each other, and providing backwards compatibility to pre-SLURL landmarks and whatnot, and this will take them months to develop, because they imagine or foresee a lot of interesting edge cases, which will take them weeks to discuss, when a simple, straightforward solution would accomplish 99.9% of everything and be done in a week or two…

    Obviously this only works well because pretty much every viewer out there can use SLURLs as landmarks and vice-versa. So most of the “hard work” has already been done. I imagine that 1.23.X viewer users would have some problems, although even the few viewers I’ve used with that codebase (like Imprudence) can already use SLURLs…


    1. Note: most popular URL shorteners don’t actually allow the expanded URLs to be changed for a specific URL. But there is open-source code allowing you to set up your own service that allows just that.

      I like because they allow me to pick a specific shortened URL instead of a default, randomly-generated one. This is good for branding and for remembering shortened URLs 🙂 Sadly, they don’t allow URLs to be changed after being shortened, so their service is not suitable for what I suggested.


    2. “But no. I’m sure that the LL dev team is imagining an ultra-super-complex system with lots of complex database tables”

      Many are convinced LL aren’t even thinking that far down the road, hence Darrius rolling this solution out ;-).


Comments are closed.