| Age | Commit message (Collapse) | Author |
|---|
|
observer list automatically
Preliminary work to clean up naming conventions.
|
|
|
|
UI up to date with multiwearables.
code reviewed by Seraph and Vir.
|
|
|
|
Moved LLLibraryOutfitsFetch and LLInitialWearablesFetch
|
|
|
|
Moved all the LLInventoryModelCOllectFunctors from LLInventoryModel to LLInventoryFunctions
|
|
cleaning up a merge conflict where HG didn't quite do the right thing.
|
|
|
|
Fixed several areas of code that were not multi-wearables enabled.
Specifically allowed for the wearing of created outfits that had links to
multiple items of the same type. Such outfits can be created by dragging
multiple items of the same type into an unworn outfit folder. When you
wear the outfit, all items (up to 5 per type) should be worn. Does not
affect right-click options or other buttons.
Code reviewed by Vir.
|
|
Superficial cleanup to change all typedef std::vector<LLUUID> to use a common typedef uuid_vec_t instead.
|
|
|
|
Superficial cleanup to replace all instances of "gAgentAvatar" with "gAgentAvatarp".
|
|
Superficial cleanup to replace all instances of "LLVOAvatarSelf *avatarp = gAgent.getAvatarObject" with "gAgentAvatar".
|
|
|
|
|
|
Superficial cleanup so that all instances of gAgent.getAvatarObject() use "LLVOAvatarSelf *avatarp = gAgent.getAvatarObject".
|
|
Lots of superficial cleanup, particularly around "if (" formatting.
Removed LLAgent as a friend of LLAgentCamera and refactored to use accessors.
|
|
|
|
Minor superficial cleanup to have all references to getAvatarObject use LLVOAvatarSelf *avatarp = gAgent.getAvatarObject()
|
|
Removed mAvatarObject / gAgentWearables.mAvatarObject since it's redundant with gAgent.mAvatarObject.
|
|
First check-in; only compiles, nothing more.
|
|
|
|
|
|
Since multiple inventory items can refer to the same asset ID, we needed to
revert changes to old_wearable (indexed by asset ID) after saving changes
made to a wearable to a new asset ID. This prevents user confusion around
unsaved changes.
Code reviewed by vir.
|
|
bold as (worn) when only one is actually worn"
Simple special-case fix for this specific issue, although I added a comment to llwearablelist.h that eventually the whole LLWearableList class will need some redesign.
Core issue is that you can have multiple itemIDs pointing to the same assetID and LLWearableList doesn't account for this possibility during lookup-wearable-by-assetID operations.
|
|
|
|
Added code to suppress local composite updates while wearables are loaded. This
makes sure that we don't update your appearance until all your wearables are
added to gAgentWearables. Hackish for 2.0, but will be inherently better for 2.1
code reviewed by vir.
|
|
Demo code, will get cleaned up / extended through future work on the project - just need to check it in to collaborate.
|
|
EXT-5673 : Autopopulation: Created outfits copy subfolder contents as well as immediate folder contents
EXT-5632 : Autopopulation is including subfolders even if those aren't outfits
DEV-46683 : Post-Deployment Cleanup
This is a series of changes to fix autopopulation behavior that was broken due to the new surprise web avatar deploy. That deploy surfaced a number of serious issues with the original AP code. I did not write this code and the person who did is no longer here, so I've done my best to fix those issues up.
This is a fairly comprehensive set of changes, but it's necessary given the poor state of the pre-existing code and how many problems it caused the new web avatar deploy.
This new version of the AP code will:
(1) Look for a Library->Clothing->Initial Outfits folder and use that if it exists
(2) Not create outfits out of folders that aren't complete outfits
(3) No longer string match against "More Outfits" in order to ignore outfits
(4) No longer recursively collect folder contents when creating an outfit (i.e. will only look at direct descendents)
|
|
createStandardWearables() now COF-based
|
|
|
|
|
|
|
|
|
|
We were pushing off redrawing your local texture composite
while waiting for a baked texture cache response from the server.
If this happens when your textures come in, your avatar will de-cloud
but the composite will not update, resulting in nudity.
Changed the logic so we will re-generate a local composite even if
we have a pending baked texture query (we still suppress uploading the
composite until a response is received). Verified several times that this does
fix the issue. Will update the JIRA with reliable repro.
Q verified issue is worthy of a hotfix checkin
Code has been reviewed by vir, bigpapi, and seraph
This is necessary for new user experience. Patch should be contained enough to be low-risk. Contact Nyx if any further questions.
|
|
|
|
|
|
Moved autopopulate to after avatar appearance resolves
|
|
Checker: REVERSE_INULL
Function: LLAgentWearables::setWearableOutfit(const LLDynamicArray<LLPointer<LLInventoryItem>, (int)32> &, LLDynamicArray<LLWearable *, (int)32>&, int)
File: /indra/newview/llagentwearables.cpp
|
|
Checker: REVERSE_INULL
Function: LLAgentWearables::setWearableOutfit(const LLDynamicArray<LLPointer<LLInventoryItem>, (int)32> &, LLDynamicArray<LLWearable *, (int)32>&, int)
File: /indra/newview/llagentwearables.cpp
|
|
changed logic of the save as button to copy a link from the newly created
inventory item to the current outfit folder. This makes your changes
persist on relog.
Reviewed by Vir.
|
|
Checker: NULL_RETURNS
Function: LLAgentWearables::makeNewOutfit(const std::basic_string<char, std::char_traits<char>, std::allocator<char>>&, const LLDynamicArray<int, (int)32> &, const LLDynamicArray<int, (int)32> &, int)
File: /indra/newview/llagentwearables.cpp
|
|
Checker: FORWARD_NULL
Function: LLAgentWearables::setWearableOutfit(const LLDynamicArray<LLPointer<LLInventoryItem>, (int)32> &, LLDynamicArray<LLWearable *, (int)32>&, int)
File: /indra/newview/llagentwearables.cpp
|
|
|
|
|
|
work in progress.
|
|
|
|
they can get a sense of their contents.
Also moved the My Outfits autopopulation from the library out of where it was done before (as a result of
initial wearables message) to be done in the idle login during the precaching state.
-Reviewed by Nyx
|
|
|
