Proposal: Semantical tagging if outfit items

[Former user]

Problem

Traditionally, the avatar outfit was made off layers, like shape, skin, hair, pieces of clothing. Attachments were just objects or accessory. The viewer was able to tell what an outfit piece or attachment is, so outfit handling by using layer and attachment name was sufficient. Meanwhile attachments take the role of outfit and even avatar body, leaving the traditional outfit useless.

This makes it impossible for the viewer to distinguish what an attachment worn is meant for. Imagine, a kitty avatar wears its upper body, a mesh jacket and the collar, all on chest slot. Now how to remove the jacket without breaking the avatar?

Solution

The suggestion solves that by introducing the role of the attachment. The role is in fact the name of the clothing layer or attachment slot, the worn item occupies. Traditionally, if you wear something on chest, than this was the role of the attachment. Now you can extend the Attachment name by the tag "(jacket)" making the viewer handle the attachment as if it was a jacket layer. The devices would see it as jacket, they could lock and strip it by issuing the "@remoutfit:jacket" commands.

The extension works as a 'dictionary' between the worn items and the view how the viewer accessing devices see them. While the old system only displayed what items the avatar wears, the extension show the devices what roles the worn items take and allows the devices to handle the items in respect of the taken roles. The items accessing the viewer will not know what items that are but handle them as what they are used for.

The extension continues the system of attachment names, where you name the attachment point, so the viewer knows where to attach something automatically. Now you name also which layer and attachment slots the item should occupy. This will be the role of the item, because the accessing devices will see this item as something worn on that layer or attachment point.

[Former user]

Formal definitions

• A clothing layer only states what layer and attachment slots it should occupy, because the viewer always knows where to wear the layered clothing (like a jacket or shirt.)
• An attachment can give the name of the attachment point to use for automatically wearing.
• There is possible to mix names of clothing layers and attachment points in same tag list.
• It is possible to name multiple attachment points. For attachments, the attachment point named in the list as first is used for auto-wearing the attachment.
• Slot names can be hidden by leading dot.
• The item is occupying only the named slots that are not hidden, no matter where the item is really worn.

Examples

1. A modern mesh avatar

It is made of these parts (names are examples)

• Alpha layer "White Kitty Alpha" rendering the actual shape invisible
• Upper body part "White Kitty Upper" to be worn on chest.
• Lower body part "White Kitty Lower" to be worn on pelvis.

All three parts takes the role of a shape, hence we tell the viewer to pretend they are worn on shape layer: We use the names "White Kitty Alpha (shape)", "White Kitty Upper (shape)" and "White Kitty Lower (shape)".

Now, the outfit scanner (@getoutfit) will not see the alpha part and the attachment scanner (@getattach) will not see the body parts. Locking or removing the alpha, chest or pelvis slots will not affect the avatar, but locking or removing the shape layer will.

So, although the viewer knows where to wear the alpha part of the avie, it has no clue where to attach the body parts. To give this information we take the attachment slot into the tag list. But in order they not occupy the slots and become visible by external devices, we hide the slot names by leading dot: "White Kitty Upper (shape, .chest)" and "White Kitty Lower (shape, .pelvis)".

2. Regular heels (simple version)

The example heels use four items:

• Shoe base named "Heel base",
• Alpha layer "Heel Alpha",
• Feet attachments "Heel Left" and "Heel Right".

We do the same here, we declare them all as shoes by tagging them so. The attachment get also the hidden names of attachment points: "Heel base" (unnamed), "Heel Alpha (shoes)", "Heel Left (shoes, .left foot)" and "Heel Right (shoes, .right foot)".

Done, now the attachment scanner (@getattach) will not notice the attached objects, taking off left and right foot via "@detach:left foot=force" will leave them worn, even if not locked.

The outfit scanner (@getoutfit) will only see the shoes layer but not the alpha layer. And another good news: Issuing the command "@remoutfit:shoes=force" will take off all four items at once (if not locked), without leaving ugly or cut feet.

[Former user]

3. Kneel boots (advanced version)

So, imagine now the old good kneel boots: Two items made off three attachment each. Plus the shoe base:

• Shoe base "Boot base",
• Feet attachments "Boot L Foot", "Boot R Foot",
• Lower leg attachments "Boot L Lower", "Boot R Lower"
• Upper leg attachments "Boot L Upper", "Boot R Upper"

So, the minimum we can do, we tag them all by "shoes" and mask the attachment point when needed: "Boot L Foot (shoes, .left foot)", "Boot L Lower (shoes, .l lower leg)" and "Boot L Upper (shoes, .l upper leg)". Same for right boot.

This way all 7 items occupy only the shoes layer and are lockable and removable all at once. Now, imagine, the boots are made so, that if you take the left or right boot (all three attachments), the foot not looks ugly. So you want give your dom or beloved the way to remove the boots side-by side. To do so, you tell the viewer, that the boots are not only a single piece of outfit, but also made off two pieces, each on left and right foot. You name the left boot items this way:

• "Boot L Foot (shoes, left foot)"
• "Boot L Lower (shoes, .l lower leg, left foot)"
• "Boot L Upper (shoes, .l upper leg, left foot)"

Similar the right boot items. You notice, the feet attachments do not hide the tag, so the attachment appears for the attachment scanner as worn on foot. The leg attachments hide the first tag - here the viewer will auto-attach them, but define the foot tag as attachment slot to occupy.

The attachment scanner will see them all as worn on the foot. Locking the foot will lock them all, and cleaning the foot slot via "@detach:left foot=force" will remove all three items of the left boot.

The boots still occupy the shoes layer, so removing this layer still takes all seven items as one piece.

Sculpted jacket ##

It is made off a worn jacket, a collar and upper arm sleeves, probably also a belt worn stomach. How to handle it is easy: All the attachments will get the "jacket" tag making all them to occupy the jacked layer, so the viewer locks and removes all them at once as a single object.

That's all

That's all about the proposal. Sorry for splitting, putting the whole text in one post was impossible (and reducing the text more without to make it unclear is impossible as well.)

Made also a typo in the issue and the title, "if" means "of", can't edit, sorry about it too.

[Former user]

With time of thinking about this issue, i tend to give it another title:

Introducing outfit roles by tagging wearable items

The extension should handle worn items (clothes and attachments) by their roles stated in the tag list. The role masks the place where the item is really worn, allowing the master to find the item on its expected place. What roles are possible this way? - I’d imagine three kinds of them, outfit roles, accessory roles and user-defined roles.

1. Outfit roles

are subdivided into body roles and clothes roles.

a) The body roles are

• skin
• eyes
• hair (yes, we take it as part of the avatar body)
• shape
• tattoo (usually it is a part of the skin)

b) The clothes roles are

