@detachthis=n and @detachallthis=n don't lock linked items in folder

[Chandra Hild]

This is appears to be an implementation difference between RLV and RLVa where the API doesn’t define an intended behavior. In my particular use case it would be preferable to lock everything that’s in the folder, link or not.

Test setup: All items are inside #RLV, configured like so:

‌

RLV command sent to each viewer: @detachthis:linktest=n

Test results for all RLVa viewers:
Both “linked object” and “unlinked object” become locked on.

Test results for all RLV viewers:
Only “unlinked object” becomes locked on. “linked object” remains detachable.

‌

Tested RLVa viewers

• Black Dragon 6.4.0.46057
• Catznip R12.3
• Firestorm 6.3.2 (58052)
• Singularity Viewer (64 bit) 1.8.9 (8338)
• Alchemy 6.3.6 (46699)

Tested RLV viewers

• RestrainedLove viewer v2.09.26.04 (6.3.0) 6.2.5.192311159
• Kokua Release FTRLV 6.3.8.46425

‌

[Marine Kelley]

Ah, linked objects, how much confusion they brought me.

Conceptually, from the RLV’s standpoint, you don’t lock items but folders, and there is no such thing as a linked folder. Therefore, a link in an folder pointing to an item in another folder is not the same thing as the first folder being linked to the second.

If you locked “linkitems” instead of “linktest” and tried to detach “linktest” from a script, it would report stuff still being attached in that folder afterwards because if I did like RLVa, “linked object” being locked on by its folder, its link in “linktest” would stay worn no matter what, and this would be confusing for the user. For this reason, I preferred not to try every link pointing to an object nor every link an object is referenced by, when testing the lock state. For all intents and purposes, from a script’s standpoint, a link and its source object are two separate items because they are in two separate folders.

You could argue that the user could “cheat” by creating links to an object in other folders to bypass a lock restriction… Truth is, they can do that by copying the object (if it’s copiable), but they can’t do that if the folder containing the object is already locked.

You are right that in your case this may be confusing, but in other use cases the opposite would be just as confusing. I think there is no best solution there and I have scratched my head enough on the matter in the past.

Hope this helps.

[Chandra Hild]

I was afraid something like that was the case. I’m using a custom made wardrobe manager and I’m not quite sure how to replicate the behavior in viewers using RLV. I run the following commands:

• @detachallthis:newfolder=n - Temporarily prevent removing anything that’s in the new outfit, so that it avoids the scenario where things are quickly detached and then attached again in the event parts are in both the old and new outfit
• @remoutfit=force,detach=force - Remove anything not on the new outfit
• @attachover:newfolder=force - Add the new outfit
• @detachallthis:newfolder=y - Allow removing things from the outfit again

The outfits are mostly comprised of links for things like head, body, tails and such that are common between them.

‌