I released a version 0.81 fix for both the Commercial and Personal editions.
- Commercial Edition has full functionality restored.
- Personal Edition can still do the "Edit Linked Parts" --> "Touch" to update skirt, but textures will not be propagated. All other prim parameters will be sent to the rest of the skirt. I'm sorry that I was not able to keep ALL features identical between Personal and Commercial Editions
- the Template DropScript can still be used with both versions, to send texture information
Technical explanation: inconsistencies / holes in the SL Permissions system:
Users should be aware that a serious hole in the SL permissions system is that any object, even if "NO COPY / NO TRANSFER" can be physically copied, if they are "MOD"-able.
The way it works is that you write a script that reads off ALL the prim parameter settings of an object and reports them, and then you drop it into the "MOD / NO COPY / NO TRANSFER" object. With the prim parameter settings, you can recreate the object, and you could have another prim "listen" to this report of settings, and duplicate the object.
This has been known a long time, and caused quite an outcry when the technically excellent and ethically conscientious scripter Jeffrey Gomez released an incredibly helpful tool, that as a side-effect, revealed more publicly the already-present and known-to-some short-coming in the SL permissions system. He tried to work with LL to close this permissions hole, but LL was not interested. He tried to release an entire LSL-based system to close the hole, and was attacked by the user community.
So, the hole remains. As you might have guessed, the way the DropScript works is by reporting all prim parameters to the LoopRez object. It could copy objects that are NO COPY / NO TRANSFER, except that I coded it so that it checks permissions and refuses to run, unless FULL perms are present. I have no wish to be attacked the way Jeffrey Gomez was.
There was a time when even textures could be copied in this way; however, LL did patch the permissions system so that texture UUID's can not be read unless full permissions are present, while other prim parameters CAN be read. I was aware of this, and figured that would not be a problem, because I warned LoopRez Deluxe users that they would need full permissions on any template prims.
Here's the subtle problem that I missed: if an object that you have FULL permissions to is linked to an object that you do NOT have full permissions to, you will not even be able to read the texture UUID of the object that you DO have full permissions to.
And, when you try to read a texture UUID that you're not allowed to, it returns the NULL_KEY (all 0's). And when you try to set a texture with NULL_KEY, you get... the "Smoke" texture.
The Commercial Edition fix was easy -- the Little Metal Ball is now full permissions. Early testers of the latest version of LoopRez Deluxe sometimes had a metal ball that was full permissions, sometimes not, which is why the problem seemed unpredictable and intermittent.
The Personal Edition can NOT be fixed, because the panels are all NO TRANSFER (by definition of the Personal Edition.) You can still do the "Edit Linked Parts", but I edited the script so it would not try to read the textures (because it can't). Textures can still be read by the DropScript, because it is dropped onto an unlinked prim which you have full permissions on.
I apologize to all LoopRez Deluxe users who received this product with the "Edit Linked Parts" initially not working.