• gloves
• jacket
• pants
• shirt
• shoes
• skirt
• socks
• underpants
• undershirt
• alpha

These roles explain the viewer very clearly what an attachment or clothing layer is meant for, and usage of the role names is also very clear for the user.

2. Accessory roles

That are roles of objects worn on an attachment point, i.e. the role names are names of attachment slot. The slots themselves have not always a clear goal, so we can give here only a suggestion, how to use which role. For example:

• neck - here will go the collar (no matter where it is really worn), leaving free the chest and spine roles.
• chest - Here you wear a chest jewelry, e.g. a necklace.
• skull - We have hair already (body role) so here is something worn on head, e.g. a helmet.
• shoulders (left and right one) - for something worn on shoulder.
• hands - for rings and other jewelry and accessory, worn on fingers and hands.
• feet - here go the shoes in case we want handle left and right one separately (all boot items could use this role.)
• spine - something worn on spine like backpack.
• pelvis - something worn on pelvis, like piercing. However, a male genital would use the shape role rather than this.
• mouth - piercing or cigarette, or gag.
• chin - another place for piercing
• ears - ear rings
• eyeballs - eye sparkles perhaps or a borg eye
• nose - nose piercing
• upper arms - arm ties or cuffs but only if wanted to be handled separately from forearm cuffs.
• forearms - normally the role for the arm cuffs on fore- and upper arms.
• hips - something worn there
• upper legs - leg ties, or leg cuffs (similarly to the arm cuffs)
• lower legs - the leg cuffs go usually here (upper and lower parts)
• stomach - belly piercing
• pecs - nipple clamps
• all huds - the huds are not visible by others, so the user can put whatever she wants.
• root - an invisible particle source perhaps.

This is just a recommendation to give a clue how to configure the accessory.

3. User-defined roles

However, we can go even further and give items roles not covered by layer and attachment names. For this reason not all RLV commands would work for them. The outfit and attachment scanners (@getoutfit and @getattach) would not see them, but the commands like @detach:name=n or @remoutfit:name=n will.

To give an item an user-defined role, we simply name it in round brackets: "Casual Female AO (.bottom, ao)". Now we told the viewer to use the hud attachment point for auto-wear, and define the role "ao" to display the item the accessing devices.

Retrieving list of used roles.

Because the role "ao" would see neither @getoutfit, nor @getattach, we need a command to retrieve the name, as well names of all used roles:

@getroles[:role]=channel number

If the role is named, the response will be either empty string (role not used) or the role if an item used it. If a role is not named, the response is a comma-separated list of all roles used by worn items. However, this command would reveal all used roles, body roles (shape, skin, etc), outfit roles (shirt, shoes, etc) and accessory roles (chest, left hand, etc) will be in the response, as soon the role is used by one of worn item.

So, a device can issue the command "@getroles:ao=22222" to check if there is something using the role "ao", or issue the command "@getroles=22222" and look up for all used roles.

Than if needed the device can issue the commands "@detach:ao" to lock the AO on the avatar or to remove it.

Implementation

The viewer could maintain three lists: One list for every role type (outfit, accessory and user-defined roles), the roles in the list reference further lists of items (layer and attachments) using this role.

The RLV commands are than translated forth and back through these lists.

Extension switch

The role extension requires the user to rename the outfit items, and although in the most cases the extension would handle the items on the traditional manner, the item names may in some case fall under new system of role tags. In order the user has not to go through the whole outfit folder, it is advisable to implement a switch setting the role system on and off.

[Satomi Ahn]

This is definitely something we've been needing, not only since mesh, at least from the time multi-attachments/layers were made possible, if not since the beginning.

And this was also one of my pet topics of thought :).

I wanted to add 3 (independent) suggestions, one concerning improved backward compatibility, the other making the whole thing even more flexible, and the last one concerning implementation.

Backward compatibility

As I see it, I think one of the main problems is retaining backward compatibility while providing the full power of state-of-the-art outfits and not making everything over-complicated in the meanwhile.

Allowing the use of existing clothing layer and attachment spot names as "roles" is indeed natural as it allows using @[get|rem|add][outfit|attach] commands. But, this is somewhat limited by the pre-existing definitions.

For user-defined roles, sure new RLV commands could added, but it is also be possible to add virtual folders that could be browsed with @getinv[worn] commands, for instance @getinv:roles=1111 (and "roles" would be listed under root @getinv=1111). Commands that usually apply to #RLV folders would also apply to items under /roles where it makes sense. More virtual folders could be added to reflect other information (see below).

Multiplicity

That was one aspect. The other set of suggestions I mentioned is for dealing with multiple things of a kind, i.e. multiple worn items assuming a common role (but would also apply to "legacy" roles such as clothing layers and attachment points).

It should be possible, when you want to detach or lock an item, to choose only one of the items of a role you want to detach or lock. This is especially important for legacy roles (for user-defined roles, an alternative would be to have them all as one-of-a-kind and just define more roles if you want to wear more items).

For this to be possible, there should be a way to distinguish between items of a role, so they should receive identifiers. One way would be to have the viewer automatically assign such identifiers, but then it is hard for the user to guess which is which (except arguably for clothing layers if the identifier would be the stacking number... but then the identifier would change over time, which would not be practical). So, the same way a user can assign roles to clothing items, it should be possible to assign a unique label (a more precise/descriptive name for that piece of clothing).

If such labels are used, then it would also be nice to be able to declare user-defined roles as being either "one of a kind" (behave the same as body parts in the current system: wearing a new item would replace items you were wearing) or "multiple of a kind" (like anything else you can make the avatar wear).

Different worn labels under one role should be browseable using new RLV commands and, for backward compatiblity, using commands like @getinv:roles/myRole1=1111 (which would give the list of labels of worn items having the role "myRole1").

Implementation

It occurred to me that a system of inventory links similar to LL's outfit system since viewer 2.0 could work well.

Each worn item should create a link (where items could either be inventory items or whole folders, if they should be considered as one inseparable piece of clothing).

The links could be organised in a folder hierarchy such as /#SomeSystemBaseFolderNameToBeInvented/role/label/link. RLV commands (new or new cases in old ones) would only have to browse this hierarchy.

One-of-a-kind roles could have a special mark, like a reserved first character or some capitalization convention.

[Marine Kelley]

I have read the whole proposal carefully and I came to the same conclusion as Satomi : to create a second #RLV folder (with a different name) and to fill it with links is the best way to formalise the problem and to solve it. And yes we do need this kind of control, because the RLV has no way of knowing which object to remove from the Chest attach point (for instance) if there are 3 worn at the same time.

In essence, the user does not care what role an object is assigned to. That role may change, it may be multiple, it may be under a hierarchy, so it would totally confuse any non-technical user any day. Therefore, to put this kind of information directly into the object name would not be appropriate. However, to create a link to this object and to put it in a special folder (or several folders) does make sense, because what the user wants to tell the RLV is "add/remove/lock/list the set of objects and clothes that go by the label X" where X is a folder contained in that second #RLV root, and is full of links (or even actual objects).

