Restore To Last Position (RTLP) was a joint server / viewer capability that presented uses with the ability to right-click on an object in inventory and return it to its last recorded in-world position, relative to the region in which the user is standing. However, due to an exploit used be griefers to rez objects on regions where they otherwise had no rezzing rights, the Lab made changes to the simulator code, which also impacted how this capability worked. As a result, the viewer-side code was removed from the official viewer.
Nevertheless, TPVs have continued to provide RTLP to users. Unfortunately, the the capability has been long been known to cause a range of genuine inventory issues, and since the changes made to the simulator code to prevent griefing, the shortfalls with RTLP have been somewhat exacerbated (such as with No Copy items, which is why some TPVs have blocked the capability from being used with No Copy objects).
However, as I reported In my last SL projects update, as a result of the recent survey the issued in respect of inventory loss issues, the Lab is considering deprecating the last of the server-side messaging which allows RTLP to work.
This has understandably given rise to concern among some TPV teams, simply because they are aware many users do find the capability useful, despite its limitations, and communicated this to Oz Linden at the TPV Developer meeting on Friday, March 13th.
As no final decision on the future of simulator-side messaging for RTLP has been made, Oz suggested to TPVs that they provide reasoned arguments as to how and why it, or a function like it, should continue to be supported by the Lab, which can then be considered when the time comes to determined the future of the current capability.
To this end, the Firestorm team have issued a blog post asking users to offer their own clear, concise explanations as to how they use RTLP and why they find it beneficial. The aim is to take the submitted examples and build them into a reasoned argument that can be presented to the Lab and hopefully encourage them to either reconsider deprecating the RTLP messaging or to provide functionality that might help meet some of the more common use cases supplied to the Lab.
So, if you do have a clear use case for wanting to see RTLP, or some similar type of functionality to continue to be offered, and regardless of whether you are a Firestorm user or not, you should consider helping to build a reasoned argument for retaining RTLP by adding your use case to the comments following the Firestorm post (please do not add them to this post, as I am not directly involved in compiling the information).
This doesn’t men RTLP will be saved, but at least the opportunity to present user feedback to the Lab has been provided; if that feedback is sufficiently constructive and consistent, it may influence future thinking on and around RTLP.