I haven't investigated what the problem was, I've just rewritten the (ancient?) removal code
in the way we take off items in other places, i.e. by removing them from the Current Outfit forder.
Issues: Graphics preferences tab, lighting, depth of field
Issues: Color preferences tab, new direct chat
Issues: Build floater Mesh build tab
Issues: German translations of build, viewer menus
Issues: pipeline issues with mac, possibly other things
Issues: uploading content / temp content
Issues: Windlight quickprefs, parcel windlight, RLVa windlight
- fixed : LLAgentWearables::mInitialWearablesLoaded doesn't accurately reflect whether the initial wearables have actually loaded
-> if LL ever gets rid of all the legacy (mostly dead) code in llagentwearables.* we can just use mWearablesLoaded
--HG--
branch : Appearance-Misc
-> LLAgentWearables::userAttachMultipleAttachments() still had a reference to the now deprecated "MultipleAttachments" debug setting
--HG--
branch : RLVa
- fixed : LLAppearanceMgr::filterWearableItems() doesn't properly filter body parts
- fixed : LLWearableList::processGetAssetReply() creates multiple LLWearable instances for the same asset UUID
-> fix for http://jira.secondlife.com/browse/VWR-20608
- changed : deprecated removeItemFromAvatar() in favour of having LLAppearanceMgr::removeItemFromAvatar() handle it directly/correctly
-> wearables can't be worn/removed in 2.X without the viewer already having an LLWearable instance for it anyway
- added : InitialWearablesLoadedSignal signal which is emitted *once* when the initial wearables are loaded
- fixed : attachments sometimes detach only to instantly get reattached after logon
- added : LegacyMultiAttachmentSupport debug setting to route "secondary attachment points" to the primary attachment point
-> maps secondary attachment point range [39,68] onto [1,30]
-> only dislays "secondary attachment points" correctly for *other* avatars (by design)
--HG--
branch : Appearance-Misc
- EXT-8660 Cleanup ambiguous llviewerobject::set/getItemID code
Lots of files changed, but this is mostly just a trivial function call rename. This change is very low risk.
Done:
- 1. Dropped the obsolete "MultipleAttachments" setting.
- 2. Added an "Add" item to the following attachment-related context menus:
* My Appearance (ex-My Outfits) context menu.
* Edit Outfit -> Add More context menu.
* Object in-world context menu.
* Inventory context menu.
* Object inspector gear menu.
- 3. Modified "Attach To / Attach To HUD" to perform the "add" instead of "replace" action.
TODO:
- Ability to attach multiple objects at once from the Add More panel (bulk attach).
- Make sure there's no memleak when you click Wear/Attach in the in-world object context menu
and the callback isn't invoked (because e.g. avatar fails to get close enough to the object).
Issues:
0. I'm not sure whether LLAgentWearables::userAttachMultipleAttachments()
should replace attachments or add them. Assumed the former.
1. I couldn't verify that adding objects from the object inspector menu works
because I either could wear an object or see its inspector, not both.
2. > 1. Right-click on an object in your inventory and select "Wear".
> VERIFY: Attaches the object and replaces whatever's there; asks for
> confirmation before replacing an existing object.
I think this is impossible to implement because we don't know in advance
what point the object will be attached to, so we can't display a confirmation dialog.
Reviewed by Seraph at https://codereview.productengine.com/secondlife/r/843/
--HG--
branch : product-engine
Bug happened because name change was not explicitly listed as sufficient reason to save a wearable. So saving failed for alpha masks with only names changed.
Other wearables didn't have this problem because they passed precondition even if only name was changed thanking to checks that included visualparams.
- Made name change explicitly a sufficient reason to proceed with saving a wearable.
Reviewed by Neal Orman at https://codereview.productengine.com/secondlife/r/840/
--HG--
branch : product-engine
Arrehn