[Former user]

Geez, you people over-complicate things.

The solution is so easy: By using a special folder structure, i.e.

#RLV Folder
|-My Outfit
| |-:Jacket (i.e. using : do distinguish the folders from normal folders or attachment point folders)
| |-Jacket Alpha
| |-Jacket Mesh/Prim
| |-Jacket Pockets
|-:Hair
| |-Hair Mesh
| |-Hair Alpha
| |-Kitty Ear L
| |-Kitty Ear R
|-:Skirt
| |-Skirt Alpha
| |-Skirt Mesh

And add new command like @getnamedslots (while keeping @getoutfit and @getattach for backward compatibility).

When selecting requesting @getnamedslots, user would receive a list of

[Jacket] [Hair] [Skirt]

One could also encode the folders to contain info i.e. :Skirt:L = Locked.

Advantages:

• Easy to set up
• Full control and customization
• No issues with no mod items, just link it in th correct subfolder
• Can be configured w/o an RLV device and easily changed by user with inventory tools
• More descriptive slot names. Seriously, (Spine) (Chin) etc. do not tell much about the item attached there, because many items have a weird slot and it's impossible to tell by the name of the slot which item is attached there. But when the user can name the slot ":Earring" ":Belt" then it's pretty descriptive and clear for anyone who interacts with that person and tries to undress her/him
• No issues with locking. It's easy to create a named slot ":AnimeShape" and lock it (i.e. ":AnimeShape:L", without doing the lock on a single slot (i.e. chest, which may be shared with mesh chest and mesh jacket)

Disadvantages:

• There are no

[Former user]

bump Anything?

We NEED a solution, the current system is not acceptable and do not have any future in the current and coming life cycle of Second Life

[Marine Kelley]

Whoa there. The current system IS acceptable, there is no need to rush to find another one. I'm thinking of something to add to the existing one, such as executing RLV commands directly from the titles of notecards included inside the folders. I don't think we should go into complicated features when a simple solution like that could do the trick.

And remember, this is a discussion. We are not specifying anything yet.

[Former user]

I disagree. If something is complicated, then it's the current system. It's very inflexible, i.e. with all of this "hacks" where one has to add hints to the item name so the system recognize it. It's a dead end.

What we need is a clear and flexible system, that will not only handle the current generation of clothes/items but also the future one. What's more simple than organizing the available slots as sub folders? It allows to easily modify a set with a single mouse click (i.e. drag an alpha from folder A to folder B).

Using notecard titles feels like a adding hack, instead of a proper and future-proof system. There is no clean way to implement this which allows the flexibility required for the today's SL users need.

The current system already has way too much limitations, not just in this one. i.e. the locking features system is pretty broken too. If I lock the hair for example, which is pretty common, I only want to block it for scripts (i.e RLV Collar), but it also prevents me to change the hair manually, when i.e. changing a set. Same for skin, shape, tattos. So in order to change one have to unlock it, which is more than annoying and unpractical in the real situation.

Slot (or group) locks have to be on script level only, without preventing the manual change of items such as hair or skin/shape

[Marine Kelley]

"Inflexible" ? "Broken" ? "No future" ? Are we talking about the same system ? And are you deliberately trying to be offending ? Or did you find a bug ? If so, file a bug report in the appropriate section.

I don't like to hear that the system I took years to make right is "broken" and "full of hacks". It's neither. And I don't like when people come up with a "Let's ditch it and do it my way" (with the thin print "and I'll watch you work"). The shared folder system is the most complicated feature of all the RLV, and it is compounded by the complexity and fragility of the appearance manager of the SL viewer. Touch one line of code there and you break everything, if you're not extra careful.

The hints as you call them were necessary at the time when the viewer was only able to wear one thing per slot, there was no way to "Add" outfits unlike now (and some viewers are still unable to handle multi-attachments at this time). Plus, they are a viewer-side feature only, they don't impact scripts.

Also if you were referring to "nostrip" bits on the folder or item name, this is a viewer-side feature as well, nothing to do with scripts. If an item is marked "nostrip", then you should still be able to remove it manually, but no script will be able to.

