llDie() should get same protection against deletion of no-copy items as llDerezObject()
kiramanell Resident
Looking at llDerezObject(), I realized it comes with a built-in protection against deleting no-copy items. I submit that llDie() should get the same treatment. Under no circumstances, ever, should a script in a linkset be allowed to perma-delete a no-copy item! Especially since llDie() doesn't return your object to Inventory, or Trash even (Sic!). Inside a script of my own, I can guard against it with 'if ((llGetObjectPermMask (MASK_OWNER) & PERM_COPY) == PERM_COPY) {' or something, prior to the llDie () command, but it only takes 1 foreign script inside the linkset to make for a massive griefing tool!
Therefore, llDie() should fail silently when the containing object is not copyable by its owner, matching the protection already applied by llDerezObject().
Log In
Silverdown Winchester
Items can be preset to be temporary , that would have to be altered too.
kiramanell Resident
Silverdown Winchester well, then they can just exclude TEMP items from the check.
Journey Bunny
While interesting, I it would break all one-time-use consumable items in Second Life.
One may argue that there shouldn't be such items or that one would never want such items, but they do currently exist and do depend on the functionality. Breaking existing products and business models with a function-change would generally be a problem, even if those product-types are undesireable to some.
One use case mentioned here
is
interesting; specifically the idea that a single malicious script, added to a no-copy object, could cause a problem when it's not part of the original intended design of the object. Perhaps some protection could exist like a warning when adding
a script to a no-copy object, to alert the object owner that the script they are adding could delete the object?