| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| | |
|
| |
|
|
|
|
|
|
|
| |
- Parts of region crossing code
- New bakes handling code
- Bakes now sent from sim to sim without central storage
- Appearance handling changes
- Some changes to sitting
- A number of unrelated fixes and improvements
|
| |
|
|
|
|
|
|
|
|
| |
hashes for the purpose of accurately responding to AgentTextureCached
packets. There is a change to IClientAPI to report the wearbles hashes
that come in through the SetAppearance packet. Added storage of the
texture hashes in the appearance. While these are added to the
Pack/Unpack (with support for missing values) routines (which means
Simian will store them properly), they are not currently persisted in
Robust.
|
| |
|
|
|
|
|
|
| |
AvatarAppearance
It looks like this was happening when AttachmentsModule.RezAttachments was doing a secondary set of each attachment to update with the asset ID (initially they only have the inventory ID).
However, with multi-attach this was appending a second copy of the same attachment rather than updating the data that was already there.
This commit requires both simulator and service to be updated.
|
| | |
|
| |
|
|
|
|
|
|
| |
AvatarFactoryModule from AppearanceInfoModule so that it can be used in debug (inactive).
Further filters "debug packet <level>" to exclused [Request]ObjectPropertiesFamily if level is below 25.
Adjust some method doc
Minor changes to some logging messages.
|
| |
|
|
| |
Author: Mana Janus <mana@mjm-labs.com>
|
| |
|
|
|
|
|
|
|
| |
When a slider parameter is changed, the viewer uploads a new shape (or other asset) and the item is updated to point to it.
Viewer 1 uploaded the data in the initial request itself, so the asset references was almost always correctly updated.
However, viewer 3/2 always uploads data in a subsequent xfer, which exposed a race condition where the viewer would make the item update before the asset had uploaded.
This commit shuffles the order of operations to avoid this race, the item is updated with the new asset id instead of the old one while the upload was still taking place.
A second race had to be fixed where avatar appearance would also be updated with the old asset id rather than the new one.
This was fixed by updating the avatar appearance ids when the appearance was actually saved, rather than when the wearables update was made.
|
| |
|
|
| |
This is partly to address http://opensimulator.org/mantis/view.php?id=5644, though something more thorough is needed.
|
| |
|
|
|
|
|
|
|
|
|
| |
rather than abort.
When a user logs in, the attachment item ids are pulled from persistence in the Avatars table. However,
the asset ids are not saved. When the avatar enters a simulator the attachments are set again. If
we simply perform an item check then the asset ids (which are now present) are never set, and NPC attachments
later fail unless the attachment is detached and reattached.
Hopefully resolves part of http://opensimulator.org/mantis/view.php?id=5653
|
| |
|
|
| |
The second was already being filtered out so this has no user level effect
|
| |
|
|
|
|
|
| |
This was happening because we were using the source avatar's item IDs in the clone appearance.
Switch to using the asset IDs of attachments instead for NPCs.
The InventoryAccessModule and AttachmentModule had to be changed to allow rezzing of an object without an associated inventory item.
Hopefully goes some way towards resolving http://opensimulator.org/mantis/view.php?id=5653
|
| |
|
|
| |
If the inventory service is configured not to allow deletion then these will not disappear from inventory
|
| |
|
|
| |
This executes the callback on the same thread that made the request. Designed for use only by regression tests that rely on a predicable event ordering.
|
| |
|
|
|
|
|
|
|
|
| |
storage.
This works by serializing and deserializing NPC AvatarAppearance to a notecard in the prim inventory and making the required baked textures permanent.
By using notecards, we avoid lots of awkward, technical and user-unfriendly issues concerning retaining asset references and creating a new asset type.
Notecards also allow different appearances to be swapped and manipulated easily.
This also allows stored NPC appearances to work transparently with OARs/IARs since the UUID scan will pick up and store the necessary references from the notecard text.
This works in my basic test but is not at all ready for user use or bug reporting yet.
|
| |
|
|
| |
This is not used for anything - appearances are always properties of objects with ids (ScenePresence, AgentCircuitData) and just has the potential to get out of sync when the appearance is cloned.
|
| |
|
|
|
|
| |
Had to stop using AvatarService for now since it doesn't store baked texture IDs (which is why this was failing).
Also failing because cloning appearance was also cloning the AvatarApperance.Owner field, which we weren't then changing.
Extended TestCreate() to check this.
|
| |
|
|
| |
Signed-off-by: root <root@grid00001.t-data.com>
|
| |
|
|
|
|
|
| |
enters a region the attachments module tries to update the
appearance with attachments that are already part of the appearance.
Just added a check to only save if the attachments weren't there
before.
|
| |
|
|
|
|
| |
and vparams when appearance is not cached and when wearables change. Send appearance to the viewer with initial data.
Cleaned up (and added) debugging.
|
| | |
|
| | |
|
| |
|
|
|
|
| |
This will cause visual params to be persisted along with worn items. With
this, alpha and tattoo laters will be saved. Multiple layers MAY work, but
not tested because I don't use Viewer 2.
|
| |
|
|
|
| |
tattoo and alpha layers. Any change of appearance in the sim makes the green
gnome reappear on next login. Progress of sorts.
|
| |
|
|
| |
client displays a blank error box.
|
| |\ |
|
| | |
| |
| |
| | |
commenting out most of them as per Mic
|
| |/
|
|
|
|
|
|
|
| |
It contains a major interface version bump and will NOT work with earlier grid
services. This is preliminary work that will lead to layers support.
Rest appearance services are commented out completely, they will have to be
adapted by someone who actually uses them. Remote admin is working, but has
no layers support. There is no layers support in the database. Login likely
won't work. You have been warned.
|
| |\ |
|
| | |
| |
| |
| |
| | |
and avatar data are sent. And the number of times they
are stored.
|
| | |
| |
| |
| |
| |
| |
| | |
to accommodate batching of the many updates that happen on login
and teleport.
Fixed handling of the serial property in appearance.
|
| | |
| |
| |
| |
| |
| | |
old data works. Teleport out of a new region with old data works.
Teleport into a new region with old data does not trigger the
necessary rebake.
|
| | |
| |
| |
| |
| |
| |
| | |
The attachment code appears to work correctly for 1.23 viewers so, in
spite of some big changes in the internal representation, there don't
appear to be regressions. That being said, I still can't get a viewer2
avatar to show correctly.
|
| |/ |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
AvatarService -- add two new methods, GetAppearance and SetAppearance
to get around the lossy encoding in AvatarData. Preseve the old
functions to avoid changing the behavior for ROBUST services.
AvatarAppearance -- major refactor, moved the various encoding
methods used by AgentCircuitData, ClientAgentUpdate and
ScenePresence into one location. Changed initialization.
AvatarAttachments -- added a class specifically to handle
attachments in preparation for additional functionality
that will be needed for viewer 2.
AvatarFactory -- removed a number of unused or methods duplicated
in other locations. Moved in all appearance event handling from
ScenePresence. Required a change to IClientAPI that propogated
throughout all the IClientAPI implementations.
|
| |\
| |
| |
| | |
This brings presence-refactor up to master again
|
| | | |
|
| |\ \
| |/ |
|
| | |
| |
| |
| |
| |
| |
| |
| | |
Fixes: Undo, T-pose of others on login, modifiedBulletX works again, feet now stand on the ground instead of in the ground, adds checks to CombatModule. Adds: Redo, Land Undo, checks to agentUpdate (so one can not fall off of a region), more vehicle parts. Finishes almost all of LSL (1 function left, 2 events).
Direct flames and kudos to Revolution, please
Signed-off-by: Melanie <melanie@t-data.com>
|
| | |
| |
| |
| |
| |
| |
| | |
This resolves the problem where eyes and hair would turn white on standalone configurations
When a client receives body part information, for some insane reason or other it always ends up uploading this back to the server and then immediately re-requesting it.
This should have been okay since we stored that asset in cache. However, the standalone asset service connector was not checking this cache properly, so every time the client made the request for the asset it has just loaded it would get a big fat null back in the face, causing it to make clothes and hair white.
This bug did not affect grids since they use a different service connector.
|
| |/
|
|
| |
Appearance is now being passed with AgentCircuitData, as it should be.
|
| |
|
|
| |
appearing as a cloud
|
| |
|
|
|
|
|
| |
unnecessary serialization/deserialization of TextureEntry objects and allow TextureEntry to be inspected for missing bakes
* Inspect incoming TextureEntry updates for bakes that do not exist on the simulator and request the missing textures
* Properly handle appearance updates that do not have a TextureEntry set
|
| |
|
|
| |
http://opensimulator.org/mantis/view.php?id=4040 by jhurliman. The patch didn't match up, so I winged it here. My effort to manually merge the patch seems to make sense, so I'm going to commit it.
|
| |
|
|
| |
valid TextureEntry. About half the time update_avatar_appearance calls are made, the TextureEntry is empty
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
| |
the documentation.
* Automatically generated using the BuildVisualParamsEnum Method that gets data from the libOMV VisualParams NameValue definitions which they generate from the the avatar_lad.xml file
* Want to know what element controls the eye size, jowls. pointy ears? no problem.
|
| |
|
|
| |
LICENSE.txt.
|
| |
|
|
|
|
|
| |
clothes and attachments that the target avatar is wearing, to begin with, are removed. So the end result isn't a merger of those clothes/attachments and the ones the template avatar is wearing.
Added IPAddress ListenIPAddress property to BaseHttpServer so that the listening/binding IP can be set.
|