Lastly, I still prefer Satomi's suggestion of using inventory links. We can use what's already existing instead of reinventing the wheel, and users are more and more used to creating links now. No need to come up with yet another syntax that nobody will use anyway unless they are forced to (and people don't like being forced). The key to success here is to make it backward compatible with zero pain for the user and for the scripters. Short of that, it will not work.

[Former user]

Of course I am not trying to offend anyone. That's my opinion on the current implementation from a programmers point of view.

Currently users are limited to either taking off attachments or "clothes". Back then, 5-8 years ago when SL first came out that may be sufficient. But todays requirements changed. Most clothes are done as attachments (either fully or a big chunk of it) or mesh.

The other thing of course is, that attachment names have no meaning. When someone roleplays and uses other peoples RLV relay/collar/whatever, they have no meaning to know what item is attached at a specific attachment slot. A hat for example can be skull or hair, it's up to the item creator. Same as for jackets, shirts or whatever.

There is absolutely a need to have custom names for the slots, to allow easier interaction with the RLV device while i.e. undressing a person.

Is the folder system I suggested easy to implement? No, I never said that. Is it flexible, easy to manage and ready for future additions from Linden Labs? Pretty much.

Don't know about that nostrip stuff, I was referring to the "lock/unlock" feature, which was the only way I found (and everyone else I asked) to prevent an item from being taken off by others) and it did prevented changing stuff manually. But it suffers same weakness as the "hints" basically... you can't rename no-mod items, which again brings in folders into play I assume.

Back to the term "hacky/full of hacks". I have seen that pretty much in my work as programmer. You have a code base, you add a feature to a system that's not meant to be extended. Well that may works once or twice. But if adding another feature would mean that the whole thing (program or feature) breaks, it means that there is a fundamental flaw and that a new system, written from scratch may be a better alternative than attempting to modify the current system.

And yes, this may mean that it will take more time than adding a quick or "somehow working" implementation and fixing some bugs that may be introduced with it. But a rewrite of the system also always means, it's better designed to be extensible in future. You/we know more now than we may have thought 5 years ago then the current system was designed and implemented.

[Marine Kelley]

Well there is no question of rewriting the entire system from scratch. As for "hacky", it is as hacky as you get when you are given a codebase that, as you say, was not designed to do that in the first place. Twice. Once in v1 and it was workable, and a second time when v2 was introduced (after, surprise, a total rewrite by ProductEngine), and it was a nightmare to port and test. So for something that "hacky", I find it has worked pretty well over the years.

But back on topic.

Your proposal has merit. At least it doesn't require the user to rebuild a whole inventory tree (especially since, I'm not sure so correct me if I'm wrong, inventory links cannot link to a folder, only to an actual item). To add a special character and a new RLV command has the nice advantage of not breaking what is already existing and not forcing the user to do any further work if they don't want to.

However, the very issue discussed here is "how to remove the alpha layer that is included in the shoes folder without removing the alpha layer that is included in the dress folder, and without actually knowing the name of either folder".

The solution Jenna gives is to ask the user to define the role of each item. That means a lot of work asked from the user, with education over how to define roles. This takes years to achieve only a marginal result, even if the specification and the implementation are perfect.

Another solution given by Satomi would be to use inventory links organised in another #RLV folder. Technically this is the best solution, since it provides the level of abstraction we need, while harnessing a technology that is already working (the inventory links). However I assume we can't link to a folder (that would be nice !), and once again that requires the user to do additional work for no immediate return.

A third solution given by Odessa would be to indicate directly in the folder name whether it is a role or a regular folder. It requires additional RLV commands hence current scripts would not benefit from this feature, but why not. It also requires user input.

My idea of adding RLV commands written into notecard titles was not a brainfart from me, it came from some observations I did over time, such as it would be nice if a particular folder automatically kicked another folder when worn, or automatically wore another folder when detached. This idea is the consequence of the "add/replace" choice every user has now. When you force someone to wear something, often you want them to unwear another outfit. For example, if the new outfit contains shoes, you will want them to remove the old shoes. Some outfits are mutually exclusive like that. So my idea was "it would be nice if the viewer automatically did things when adding or removing a folder". By extension, this would mean executing RLV commands, totally under the user's control. Granted, I did not put much further thought into it except "how to define an event and how to define the order of execution". More work done by the user, and this is not really solving the problem here.

To be continued...

[Marine Kelley]

... cont'd

We want to know whether the currently worn alpha layer is part of the boots or the dress. There is currently no way to know that with the existing commands.

Why not use the names of the containing folders themselves ? Let's take an example :

If Jenna is wearing the following folders :

• Dresses/Glamour/Black dress
• Shoes/Boots/Knee/Leather patent

We could have some kind of command that does this : @getlabels:alpha=2222 => "black dress,leather patent"

Then : @remoutfit:alpha,leather patent=force

And it would remove the alpha contained into the "Shoes/Boots/Knee/Leather patent" and that folder, without touching the dress, without knowing the name of the folder and without requiring the user to do anything further what they are already used to.

PS : syntax and names are absolutely not thought out, this is just an example.

[Satomi Ahn]

There is a lot of discussion her, and I confess I haven't read everything with the attention it would deserve.

However I wanted to react on Marine's latest remark:

It is my personal feeling that not too much work should be put into directly handling "low level" system items from RLV API. Indeed, underlying inventory/outfits system has changed many times over the past (links, multiplicity, new layers, etc.) and might change again (ever heard of Avatar 2.0?). Every time this caused new problems in RLV API: sometimes forcing changes (longer replies for @getoutfit and @getattach, for instance) and addition of new commands (@getpathnew for instance) and often breaking older commands (multiplicity alone made the outcome of @[rem/add][outfit/attach] commands very unpredictable) with no obvious way to fix them.

Instead, more effort should be spent to make it easier to set up and provide a "high level" view. Current #RLV folders already are a quite good high-level abstraction that so far resisted well when LL made the changes mentioned above.

The main thing #RLV folders are now lacking is a kind of simplified view (like an easy way to get a list of clothing items worn at a time, not by folder names, but by clothing types, similar to existing system layers)*. Indeed, currently, working with folders is so tedious for a menu user who has to browse through all the folder hierarchy, that they will often end up switching back to the "low level" menus despite all their shortcomings.

I used to be strongly in favor of commands like extended the @remoutfit commands proposed above, that can selectively strip a single item worn on the target slot. Now I believe system slots should be exposed to the API as little as possible. Only valid case would be as a fallback when there is no other information available (no shared folders set). Also, giving the ability for "tagged" folders to change the way old "low level" commands behave would be neat, as that would be allowing legacy RLV devices to still work with all the new nice "high level" abstractions.

*: this could be achieved either by dynamically created folder links coupled with @getinv for queries, or by an improved @findfolder that would allow more filters and whose answer would be a list of several folders. Of course I am only throwing ideas. I am sure there are other ways that would work well if not better.

[Former user]

Hello Marine, Satomi, Odessa

I am surprised here is a such a long discussion crystallized. But admittedly i have not looked here for so long time. Now I've read all posts trough (also mine), than scrolled up and read again. Than thought about the issue again and how it should be implemented in the viewer and how a scripter would be using it. Now I think I can put a new volley of post here :) They look much like a definition but is not yet, rather a suggestion of the definition.

I have also corrected typos in my posts (very sorry for them) but I left the title as is, since it is a part of the link and people probably linked the issue already. But that is little of relevance here.

Folder links

First of all, Marine states two times, it is not possible to create folder links (an inventory link to a folder.) So I assumed it is not possible to do so in the linden viewer. I am using Firestorm and it is possible at least since two versions (now FS 4.6.7) to create folder links. Actually I have not used them at all but after the test, I am thinking about to change that.

I describe shortly how the folder links go in both viewers, so you don't have to install Firestorm (unless you are inclined and want to adapt the patch from FS.)

In FS, to create a link, I click the item or the folder with the right mouse button, then hit "Copy" button in the context menu. Then I go to the folder where I want to create the link, click the folder with the RMB and hit the "Paste as link" button in the context menu. This works the same for item links and folder links.

In the linden viewer it is not possible to create a folder link at all. The only way to create a link is afaik to save outfit and use links the viewer created, and these are only item links, not folder links. So, to test folder links in linden viewer, I created them via firestorm, then reclogged into linden viewer (Second Life 3.7.16) and repeated test there.

Folder links have however a special behavior.

1. I cannot rename them or change the link properties. When I click the folder link with the RMB, I only get "Delete" and "Find Original" in the context menu. Context menu of an item link is much larger.
2. When I delete the folder link, the link is gone and the original remains in place -- much like deleting an item link.
3. When I move a folder link into another folder, the link remains at its old position but instead, the linked folder is moved into the folder I tried to drop the link into. What reason? No idea.
4. I cannot copy the folder link. Neither by context menu (no "copy" there) nor via Ctrl+C/V (pressing it has no effect.)
5. I cannot move a folder link into a prim, neither into content via build window, nor via Ctrl+Drop. The cursor is the red stop symbol.
6. When under "@unsharedwear=n" restriction, items outside the shared folder are not wearable even when they are linked from #RLV directly or are inside a folder that is linked from inside #RLV.

Except that I can not create folder links in linden viewer, the test behavior is the same in FS and LV. The point 6 is special for FS since the linden viewer does not know @unsharedwear.

This means that LL' servers and the viewer seem ready for the folder links, all the FS has more is ability to create them any place. However, adapting the patches can turn not easy as it will affect the user interface too.

However, the folder links have an interesting usage scenario. By now I kept all the restraints and outfits i wanted share inside the #RLV structure, while their package boxes and the stuff like land marks, note cards etc. that came with restraints and outfits I kept inside the system folders (e.g. Objects for restraints.) This breaks the inventory in parts and I have to look at both locations when i want update my restraints.

Now I can leave also the restraints in the folder with all the rest stuff or better on a level below. For example for RR Cuffs that would be Objects/BDSM/Restraints/RR/Elegance/Cuffs and ../Collar. And under #RLV I save just the links for Cuffs and Collar folders.

This keeps the inventory together and the links will also remain valid when I rez the cuffs to install a new plugin into, while links to the cuffs themselves are destroyed due this operation. Beneficial also for my outfit folders, i have over 20 outfits with elegance cuffs. After update of them by replacement or plugin installation, I have to replace broken links, while folder links would stay valid.

I think links and also folder links are great things and I am considering to start using them massively. But the point 7 is a showstopper. I think the @unsharedwear restriction should not stop me from wearing outfit that is outside #RLV folder when it is linked from inside #RLV. But creating links or moving them into #RLV should be just stopped then.

But this conclusion is far off topic for this issue, so back to topic now.

[Former user]

Back to topic

I would redefine what the original proposal wanted to achieve. Basically we want now to extend the physical view to our shared folder by a logical view. The physical view is how we see our shared folders. We can see how the folders are structured and what items are inside.

The logical view is once the view how our shared folders are presented to the devices accessing them and thus the device users. The logical view tells also how the shared items are used, rather than what is their type. That are the roles of the wearable's in our outfit.

The current system of shared folders offered only the physical view to the accessing devices. When we for example don't wear a legacy shirt, our shirt layer is not used. The accessing device (magic wand of our miss) can see that but it does not see that instead the legacy shirt, we wear a mesh shirt which is physically an attachment. The magic wand cannot strip that shirt off directly.

The logical view would explain the viewer that the prim attached to our right hand is actually a meshed shirt so it should take the role of a legacy shirt. The viewer would tell than to the magic wand "she wears a shirt you can strip it off" and the miss were happy to take it off without needing to know that was actually a mesh prim attached to an impossible position.

Surely we can emulate the logical view by special structure of the #RLV folder. This is mostly how Odessa suggested it.

For example we create a folder "#RLV/layers/shirt" and create a link there to our worn shirt (and all other shirts we wear). Then our miss when she wants to strip our shirt would navigate to the "Shared Folders" then to "Layers" then to "shirt" and then strip off the worn one.

The magic wand will still see the shirt layer is not used, it will not know anything about this path mistress used, it's fully up to her interpretation to find and use this path when she strips off our clothes. The logical sight is a way to solve this problem.

First, The logical view gives roles to groups of wearable items (a group can be also a single item, it is than just a group containing this one item.) When a role is given, the whole group becomes a single item. This item uses up than a single slot (clothing layer or attachment slot.)

This slot must not be one used by the items in the group physically but the accessing devices see this group as an item using this slot and will handle the group as an item using this one slot. The viewer has then to translate the lock/unlock/strip commands for this slot as lock/unlock/strip commands for the entire group. Fully transparent. The accessing devices do not know anything about the translation.

Second, the logical view creates a simplified structure of the shared folder that is not exactly the physical structure of the items in the shared folders. Through some level of abstraction, the user of the viewer gets some level of freedom to organize the shared folders without to change the way the accessing devices see and can use the shared folders.

Third, the role system allows to give items also user-defined roles. This way the system should become even more flexible and ready for the future of SL. When new clothing layers or attachments come - we simply give the items new roles. When a device expects us to wear wings, we can give all our wings the role "wings" and the device will see and handle them properly.

Definition via folders

I have read all the suggestions and arguments in the thread, and I also come to the conclusion, using the tags in inventory names is not practicable. Much better is the usage of the folders and links.

Giving up to the viewer the task to create and maintain the role structure is somewhat alluring, but not possible, since the viewer can hardly tell the roles of wearable items. However, there is one possibility: When the user gets an assistant or wizard for managing shared folders and by using it the user assign items and groups their roles. The wizard can be either included into save outfit dialog or (preferably) would be a stand-alone floater for maintaining the already exiting #RLV structure.

However, I am not sure if creating a new #RLV-like top folder for roles is practical. Since you have then two places to look if there are roles and which of them are defined for each particular folder in #RLV. And then needs to synchronize things if something changed, it seems difficult to me to maintain.

Informal definition

I would prefer to declare the roles together with the items we give the roles to. This would keep the items and their roles together so we don't have to look overall to see if we did it right. However the system should allow a definition by a single separated folder.

Folders are in general easier to put into a structure and by using links you can build even a different structure than your items have in your inventory. Also using folder names is much easier than putting tags to names of every single item. So we use folders for role definition.

Basically, we create a role by creating a folder where we put items taking this role or links to the items. The Items can be at another place inside or outside #RLV folder or even inside another role folder and take the other role too.

To distinct the role folders from normal folders we start the name of the role folder by a period and take the role name into square brackets, e.g. ".[shape]". The period is important, it hides the folder content from the inventory scanner commands. The square brackets represent a package, a symbol that items inside are a single element. Also they allow to add an option string at the end: ".[shape] nostrip".

Another way is to use the leading string ".#", e.g. ".#shape". To add the option string we would need than for example round brackets: ".#shape (nostrip)". The hash reminds btw on "#RLV" symbolizing a #RLV inside #RLV.

What way is used is probably not very relevant and even every viewer could suggest another way, or give the user a freedom to use whatever syntax of role definition (Possible but not nice when you change the viewer.) so probably the exact syntax should be met at early time point.

[Former user]

Examples

However, let's try to define role structure by examples given above and similar so we can extract a formal definition of it later.

1. A (really) modern mesh avatar

Is made of mesh body, prim hair and an alpha layer. We store the items in a folder #RLV/Avatars/Mesh/Avatar2 and obviously all the items have one role: The avatar body, i.e. shape. So the structure would be this:

  #RLV
    Avatars
      Mesh
        Avatar2
          .[shape]
            Avatar body (center)
            Black curled hair (skull)
            Fullbody alpha

As you can see, all the items go in a single role folder, thus they take this one shape slot. After that @getoutfit should report shape to be used. This way all items are used as a single item, removed or locked via @remoutfit:shape together.

Since all the items are inside a hidden folder, they are invisible to the attachment scanner @getattach and also @getoutfit:alpha should not see them. But since the folders on the path are not masked by leading dots, the path scanners should be able to see and put on/take off the avatar by using the path Avatars/Mesh/Avatar2.

I am quite inclined to make it possible to access the role folder by role name over the path: "Avatars/Mesh/Avatar2.shape". In this case we address the whole folder and not the single items inside and the dot becomes another meaning here - sub element of the parent folder Avatar2 and not an invisibility mask.

This is an important part of the whole further definitions.

As you can see, there are no square brackets in the path. It is because the abstraction of the role system hides the way how the role was defined in the concrete folder structure.

The access to the real clothing layers and attachment points inside role folder is so not possible. The abstraction of the role system hides the way what the role items are really. But I can imagine this abstraction is too restricting and we need an access to the alpha or attachment slots. This may be done by appending the slot name to the role name: "Avatars/Mesh/Avatar2.shape.alpha".

Although the access to the role structure via role name (i.e. "shape.alpha") is logical, it reveals the role structure to accessing scripts but we want abstraction. To achieve that we make the...

Abstraction rule 1: The role folder loans the physically used slots to the parent folder. This way we can access the alpha layer also via "Avatars/Mesh/Avatar2.alpha" and the fact that alpha is defined within the role folder is now hidden.

Now there are cases when an access to the role structure is possible and cases when the access is not allowed. The avatar, for example, can not loose the alpha in most cases without getting an ugly look. I would achieve this by two option strings: ".[shape] fragile" and ".[shape] solid".

• "fragile" means scripts can access inside the role folder
• "solid" means this access is not possible
• When none of the options used than the viewer settings should decide.

A special case: We leave the items inside the role parent folder and link them from inside the role folder:

  #RLV
    Avatars
      Mesh
        Avatar2
          .[shape]
            Avatar body (link)
            Black curled hair (link)
            Fullbody alpha  (link)
          Avatar body (center)
          Black curled hair (skull)
          Fullbody alpha

What changes now? Since the items are not inside the hidden folder, the content of the role folder is now open and can be addressed directly by the used slots: "Avatars/Mesh/Avatar2.alpha", regardless if the shape is a solid or fragile role. With the abstraction rule 1, this path looks quite the same if the role content remains inside the role folder or not.

The only difference may be this: The outfit and attachment scanners @getoutfit, @getattach will now see the real slots used by the role content even if the role is solid by default or by definition.

2. Marine Dress and Boot example

Marine suggested me to wear these outfits (I leave out here the Outfit folder which I have in my real #RLV):

• Dresses/Glamour/Black dress
• Shoes/Boots/Knee/Leather patent

In my #RLV structure they would have the roles shirt and shoes and be defined like this:

  #RLV
    Dresses
      Glamour
        Black dress
          .[shirt] fragile
            dress alpha
            Black dress (chest)
    Shoes
      Boots
        Knee
          Leather patent
            .[shoes] fragile
              patent base
              patent alpha
              patent L (left foot)
              patent R (right foot)

Now the path for each role would be "Dresses/Glamour/Black dress.shirt" and "Shoes/Boots/Knee/Leather patent.shoes". With abstraction 1, we bypass access to the role content for outstanding scripts, so they could access the role content directly over the role parent folder.

The roles are defined fragile (who knows perhaps that is possible) because of this one example: When the scripts know the role path in each case, they would lock or remove the alpha layers via "@remoutfit:dresses/glamour/black dress.alpha" and "@remoutfit:shoes/boots/knee/leather patent.alpha".

Without knowing the path, the scripts would have to use "@remoutfit:alpha" and either remove all or the last added outfit's layer (not sure how it is really defined in this case.)

Note: When distinct enough, the path may be shortened by leaving out the leading folders: "@remoutfit:dresses/glamour/black dress.alpha=force", "@remoutfit:glamour/black dress.alpha=force" or even "@remoutfit:black dress.alpha=force". This comes close to the idea of Marine "@remoutfit:alpha,leather patent=force"

3. Old-fashioned kneel boots

Two boots made of prims, each boot has 3 attachments and the shoe base but no alpha. As in example above, we want not only give them the role "shoe" (so they act as a single piece) but also allow them to be removed side-by-side, i.e. we give the parts the roles "left foot" and "right foot". How to do so?

a) Solution 1.

The first way would be to put everything in the role "shoe" and link the parts from the roles "left/right foot":

  #RLV
    Outfit
      Boots
        Black Kneel Boots
          .[left foot]
            Boot L Foot (link)
            Boot L Lower (link)
            Boot L Upper (link)
          .[right foot]
            Boot R Foot (link)
            Boot R Lower (link)
            Boot R Upper (link)
          .[shoes]
            Boots Base
            Boot L Foot (left foot)
            Boot R Foot (right foot)
            Boot L Lower (l lower leg)
            Boot R Lower (r lower leg)
            Boot L Upper (l upper leg)
            Boot R Upper (r upper leg)

This is workable but need us to make links, increase so the number of items in inventory and makes it harder to maintain.

b) Solution 2.

