Fine control of multi-clothing layers

[Satomi Ahn]

=== Summary === In v2.1+, @remoutfit and @getpath[new] target all worn instances of a wearable type, with no way to select only one of them. Let's try fixing this.

=== Detailed description === Since viewer 2.1, it is possible to have several items of clothing and several attached objects per spot. Unless #RLV folders are set in some particular way, it is currently impossible in RLV to just strip one item of one kind (one shirt, not all shirts, or one foot attachment, not all of them, and so on).

To address this, I suggest that

First:

@remoutfit (and its synonyms) should be extended for a second argument that would be the rank of the item worn on the spot. Aliases "top" and "bottom" would always point respectively to the lowest and highest ranks.

Examples: * @remoutfit:shirt;2=force -> removes the second shirt * @remoutfit:pants;top=force -> removes topmost pants * @remoutfit:underpants;bottom=n -> locks the bottommost underpants * @getpath:socks;3=1234 -> queries the folder that contains the third socks, asks for the result to be sent on channel 1234

Second:

A new @getoutfit command (@getlayers? @getoutfitnew? <- meh!) should return the same as @getoutfit, but instead of 0 or 1, for each layer, it would give the exact number of items worn on that spot (maybe capped to 9?).

OR

A command like @getoutfitnames (à la Kitty) should be added that would return a list such as "Socks;1,Sock;2,Pants;1,Shirt;1.... ".

=== Objections === * Attachments have the same problem as clothing layers, but no obvious way to tell one attachment from another when worn on the same spot (internally in the viewer, they have integer ranks but the user has no way to guess them). Unlike clothing layers, there is no obvious visible layering.

So some other proposal will be needed for attachments (which does not mean we should drop this one!)

• I am not very fond of the idea of naming parts you want to detach after the official attachment point name of wearable type name, for the following obvious reasons: # several concrete items of clothing of different nature could attach to a same spot name # conversely a concrete clothing item typically consists of several SL inventory items # internal names of the viewer do not reflect the actual nature of the clothing item # when you see an avatar, there is noway to know where something worn by the avatar belongs (is the collar attached on chest or spine? and the skirt, pelvis or stomach? ... )

=== Distant future === The latter is actually more an objection against the whole @[add|rem][outfit|attach] business more than against this very extension proposal.

Indeed I believe another proposal is needed to create a notion of virtual clothing item, which would map a name (visible to RLV scripts) to a list of actual inventory items. This could take ideas from the current #RLV system + Kitty's composite folders + LL's aborted Ensembles (but off-topic for this ticket!).

Anyway, despite the shortcomings of @[add|rem][outfit|attach], my opinion is that these commands are needed because they make it possible to use RLV without having to set up your inventory in some particular way beforehand. So I maintain this proposal :).

=== Complementary proposal ===

There is a way to obtain the same feature such that existing scripts can benefit from it with no change.

The idea is the following: have @getinv and @getinvworn show a virtual folder called "Worn", whose contents would be the list of worn layers (and attachments, why not?) with their layering ranks. Scripts who can already browse #RLV would then be able to browse single clothing items.

Folder locking commands should then work the obvious way, by locking individual clothing layers.

[Marine Kelley]

Thanks for the proposal Satomi. Yes for now the RLV is incapable of distinguishing which piece of clothing is worn on which other piece of clothing, on any given layer. And yes although clothes and attachments should be handled the same way in the viewer, unfortunately they're not.

To me the root issue is not so much a missing command, but missing layers and attachment points. In a way, having 5 "shirt" layers (or 10 in my RLV) is like having "shirt", "shirt2", ..., "shirtN" virtual layers exactly like Phoenix used to handle multiple layers before LL decided to implement their owns.

So maybe instead of adding new commands, how about adding new virtual layers and call them in the existing ones ? The RLV could even be clever and provide a few shortcuts for "the outer piece of clothing", "the inner piece of clothing", things like that.

Now, as to find out what it means to have an attachment "over" another... I would tend to follow the same idea of virtual attach points but maybe with different meanings.

But the real real issue is that the RLV does not provide the names of the items worn, only the folders they are in. This is on purpose because :

1. The names are meaningless, they can be changed, they can contain strange words or be too long.

2. The owner might not want to let a script know what they are wearing.

3. Clothes and attachments most of the time are useless alone, they are to be worn as outfits, i.e. folders. If the owner wants to expose an item, they can do so by putting it alone in its own folder, that they name the way they like. At the end of the day, they must be in control of their inventory.

Edit : I realize this is pretty much what you meant by adding a parameter to @remoutfit, but the idea of "virtual layers" extends the idea to whatever command that handles layers, even future ones.

[Satomi Ahn]

Virtual layers were kinda off-topic. I just wanted to mention I was thinking about submitting another proposal later on, but let us keep them out of this discussion now :).

I think that by saying "names are meaningless" you pointed to something important: it should not matter if the layer you want to strip is called jacket, shirt or undershirt, but rather where it stands in the layering, since the same visual aspect can be obtained by stacking 1 undershirt + 2 shirts and by stacking 3 jackets, for instance.

What about some fake names like @remoutfit:X=force, where X is a number, meaning Xth outermost layer? Maybe we need to distinguish between the different areas of the avatar though (there are 5 baked textures on an SL avatar: top, bottom, skirt, face and eyes... obviously eyes are not needed as an area, because you cannot layer only one item on eyes). So it would yield commands like @remoutfit:top4=force,remoutfit:bottom1=force,....

Items jackets and tattoos cover several avatar areas and thus can be targeted in several ways.

[Satomi Ahn]

Other problem to take care of: if I say @remoutfit:layer3=n, then @remoutfit:layer2=force... the item that is actually locked should still be the one that formerly was on layer3, even though it is now on layer2.

So... it's more complicated than it looks like.

Maybe @getlayers should return a list of uuids with emplacements (like top2, bottom3, ... ), so that you can lock (@remoutfit:X=n) items by uuid, while knowing to what layer they correspond at the time you issue the command.

For @addoutfit:X=n locking, it's about forbidding adding to an existing spot, whatever the actual item UUID, so it won't be needed.