The JFS update system
This are the update orbs installed inworld, with a purpose to deliver product updates and redeliveries on manual request. The procedure uses a special script (productkey) and sometimes also a special device (keyholder), both included in the product package. However, the procedure might be not trivial, as the incident with update sysem demonstrated: What hapened. The keyholder device allows the user to take a redelivery or update of the accordant product from the update orb. The device is sold inside the product package, hence the product purchaser has the keyholder and can update the product this way.
But, for some reasons, i put the keyholder device inside three products (which are no freebies) with all permissions. The result: The purchasers could give the keyholder to somebody else, they can easilly go to any JFS shop with update orb installed and take the package meant as redelivery but in fact turning to a freeby. The update was month ago, but nobody took a package on this way. Either everyone bought the products was fair (thank you all!), or my description about how to update is hard to understand.
I am sure, there is no either-or and both alternatives are true. Because of this i did two things. First i planed an update tutorial, i reserved it already, so i could link it in product documentations, now i have just to fill up the page. Pictures should explain the procedure better than plain text in the notecards, even if there are a few steps.
Second thing is more important: I exchanged the product keys. This means, the productkey scripts, and also the keyholder devices in older product packages will not work anymore. The new product packages, with working productkeys and keyholders, are being sent to all customers by automatical delivery process, so the update orb will work with new devices again.
Three products are affected:
Ok, released this month and updated again? Yes, indeed. RTS is a framework for building teleporter devices. Its too early to tell all details but i plan to release special teleporters build with this framework. And while building one such device i faced a handicap of the RTS design. The old design requires button prims to have an exact given name in order to work properly. This not allows to use the buttons for displaying hover text for example, or do something else, which, theoretically, a button could do concurrently to being a button.
The new design makes it possible to give a prim multiple (not conflicting) roles, like a button and a source for hover text or particles, or even roles specified by driver scripts written by independent scripters. This allows to reduce device prims and also makes the design more logical and flexible.
The automatical updates are right now on the way to buyers, as well. If you wonder what is RTS, here the product pages (you find PDF manual linked to the pages below)
- RTS Personal Edition (now version 2.1)
- RTS Professional Editon (now version 2.1)
- RTS Extensions (now version 1.1)
That's all about this.