Another way is to nest the role folders:

  #RLV
    Outfit
      Boots
        Black Kneel Boots
          .[shoes]
            .[left foot]
              Boot L Foot (left foot)
              Boot L Lower (l lower leg)
              Boot L Upper (l upper leg)
            .[right foot]
              Boot R Foot (right foot)
              Boot R Lower (r lower leg)
              Boot R Upper (r upper leg)
            Boots Base

This way each item is only once in the inventory without any links and the structure is easier to understand and maintain. In each case once Black Kneel Boots are worn, we have used the slots "shoes" (a layer), "left foot" and "right foot" (attachments) but not the lower and upper leg attachment slots. At least this how the outfit scanners would see the situation.

Question: Should we reveal the nesting of the roles to accessing devices? It seems inclining to visualize that the role "left foot" belongs to the role "shoes". But this way the viewer user has no freedom to select what solution to use when defining the role. The scripters have to handle both structure definitions and we also come in conflict with the abstraction 1, since in each case the content of the roles is loan to the role parent folder. Hence...

Abstraction rule 2: When roles are nested, the child role keeps the content but also loans it to the parent role as if has links to the child role content.

This way we achieve exactly the same logical view to the Black Kneel Boots folder as in the solution 1 so that the accessing scripts are not able to tell what way the viewer user has defined the roles and can access them in one single way.

