Interesting proposal, and one probably worthy of further investigation.
My concern with this plan is that the conversion from one wearable type
to another is very much non-trivial. The wearable parameters (sleeve
length, etc) have no relation to each other between wearables. For
example, "sleeve length" for undershirts is visual parameter #603, which
"drives" parameters 1042 and 1043. For shirts, it is parameter #800
which "drives" 600, 1013, 1029, and 900.
You'd fundamentally be taking an existing wearable, and creating an
entirely new wearable of a different type based on that wearable.
Whether or not you save it back to your inventory as a different item,
you are essentially both copying it and modifying the wearable. What
happens if it is mod-able but no-copy? If you make changes to the
converted (undershirt) version and hit save, do you have to
back-translate those parameters back to the original (shirt)? I'd think
we'd need to create a new asset/inventory item of the converted type to
implement this idea, at which point permissions on the original are very
much a factor.
Could you do the math to do the conversion? probably. Would the result
be of acceptable quality? possibly. Would it be lossy in some cases?
definitely. Do I want to implement a conversion function that will
convert a wearable type to any other wearable type, including figuring
out (by examining all parameters in avatar_lad.xml) what parameters line
up with what other parameters for each possible conversion operation and
then translate those conversions into code? no, I'd *really* rather not.
But perhaps I'm overcomplicating the implementation of this idea somehow?
-Nyx
Kitty wrote:
>> Again, if any open source developer wants to look at the code
>> architecture and draw up a plan for how this can be done in a
>> reasonable amount of time, I'm all ears. My current ideas on
>> how to implement this would push us well out of the timeframe
>> that we were hoping to ship this set of features.
>>
>
> Could inventory links be used as a modifier for wearables rather than the
> current pass-through?
>
> I.e. an item on the shirt layer
>
> User right-clicks and picks "Wear as undershirt" which generates an
> inventory link in COF just as it does now, but with the lower two bytes of
> its item flags set to WT_UNDERSHIRT.
>
> The "onWearableArrived" would examine the inventory link to the wearable in
> COF, note the discrepancy on what it's being passed and convert the
> LLWearable to match the type specified in the link and everything else just
> works more or less the way it does now?
>
> It's not an ideal solution ("downgrading" jackets might get troublesome
> since they have two textures) but would allow arbitrary reordering of
> existing layers and since it's all handled by links "no modify" or "no copy"
> on the original wouldn't even come into it.
>
> Kitty
>
>
_______________________________________________
Policies and (un)subscribe information available here:
http://wiki.secondlife.com/wiki/OpenSource-Dev
Please read the policies before posting to keep unmoderated posting privileges
