Age | Commit message (Collapse) | Author |
|
|
|
and sb system is unavailable, to avoid stale appearance problems
|
|
|
|
|
|
boost::func equivalents
|
|
moved over:
isWearingWearableType
wearable::writeToAvatar
wearable::mTEMap (stores LocalTextureObject*)
more from wearable::import/export
wearable::createVisualParams, etc
|
|
llappearance/LLWearableData. Moved LLDriverParam into llappearance
|
|
|
|
|
|
|
|
|
|
per-region basis
Set up an architecture to minimize the use of the baked texture debug setting.
Instead concentrating on setting a per-region flag at the region handshake point.
This should be processed once the new regions are using the updated handshake.
The debug setting is being used in this one location as a placeholder.
Builds, but not fully tested/commented yet, passing this work off to Vir.
|
|
agentAppearance messages
If you're using the new pipeline, then we should not be requesting cached baked textures
from the simulator. Nor should we be sending agentAppearance messages to the simulator
(note: this may change in the future on region arrive)
|
|
|
|
|
|
|
|
simplifies llvoavatar and allows adding such tracking to classes that live outside the avatar lifetime
|
|
|
|
|
|
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.
|
|
|
|
toggling when default is INFO
|
|
|
|
|
|
bake-related logging
|
|
|
|
Use the new "Avatar Rez" debugging tag to see the output.
|
|
|
|
|
|
gesture copy to LLAppearangeMgr::onFirstFullyVisible().
|
|
- 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
|
|
actually remove all clothes.
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.
|
|
Recent Tab if that tab is open when item delivered
|
|
|
|
|
|
|
|
... and changed jira issue ID in comment to the current one
|
|
disconnected'
|
|
Fixed login issue that was causing multiattachments to be replaced instead of added.
|
|
screenspace metric.
Physics no longer removed when outfits changed.
|
|
were formerly in edit outfit.
Miscellaneous code cleanup.
|
|
back-out the back-out for this branch. yay.
|
|
Backing out this merge that I pushed (prematurely) to the wrong place.
|
|
|
|
Added debug setting for disabling physics.
Added disable-multiwear and disable-camera-reset to wearabletype.
|
|
|
|
|
|
- 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
|