[Former user]

External role definition

This is the definition suggested by Satomi, continued by Marine and looking also similar to the example of Odessa. The idea was to use a separate folder for all the role folders. The internal role definition would be the one used above when the roles are defined together with the items taking the roles.

However, as long we don't create a top-level sister folder to #RLV, the internal role definition can be mapped directly to the external definition system. With the sister folder probably too, but we try to leave that new folder inside #RLV.

We create a new folder ".[all]" directly in #RLV that takes all the roles of wearable's in the rest of #RLV. The system could be realized like in this example after we share our Black Kneel Boots:

  #RLV
    .[all]
      .[left foot]
        Black Kneel Boots
          Boot L Foot (link)
          Boot L Lower (link)
          Boot L Upper (link)
      .[right foot]
        Black Kneel Boots
          Boot R Foot (link)
          Boot R Lower (link)
          Boot R Upper (link)
      .[shoes]
        Black Kneel Boots
          Boots Base (link)
          Boot L Foot (link)
          Boot R Foot (link)
          Boot L Lower (link)
          Boot R Lower (link)
          Boot L Upper (link)
          Boot R Upper (link)
    Outfit
      Boots
        Black Kneel Boots
          Boots Base
          Boot L Foot (left foot)
          Boot R Foot (right foot)
          Boot L Lower (l lower leg)
          Boot R Lower (r lower leg)
          Boot L Upper (l upper leg)
          Boot R Upper (r upper leg)

