[BUG-229423] New LSL function: llWearFromInventoryTemp #7289
Comments
|
Kyle Linden commented at 2020-09-30T20:24:46Z Leaving open for comments and feedback. |
|
hatake.kohime commented at 2020-09-30T23:43:19Z As a mesh body user only some of the time, I think this would be a great feature to add. I know there are thousands of residents who rely on the outfits system already built into the viewer to change their looks, but sometimes one forgets to add that silly little alpha and suddenly you're inadvertently inappropriate. This would definitely go a long way in helping older mesh items that work with the system bodies to work a little more uniformly with the mesh ones. Shapes will vary, of course, but alphas will not. :) |
|
Anastasia Horngold commented at 2020-10-01T00:25:33Z Great idea. If I am reading this correctly, it would also allow the following use case: Instead of wearing a mesh clothing item AND its control HUD, the user could add just the HUD (which would then attach the mesh wearable). Thus only one item would have to be located and worn. Also, only the HUD would need to be saved in an outfit, reducing the number of links in inventory. |
|
Willow Wilder commented at 2020-10-01T01:11:18Z It's only the last month or two that I began to convert to BOM. As it stands now, I use a combination primarily because of the alpha cuts for clothing. I simply can't face going back to making/finding/wearing alpha layers once again for clothing when a HUD will do the job quickly and more efficiently. The above proposal sounds promising. |
|
Lucia Nightfire commented at 2020-10-02T16:21:03Z, updated at 2020-10-02T19:19:38Z The biggest problem with alpha masks is one I've mentioned repeatedly at the Server, CC & Oz's UG many times, they cannot always be used with combinations of clothing that overlap each other or combinations of clothing that leave exposed skin in between. This goes even with precise rigging/weighting to ensure 0 clipping. Alpha cuts on the body should be dictating "cutoff" and "overlap" areas, not clothing despite the illusion that custom alpha masks "might" somehow be more modular. Another issue LL seems to forget is we are now fully immersed in an ever prevalent environment of NO-MOD clothing for NO-MOD bodies. For reasons mentioned above, if creators put alpha masks in their no-mod clothing, are they going to also have to give end-users the option to allow or not allow "auto-masking"? This would defeat the purpose of the feature if users had to manually set this up per clothing or per outfit when auto-alpha and alpha by HUD methods already exist. This is another wishful thinking attempt at trying to eliminate the need for alpha cuts without making things more intuitive or convenient. IMHO, if LL truly wants to offer a feature to definitively get rid of the need for alpha cuts, implement and PERFECT the "tug and tuck" clothing feature Sansar had. Said feature would eliminate the need for alpha cuts with most fabric based clothing. A creator can then be more liberal in their rigging/weighting when designing clothing and not have to hard-rig/weight an entire piece for each popular mesh body on the market. At most, they may just have to rig/weight for the chest area and have this be the only variable per clothing piece. This area could be its own link. The rest of the clothing would auto-conform to a spec previously updated/saved by the user.
|
|
NeoBokrug Elytis commented at 2020-10-02T19:35:03Z How about instead of a string as input, a list as input? That way several clothes could be applied at once without looping through inventory. |
|
Anastasia Horngold commented at 2020-10-07T21:07:14Z, updated at 2020-10-08T20:54:29Z TL;DR: Allow feature to be disabled/modified on a given item. I'd suggest that the feature should also allow the purchaser (of a hypothetical piece of mesh clothing) to disable the scripted alphas for that item, since they might not like the way the maker has done it. Example: Maitreya bodies allow clothing makers to control their alpha cuts by script. I have one dress where the maker has alpha'd the body's legs to exactly the hemline, so that in many positions/angles it's obvious that the body's legs are chopped off there. I always have to redo the alpha cuts so that more of the legs are visible slightly up in the skirt—every time I put it on. I would not want the parallel situation to crop up with system alphas on hundreds of clothing items. Instead, I would want an interface to be available that allowed me to completely disable the system alpha or to substitute another of my choice from inventory. |
How would you like the feature to work?
Function: llWearFromInventoryTemp( string name )
llWearFromInventoryTemp attaches a single wearable(inventory type INVENTORY_CLOTHING) from the object's inventory to the avatar. This function must be called from an attachment and the avatar must have previously granted PERMISSION_ATTACH.
When the attachment containing this script is removed, the wearable is also removed from the avatar's appearance. The avatar may also manually remove the wearable through the viewer UI.
No inventory item is created for the wearable in the agent's inventory.
The "name" parameter is the name or UUID of a wearable in the attachment's inventory.
Why is this feature important to you? How would it benefit the community?
Mesh bodies used a system of alpha cuts to hide parts of the body that should be obscured by clothing. Alpha cuts were originally controlled through a HUD associated with the body. Clothing creators and body vendors then developed a system to automatically turn some of these alpha cuts on and off through a script in the clothing item.
BOM provides no similar mechanism. In order to hide parts of the body, the users must search through their inventory for an appropriate alpha layer and attach it or add it to the outfit manually.
This function will allow clothing creators to create BoM enabled clothing without forcing their consumers to search for the appropriate alpha layer.
Links
Duplicates
Original Jira Fields
The text was updated successfully, but these errors were encountered: