Prevents the avatar's baked texture UUIDs sent by the server's first objectUpdate
message from being overwritten until the wearable cache results come back.
- Added xml for a new floater Appearance and registred it in the floaterreg
- Removed side tray dependencies
- Added static helper method: LLFloaterSidePanelContainer::getPanel
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.
- 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
Added additional logic to tell if you're in edit outfit mode, removed some bad code that was causing removed wearables to never send out an appearance update.
- Added common interface for My Outfits and Wearing tabs.
- Changed LLPanelOutfitsInventory to use common interface for My Outfits and Wearing tabs.
- Removed dependency on outfits side panel from inventory bridge context menus.
- Removed unused LLShowCreatedOutfit class from llagentwearables.cpp.
- Restored opening newly created outfit in My Outfits tab.
- Fixed worn items indication for Wearing tab items.
Revieved by Neal Orman at https://codereview.productengine.com/secondlife/r/604/.
--HG--
branch : product-engine
EXT-7929 FIXED Updated functionality of attaching object: loading indicator gets hidden when attaching is completed.
- Fixed crash when accessing singleton on application exit.
- Updated functionality of attaching object: loading indicator was not hidden.
* Reason: link to attachment was created without next appearance updating.
* Fix: passed "true" into LLAppearanceMgr::addCOFItemLink to call LLAppearanceMgr::updateAppearanceFromCOF when attachments is completed. (Like for clothing).
Reviewed by Vadim Savchuk at https://codereview.productengine.com/secondlife/r/611/
--HG--
branch : product-engine
* Outfit is loading for the first time
* After user clicks:
** Item Context menu > Add
** Item Context menu > Replace
Known Issues:
1. For multi-wearable indicator will disappear after first item from the batch is worn.
Did not fix this to not affect the stability before 2.1 release.
2. To show loading indicator first time we have to notify subscribers of LLAgentWearables.
For now this is done from the deprecated LLAgentWearables::processAgentInitialWearablesUpdate
Reviewed by Vadim Savchuk at https://codereview.productengine.com/secondlife/r/602/
--HG--
branch : product-engine
Implementation details:
* Added flag to LLAgentWearables to determining that outfit is changing. Synchronizing it with mLoadingStartedSignal and mLoadedSignal signals.
* Check this flag when there is no outfit set to show empty title when outfit is being changed.
* Also updated condition to disable "Wear" button when outfit is being changed.
Additional improvements:
* Removed reference to parent LLSidepanelAppearance from the LLPanelOutfitsInventory.
* Now LLSidepanelAppearance is subscribed to mLoadingStartedSignal and mLoadedSignal to update its loading indicator.
Known Issue:
* When new outfit is being worn its name is shown in title for a short moment (loading indicator is shown at this time). Then it is changed with an empty title and is shown when outfit is already worn.
If necessary it should be investigated and fixed in scope of another issue.
Reviewed by Vadim Savchuk at https://codereview.productengine.com/secondlife/r/593/
--HG--
branch : product-engine
Details:
* Added signal "Wearable Loading Started" in AgentWearables (in parallel with "Wearables Loaded")
* Now it is raised from the LLAppearanceMgr::wearInventoryCategory.
Reviewed by Vadim Savchuk and Neal Orman at https://codereview.productengine.com/secondlife/r/583/
--HG--
branch : product-engine
Brad Payne (Vir Linden)