As you can see here, we took the roles out of the item folder. Because we have really a lot outfits that define the same roles, we should not put the links directly into the role folders but organize them by final outfit name.

The difficulty here would be for the viewer probably to find a connection from the item folder into roles folder. Because...

Abstraction rule 3: Regardless how the roles are defined, the scripted access to them should be the same.

For example when the role is fragile by default or definition, to access the physical layer of Boot L Upper, we stil use the path "Outfit/Boots/Black Kneel Boots.l upper leg" or "Outfit/Boots/Black Kneel Boots.shoes.l upper leg" but not ".all.shoes/Black Kneel Boots.l upper leg".

Due abstraction the user of the viewer should have a full freedom how to define the roles and select the system they like the most or considers to be most useable in every situation while the devices accessing the roles would not notice the difference and have the same one way to control shared folders.

Scripted access

The outfit and attachment scanners will use the logical view automatically because the viewer registers the layer and attachment roles automatically when an outfit using that roles is worn. So stripping or locked a meshed shirt that used the slot "shirt" will be possible via @remoutfit:shirt without any changes on the side of the scripted device.

but to use the role system of shared folders, the scripts need to know the path to the role and probably the role structure. The role can be used (worn at time), it can be available, i.e. just defined if worn or not, and sometimes a script could want information only about the role using by a device that has the script and issued the access commands.

a) Revealing the role names

@getusedroles[:role]=channel number

This would give the names of roles used by worn wearable's. Is a role named, e.g. "@getusedroles:shoes=2222" than only the string "shoes" is answered when something is worn that using the shoe slot.

When multiple parent folders use this role, than the retrieved string will have "shoes" multiple times, e.g. "shoes,shoes" when we wear heels and boots at same time.

When the role is not specified, we get a list of all used roles at this time.

@getallroles[:role]=channel number

This answers a coma-separated string of all roles that are defined by the user.

Probably each role name could ba added a suffix telling if the role is not used, used completely, or partially. Also interesting to know if the role is fragile or solid. Something like this "shoes:NF" for "not used, fragile".

The result will be actually very long especially when we don't specify a role, hence only the role names should be resolved, no role paths.

@getthisrole=channel number

When the role is not specified, the response is name of the role used by the object issued this command. When the role is specified the response is either the role name or the empty string.

When this item does not belong to a role, the result will be an empty string.

b) Revealing the role path

We start from the example 2 (dress and boot example) wearing these two outfits:

• Dresses/Glamour/Black dress
• Shoes/Boots/Knee/Leather patent

@getusedrolepath[:role]=channel number

When a role is specified, retrieves a role path of the item using the role. For the example 2, requesting via "@getusedrolepath:shoes=222" would reveal the path "shoes/boots/knee/leather patent.shoes".

When more than one outfit is worn that uses role, than all paths would be in result.

When the role is not specified, paths for all worn outfit that register any role are in result.

@getallrolepath[:role]=channel number

This responds a list of all outfit paths that define this specified role. The string could be quite long already. Perhaps its worth to add a special suffix telling "this is the packet #5 of 8".

When we don't specify the role, the response will be definitely very long.

@getthisrolepath[:role]=channel number

This only responds the path to the role defined (and used) by the item that has issued the command. Similar to @getusedrolepath but we don't get multiple result even when the role is used by multiple outfits.

When this item does not belong to a role, the result will be just the path to the item in #RLV when it is there or an empty string.

c) Revealing role structure.

Only works when the role is fragile by definition or by default. The role structure can be only revealed by using this commands for other commands the role hides the structure so the whole group of physical slots appears as a single item using a single logical slot.

@getroleslots[:path]=channel number

When the role is fragile (by definition or by default), the result is the list of slots used physically by the role in specified path. For example issuing "@getroleslots:shoes/boots/knee/leather patent.shoes=2222" will result this list: "shoes,alpha,left foot, right foot".

When the role is solid, the result will be the logical slot used by the role, i.e. just the role name.

When the path is not specified, the result will be the same as connection of @getthisrolepath and @getroleslots, i.e. we receive the physical slots used by the role the item belongs to that issued the request.

When this item does not belong to a role, the result will be just the used physical slot.

The end

So far my definition ideas i've got.

[Marine Kelley]

Thank you for reviving the discussion, I just wanted to say it wasn't dropped at all, I'm still keeping that enhancement in my mind, but haven't come up with a solution yet (it's a tough problem). Don't despair, I really want to make something like this :)

[Former user]

Update

I don't think you dropped it Marine :) Since I can see you changed the priority to major. But the topic is really not easy to handle.

I have changed suggestion for scripted access a bit in the last post abive, so that the response no more depends on fragility of the role because this is a premise the script cannot know. Otherwise the result would confuse the scripts.

I hope that the suggestions helps to find the way to the right solution. Actually I am trying to show what we could need and how to reach that. I am using a syntax I've suggested, but the syntax is just a minor details. I think it can be adapted to any other as long the suggested way remain the same.

Secondly, I believe I have an extension to the idea. Basically it is a possibility to give a group more than one role (actually I thought its not needed but faced needs to do so) and also a need to hide the role from @getoutfit, @getattach and @getroles commands. Again, I am using the syntax from above but it must not be the final one, just for explanation.

Name convention

However, i would suggest that the role names can take only letters, space and underscore char. Numbers are not allowed (some devices may use numbers as index to distinguish the roles.) At least comma, period, colon, slash and assignment char are used for the RLV communication and should not appear in the role names.

For the next suggestion the chars "@", "/" and "&" have special meaning and are also not part of allowed role names.

Twin roles

Now, when I had freedom to decide, I had a big problem while giving the structure in the example 2 above, as I structured the Black dress (rem, the path was Dresses/Glamour/Black dress.) What role I give the dress, what legacy slot it has to use, shirt or jacket? First I decided for jacket but now I updated the example and changed to shirt.

