| Commit message (Collapse) | Author | Files | Lines |
|---|
|
|
|
|
|
|
|
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.
|
|
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.
|
|
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.
|
|
En_US so that a different culture doesn't save values with commas as decimal points, etc.
This will hopefully stop giants stalking the grid.
See http://opensimulator.org/mantis/view.php?id=5614
|
|
the texture was changed
|
|
Signed-off-by: root <root@grid00001.t-data.com>
|
|
|
|
AvatarFactoryModule.SetAppearance()
Baked texture set not yet checked, nor persistence of data in avatar service
This is a foundation for later npc related tests.
|
|
This now creates an avatar but appearance is always cloudy.
Move doesn't work.
Really, creating an NPC should only involve a ScenePresence rather than doing anything with IClientAPI, since an NPC has no viewer to communicate with!
|
|
At the moment, this command just asks the AvatarFactory to perform the existing baked texture check for each avatar in the simulator and returns "OK" or "corrupt".
This is for debugging purposes
|
|
|
|
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.
|
|
for now
|
|
and vparams when appearance is not cached and when wearables change. Send appearance to the viewer with initial data.
Cleaned up (and added) debugging.
|
|
into "one-to-many" and "many-to-one" makes it possible to call the right function on presence creation (both child and root) and when a child agent is promoted to root. This brings the total number of appearance sends down to one or two on login.
Cleaned up the avatar update calls in the groups code. Cleaned up
some commented and debugging code, and a few formating fixes.
|
|
fix some of the appearance problems on osgrid. Also added a transaction lock on SetAppearance. This won't prevent concurrent access to Appearance but it will at least make sure each update completes.
Signed-off-by: Melanie <melanie@t-data.com>
|
|
|
|
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.
|
|
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.
|
