| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
| |
of sim freeze? -- HandleRequestImage in LLClientView is now sync, which means that it cannot take too long to complete. However, its execution path may end up in J2KDecoderModule.Decode, which is heavy and could stop the packet processing thread while it's at it.
|
| |
|
|
| |
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"
|
| | |
|
| |
|
|
| |
Make it clear that transaction parameter to HandleUDPUploadRequest is an ID.
|
| |
|
|
|
|
|
|
|
| |
sends an asset transaciton but it is empty. So we can't ignore name data
when a transaction is present and can't treat every transaction as valid.
Conflicts:
OpenSim/Region/Framework/Scenes/Scene.Inventory.cs
|
| | |
|
| | |
|
| |
|
|
| |
grepping for remaining uses
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
| |
an UploadAsset request could throw an exception because m_asset did not yet exist.
This was accidentally introduced in 4fc0cfb
This commit also consistently removes the AssetXferUploader when the transaction completes, no matter if it completed on asset upload or item operation.
The amount of data being retained was small, since this was clothing/bodypart metadata in the asset rather than textures themselves.
|
| |
|
|
|
| |
This was only used if none of new item, update item or update task item had been set.
But since all transactions go through these paths this old code is redundant.
|
| |
|
|
|
|
|
| |
UploadAsset() to prevent item creation failure when NewInventoryItem thread reachs the object first.
This was preventing the previous race condition fix in 4fc0cfb from actually working.
This commit also removes some of the pointless transaction id checks - these conditions are already being enforced in AgentAssetsTransactions.
|
| |
|
|
|
|
|
| |
user item and update user item mechanisms
This is done for consistency and to allow removal or some access methods that increase code complexity.
However, this path has not been used for a long time, not even by LL 1.23 - viewers use caps http upload for this instead
|
| |
|
|
|
|
|
|
|
| |
in the viewer or updating existing assets.
On creating these items, the viewer sends a UDP AssetUploadRequest followed by a CreateInventoryItem.
It was possible for the CreateInventoryItem/UpdateInventoryItem to occasionally outrace the AssetUploadRequest and fail to find an initialized Xfer object, at which point the item create would fail.
So instead we always set up a Xfer object on either the asset or inventory item update request.
This does not introduce a new race because code already exists to delay the item operation until the asset is uploaded if necessary (but this only worked if the xfer object already existed)
|
| |
|
|
| |
Also change code to grab the agent asset transaction module once.
|
| |
|
|
| |
creations and getting contacted from other grids. Incoming HyperGrid teleports can also be restricted to local users.
|
| |
|
|
| |
agent id anyway
|
| |
|
|
| |
decoded, instead of just success/failure
|
| |
|
|
|
|
| |
JPEG2000 decode of an asset
For debugging purposes.
|
| |
|
|
| |
image manager (udp texture fetch). No significant functional changes.
|
| |
|
|
| |
hunting. No functional changes.
|
| | |
|
| |
|
|
|
|
|
|
|
| |
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.
|
| |
|
|
| |
a newly created CoreModules/Caps. Not all.
|
| |
|
|
|
|
| |
Addresses http://opensimulator.org/mantis/view.php?id=5444
Fix is to stop the asset transaction calling UpdateInventoryItem() since the caller is doing it anyway, which is more correct.
This did not effect scripts.
|
| | |
|
| |
|
|
| |
show caps
|
| | |
|
| |
|
|
|
|
|
|
|
| |
the server settings.
This is in a very crude state, currently.
The LindenUDPModule was renamed LindenUDPInfoModule and moved to OptionalModules
OptionalModules was given a direct reference to OpenSim.Region.ClientStack.LindenUDP so that it can inspect specific LindenUDP settings without having to generalize those to all client views (some of which may have no concept of the settings involved).
This might be ess messy if OpenSim.Region.ClientStack.LindenUDP were a region module instead, like MXP, IRC and NPC
|
| | |
|
| |
|
|
| |
client stack uses modules in the same way that scene does - through their interfaces
|
| | |
|
| |
|
|
| |
so that it makes sure that the file is added to Xfer's before it signals the client to come and get it. This allows the simplification of the logic of Xfer's.
|
| |
|
|
|
|
| |
keeping track of time. Simply handle the issues, which are: (1) rapid double requests from the viewer for the same file; (2) sometimes the file generation takes too long and the Xfer request arrives at the XferModule before the file name is added.
This still has debug messages commented out, in case this needs more debugging. Pushing it so others can test.
|
| |\ |
|
| | |
| |
| |
| | |
transfers just don't start without it. Observed my Nebadon and yours truly.
|
| |/
|
|
| |
which now lives entirely in LindenUDP space.
|
| |
|
|
| |
inventory requests, which apparently are happening and may cause race conditions if the file name is removed after the first transfer.
|
| |
|
|
|
|
| |
* Adds an item that checks to see if the top request has been there for longer then 30 seconds without an update and sends an AbortXfer if it encounters one. This allows the client to cancel the Xfer on it's side so you can re-select the prim and get the inventory when it fails the first time.
* Some interesting locking... Using NewFiles to lock the rest of them. We'll see how that goes.
* The goal of this is to ensure that Xfers are restartable when they fail. The client will not do that on it's own.
|
| |
|
|
| |
random rather than using IDs known by the client ahead of time.
|
| |
|
|
|
|
|
| |
Refactor to remove the property "MyScene" and the pointless circular
refs to the managing classes. Converted the module to a non-shared module.
Reformatted source for 80 columns. Removed the special role the module
had in the old loader.
|
| |
|
|
|
|
|
| |
folder up from connectors into Scene.Inventory.cs
This fixes the problem for all architectures (hg as well as local and grid) and means we don't have to dupe code between connectors.
Not ideal in that it becomes non-modular, but methods in Scene.Inventory.cs should eventually be modularized anyway.
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
|
| |
owner, if the notecard is saved by a permitted group member
This means moving the alert up to a place where the IClientAPI is available.
One can also argue that such client messages shouldn't be sent directly from the scene data model
|