A shirt is something for a blouse or perhaps a short summer dress. Jacket is also not good as we can wear one above the dress. Somehow we do not have a legacy layer for a dress, a combination of a shirt and a skirt.

Ok, why not give the dress both roles, shirt and skirt? We just put both in the square brackets and connect by coma:

  #RLV
    Dresses
      Glamour
        Black dress
          .[shirt,skirt]
            dress alpha
            Black dress (chest)

The result is this: We now created two twin roles, the same group of physical items takes now two (or more) roles and uses so the both specified logical slots. When one is locked ("@remoutfit:black dress.shirt=n") than the other is locked too.

Btw. the same effect we would achieve by defining two separate role folders and put links in one:

  #RLV
    Dresses
      Glamour
        Black dress
          .[shirt]
            dress alpha (link)
            Black dress (link)
          .[skirt]
            dress alpha
            Black dress (chest)

But we don't have to make links. We can also use nesting and let the abstraction to create the same structure for us:

  #RLV
    Dresses
      Glamour
        Black dress
          .[shirt]
            .[skirt]
              dress alpha
              Black dress (chest)

The small difference will be just that a script can access skirt role not only directly but also as a sub role of the shirt role, via "shirt.skirt". But this is a detail the script cannot know.

Nesting single roles makes the definition a bit more complicated than making twin roles but stil doable. But when possible, I'd prefer to have twins.

Well, this is just an example and as is, it is somewhat nonsense. No one will give a group two legacy roles. But how I came at all to the needs of making twin roles?

As I said before, we do not have a legacy layer for a dress. But now we can make user-defined roles. Why not create a role for all our dresses, gowns and alike? We call it also appropriately: ".[dress]". The full structure I will no more give, I think it is clear.

This role is fine but has a problem. When I am tied to a legacy bondage post, the post checks my outfit via @getoutfit and cannot see the dress. Only the modern magic wand of my miss uses @getroles and can see the dress. What to do?

The answer is simple: Make a twin roles with the old sister legacy shirt role and the young sister dress role: ".[shirt,dress]". Now the bondage post will see the dress as it is registered for @getoutfit and also the magic wand will see it.

Hidden roles

The solution above has a small snag: The magic wand will use @getroles and see both roles, shirt and dress. Miss gets two buttons for the same thing and probably would want to correct 'that mess' and strip off 'that invisible shirt'.

So, we need a way to hide the shirt role from @getroles when the command can see the dress role. The one way is to take as rule, when a twin role is defined containing a legacy role and an user-defined role, than the legacy role is hidden from @getroles commands.

This way the magic wand will only see the dress role and not the shirt role. The con to do it is that the user will have no freedom if to define a twin role or two nested roles.

I'd suggest here another way: When the role name starts by the char "@" than the role is hidden from @getroles commands but is visible to @getoutfit and @getattach commands (if it is a legacy role for sure.) This way we can decide freely if we define a twin role ".[@@shirt,dress]" or we nest the roles ".[@@shirt]" and ".[dress]".

Note: Bitbuket seems to interpret the leading @ char too so I had to tweak the text a little so that it looks close to what I wanted express.

Why I used the "@" char? I like a small syntax addition: The char "@" is a shorthand for ",@" when used in the middle of role name, i.e. the char is than a separator that splits the single word in two and is at same time the prefix for the following role name.

With this syntax I would define the twin role this way: ".[dress@shirt]" which means than "it is a dress worn at shirt layer" and defines the twins ".[dress,@@shirt]" implizitelly.

There are two other cases possible: The slash prefix "/" denotes a role that is hidden from @getoutfit and @getattach commands but is visible to the @getroles commands. The char is also a separator. With ".[jacket/shirt]" we define a twin while both layers are visible to the modern magic wand but only the jacket layer is visible to the legacy bondage post.

The char "&" is also a separator char and as prefix denotes the role invisible to all, @getroles, @getoutfit and @getattach commands. The role ".[jacket&shirt]" is in fact a twin while only the jacket role is visible to legacy bondage post and modern magic wand.

And without the prefix chars?

Yes, we can also define the same without using prefix chars. Instead, we will use role options. The prefix chars "@", "/" and "&" we replace by options "legacy", "extended" and "hidden" (again, just suggestion.)

This way we can replace this definition:

  #RLV
    Dresses
      Glamour
        Black dress
          .[dress@shirt]
            dress alpha
            Black dress (chest)

by this one:

  #RLV
    Dresses
      Glamour
        Black dress
          .[dress]
            .[shirt] legacy
              dress alpha
              Black dress (chest)

It is somehow like RISC and CISC. When you have large syntax the user must learn more but can have smaller structures. When you have smaller syntax, the user has to combine things and gets bigger structure but has less to learn.

[Former user]

There's a lot of good discussion on this issue, and has been for some time. However, I'm concerned. It's a very tough problem.

To get to the point where this is reliably available, it requires

• Some resolution here. It's a complicated problem.
• Implementation by Marine. These solutions are complex and I don't envy the job of doing the implementation work on making this actually happen at the code level.
• Adoption by RLVa (for all the non-Marine clients, bless their hearts). A lot of them are still stuck on the RLV 2.8 spec even, which is the highest I can reliably use.
• User education for how to re-organize their entire outfit collection
• Enough users actually taking the time to do that
• Device manufacturers writing strippers that take advantage of the new toys like @getrole etc.

Obviously that is the cleanest path. But I look at the date this was filed, the complexity of the proposals, and the list of things required to actually get it usable and I'm concerned.

I'm wondering if there's a hackish shortcut that would get me there faster. For example, it would be possible to write a "strip script" that would basically

• Scan the avatar at likely places (for "shoes", say--shoes, left foot, right foot, left lower leg, right lower leg)
• Do some kind of fuzzy logic that assumes elements in a set come from the same creator and/or have similar names
• Reach some kind of guess about what to strip for "shoes", do it, and then ask "did I get that right? y/n"
• In the wrong case, the user can then add/remove clothes to get a more reasonable interpretation of stripping "shoes"
• Scan the avi again and figure out the delta of what was removed
• Store the guids of your "shoes" in a web database somewhere
• In the future we get it right the first time, because now we know how to remove those shoes

This approach is kind of hackish and terrible, but it has the advantage that it's implementable now, without a lot of the adoption and trickledown of doing it "right", and it gets better over time as it learns. It also has the advantage that users don't have to up-front organize their whole inventory in a new system that they have to learn.

I'd obviously prefer to get a real solution at the RLV layer, but in the absence of that I wanted to suggest the vague outline of a backup plan that I'll be looking into if I can't figure out how to contribute meaningfully to a clean solution.