| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
|
| |
causing the simulator to continually request that they rebake
This is because the alpha texture is not in the cache, we must continue to have the fallback of looking for these and other persisted bakes in the asset service.
Relates to http://opensimulator.org/mantis/view.php?id=6927
|
| | |
|
| |
|
|
|
|
|
|
| |
details cannot be found.
This is causing many issues on OSGrid, possibly due to teleporting timing differences with simulators hosted in different places or HG teleports
Added a bit more logging for debug purposes.
See http://opensimulator.org/mantis/view.php?id=6939
|
| |
|
|
|
|
|
|
|
| |
- 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.
|
| |
|
|
|
|
|
|
|
|
|
|
| |
packet can be pulled out of LLClientView and moved to
AvatarFactory. The first pass at reusing textures (turned off by
default) is included. When reusing textures, if the baked textures
from a previous login are still in the asset service (which generally
means that they are in the simulator's cache) then the avatar will not
need to rebake. This is both a performance improvement (specifically
that an avatars baked textures do not need to be sent to other users
who have the old textures cached) and a resource improvement (don't
have to deal with duplicate bakes in the asset service cache).
|
| |
|
|
| |
with our own and add export permissions as well as a new definition for "All" as meaning "all conventional permissions" rather than "all possible permissions"
|
| |
|
|
|
|
|
|
| |
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.
|
| |
|
|
|
|
|
| |
rather than "corrupt"
Corrupt is misleading - it implies textures were uploaded but are not j2k valid.
The actual situation is that at least one required baked texture is not present.
|
| |
|
|
| |
HGAssetBroker doesn't try to save back to the avatar's originating region
|
| |
|
|
| |
automatically turns off any logging enabled between tests
|
| | |
|
| |
|
|
| |
grepping for remaining uses
|
| | |
|
| |
|
|
|
|
|
| |
with wearables. The fact that this hasn't caused problems earlier
suggests either that no one is using multiple layers of wearables or
that this code is useless because the assets are coming in with the
wearables request.
|
| | |
|
| |
|
|
| |
last commit 205f2326
|
| |
|
|
| |
AvatarFactoryModule.SetAppearance() for future use
|
| |
|
|
| |
seen on inter-simulator teleports where avatar baked textures are not available from the asset service.
|
| |
|
|
|
|
|
|
| |
the same simulator.
This involves a large amount of change in test scene setup code to allow test scenes to share shared modules
SetupScene is now an instance method that requires an instantiation of SceneHelpers, though other SceneHelpers methods are still static
May split these out into separate classes in the future.
|
| |
|
|
| |
Permanently comment out warnings about ScenePresence not being found - this is entirely expected if the avatar has alraedy logged out or left the scene.
|
| |
|
|
| |
Eliminated an extra newline in the console if the log line doesn't contain a category (example of a category: "[ASSETS]").
|
| |
|
|
| |
AvatarFactoryModule after an avatar's appearance has been succesfully changed and persisted (if the persist option is set).
|
| | |
|
| | |
|
| |
|
|
| |
texture ids were available for the rebake request
|
| |
|
|
|
|
|
|
| |
from the server end.
This is not as useful as it sounds, since you can only request rebakes for texture IDs already received.
In other words, if the viewer has never sent the server this information (which happens quite often) then it will have no effect.
Nonetheless, this is useful for diagnostic/debugging purposes.
|
| |
|
|
| |
This allows some logic simplification and allows an external caller to manually request rebakes even if textures are uploaded (future command).
|
| |
|
|
|
|
| |
after another thread had started it on QueueAppearanceSave() or *Send()
However, the window for this race is very small, and the next queued appearance save or send would restart the timer anyway.
|
| |
|
|
|
|
|
|
| |
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.
|
| |
|
|
|
|
|
|
| |
in the same thread rather than on another one.
The caller is already an async thread from LLClientView so this doesn't hold up the client.
However, launching on a separate thread does remove the effect of m_setAppearanceLock
This was potentially allowing two different SetAppearance threads to interfere with each other, though this probably rarely happens, if at all.
|
| | |
|
| |
|
|
|
|
|
|
|
| |
wrong avatar.
In AvatarFactoryModule.HandleAppearanceUpdateTimer(), we loop through appearance save and send requests and dispatch via a FireAndForget thread.
If there was more than one request in the save or send queue, then this led to a subtle race condition where the foreach loop would load in the next KeyValuePair before the thread was dispatched.
This gave the thread the wrong avatar ID, leaving some avatar appearance cloudy since appearance data was never sent.
This change loads the fields into local references so that this doesn't happen.
|
| |
|
|
| |
endings from previous commit.
|
| |
|
|
| |
scene presence by client ID.
|
| |
|
|
|
|
| |
AvatarFactoryModule.Initialize()
This is never null
|
| |
|
|
|
|
|
|
|
| |
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.
|
| |
|
|
|
|
| |
that same height in ScenePresence.
This prevents unnecessary work in the ODE module, though possibly that should be checking against same size sets itself
|
| |
|
|
|
|
|
|
|
|
|
|
| |
entries to make a newly created user appear as a non-cloud on viewer 2
Viewer 2 no longer contains the default avatar assets (i.e. "Ruth") that would appear if the user had insufficient body part/clothing entries.
Instead, avatars always appear as a cloud, which is a very bad experience for out-of-the-box OpenSim.
Default is currently off. My intention is to switch it on for standalone shortly.
This is not particularly flexible as "Ruth" is hardcoded, but this can change in the future, in co-ordination with the existing RemoteAdmin capabilities.
Need to fix creation of suitable entries for users created as estate owners on standalone.
Avatars still appear with spooky empty eyes, need to see if we can address this.
This commit adds a "Default Iris" to the library (thanks to Eirynne Sieyes from http://opensimulator.org/mantis/view.php?id=1461) which can be used.
|
| |
|
|
| |
SP.AddToPhysicalScene()
|
| |
|
|
|
| |
Assets have to be marked non-local as well as non-temporary to persist. This is now done.
Hopefully addresses http://opensimulator.org/mantis/view.php?id=5660
|
| |
|
|
| |
textures (which are already stored permanently)
|
| |
|
|
|
|
|
|
|
|
| |
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 seems to make more sense as we can get SP.ControllingClient
|
| | |
|
| | |
|
