Age | Commit message (Collapse) | Author |
|
- Removed all sidetray dependencies and the sidetray itself.
- Also removed LLFloaterSidetrayTab and LLSidetrayListener as unused.
|
|
- Added xml for a new floater Appearance and registred it in the floaterreg
- Removed side tray dependencies
- Added static helper method: LLFloaterSidePanelContainer::getPanel
|
|
|
|
initial outfits copied on first login
reviewed by Stone
|
|
|
|
EXP-630 My appearance floater may be opened by SLApp
EXP-633 Search floater can be opened by SLApps
|
|
another avatar change to be initiated
|
|
|
|
|
|
Enabled the "Replace Current Outfit" option for incomplete outfits (i.e. those that don't contain full set of body parts).
|
|
|
|
onIdle functions to llcallbacklist.
|
|
|
|
|
|
Outfit" in My Appearance SP).
|
|
|
|
Single attachment request are now batched up and sent all at once as a single message.
|
|
LLAppearanceMgr::updateClothingOrderingInfo.
I couldn't reproduce the problem (it has happened for only two users, both running MacOSX),
but from what I see in the logs, it might have been caused by (or related to) NULL COF items.
I haven't found out how they appear nor what exactly causes the crash, but just for any
case I added a check to make sure we don't try to update wearables ordering info for such items.
Reviewed by Sergey Litovchuk at https://codereview.productengine.com/secondlife/r/876/
--HG--
branch : product-engine
|
|
back-out the back-out for this branch. yay.
|
|
Backing out this merge that I pushed (prematurely) to the wrong place.
|
|
|
|
|
|
|
|
* EXT-8661 Take out unused mRegisteredAttachments in LLAppearanceMgr
Removed unused mRegisteredAttachments. Not sure what this was used for, but it's no longer used.
|
|
* EXT-8688 Automatically detach same object is detected
* EXT-8689 Cleanup detachAttachmentIntoInventory code
When an object arrives as an attachment, if it's already attached then it's automatically detached.
|
|
|
|
|
|
updateAppearanceFromCOF()
|
|
subsets of the current outfit.
We allowed wearing any outfit that contains non-worn items.
Now it appears to be wrong, therefore and I changed condition so that
we allow wearing any outfit (or folder) that contains the full set of body parts.
Reviewed by Sergey Litovchuk at https://codereview.productengine.com/secondlife/r/855/
--HG--
branch : product-engine
|
|
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
|
|
|
|
consisting of body parts only.
Changed the condition to enable the "Wear" button in My Outfits and the corresponding item in the outfit context menu.
They now get enabled for any outfit that isn't the base outfit and contains non-worn wearables.
By the way, did a minor cleanup: moved an LLAgentWearables.isCOFChangeInProgress() call to LLAppearanceMgr::getCanAddToCOF() to avoid code duplication.
Reviewed by Sergey Litovchuk at https://codereview.productengine.com/secondlife/r/832/
--HG--
branch : product-engine
|
|
feeeeling.
|
|
|
|
|
|
Reason:
When you click on a clothing link in COF, LLAppearanceMgr::wearItemOnAvatar() removes
all COF links of the clicked wearable type -- thus invalidating all previously
obtained LLViewerInventoryItems for those links -- and then passes such an
invalid item (item_to_wear) to addCOFItemLink() which of course crashes.
Fix:
1. Handle this case in wearItemOnAvatar(): don't try wearing COF items.
2. Disable the Wear button in the inventory SP when a COF item is selected.
3. Fixed get_can_item_be_worn() to return FALSE for items which are in COF or have links in COF.
Reviewed by Nyx at https://codereview.productengine.com/secondlife/r/811/
--HG--
branch : product-engine
|
|
|
|
Details:
1 Updated condition is item can be worn considering situation when item is copied in COF but is not worn.
2 Avoided code duplication in method LLOutfitsList::canWearSelected()
reviewed by Vadim Savchuk and Neal Orman at https://codereview.productengine.com/secondlife/r/785/
--HG--
branch : product-engine
|
|
|
|
|
|
|
|
|
|
appearance update until all links are created
|
|
|
|
|
|
|
|
Original patch merged poorly with a coverity cleanup, resulting in us not
passing the callback on to the proper functions for clothing (we did for
bodyparts). Added the callback and wearing clothing works again!
Code reviewed by Monroe
|
|
'Save' for outfit with non-link items.
- Added inventory collector functor to select items by their actual type.
- Fixed outfit "dirtiness" calculation so only link items are checked.
Reviewed by Neal Orman at https://codereview.productengine.com/secondlife/r/728/.
--HG--
branch : product-engine
|
|
|
|
Replacing logic with call to removeCOFItemLinks, which should do appropriate
checking to determine that item is in the COF and is actually a link.
Code reviewed by Seraph
|