To get this to work, I had to disable the dupe link check I put in a couple of commits ago.
When the viewer adds wearables to an existing outfit, it first requests deletes of all the existing links before creating a new set.
Since these messages are async, the creates were being received before the deletes had a chance to complete, resulting in missing current outfit links.
However, the dupe check shouldn't be as important now that broken links have been fixed - it was the broken links that were causing the client to create dupes.
Tested on kokua 0.1.0 WIP and SL 2.6.3. I now have no problems managing outfits on my standalone.
It appears that if the viewer requests a folder containing links, we must also send the folders that contain the link targets first.
This was tested with Kokua 0.1.0 WIP though I predict it will also work with other viewer 2s
I believe this is safe since there is a 1-1 correspondence between link item and worn item (i.e. you can't be wearing the same item at two spots simultaneously in one outfit).
This should stop lots of duplicate links being created when viewer 2 is used.
However, this doesn't prevent broken inventory links, which I believe is timing related since the effect is not consistent (e.g. keep relogging and the viewer should end up seeing them correctly) . I think we actually see this problem on viewer 1 as well.
It might be easier just to implement the Fetch*2 inventory caps which are documented at http://wiki.secondlife.com/wiki/Inventory_API. WebFetch* has been deprecated by Linden Lab since viewer 2.5.1 and according to the sl wiki, "has numerous bugs".
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.
and currently used for all of an avatars attachments by the other
policies. Also changed the way items are pulled from the update queues
to bias close objects even more.
This should correct save all the assets required for the items within the coalesced objects in an IAR. This should also correctly gather the items on hypergrid takes.
per Melanie's very good suggestion. The immediate queue is
serviced completely before all others, making it a very good
place to put avatar updates & attachments.
Moved the priority queue out of the LLUDP directory and
into the framework. It is now a fairly general utility.
From pure code inspection, it looks like the uuid gatherer may get most asset uuids because the scene object serializer naively pulls non-root parts from all contained scene objects into one mega-object. However, root part uuids may well still be missing, and there may be other odd artifacts from this bug.
It appears that storing the size of the coalescence and the offsets is redundant, since one can work out this information from the position data already in the scene object groups.
to the entity update queue. The number of property packets can
become significant when selecting/deselecting large numbers of
objects.
This is experimental code.
This structure matches the existing one for SceneObjects and will allow code to be reused by the uuid gatherer, other tests, etc.
Test is not yet fully implemented due to a bug in rezzing coalesced objects where they all get the same name as the item.
Only one object should get the same name as the item, which appears to be the one selected last when the the objects were coalesced in the first place.
This bug will be addressed shortly.
This should happen if the client supplies a task ID with the RezObject call.
The rez goes through the same code as llRezObject(), so the same perms are applied.
Rotation isn't yet preserved, this should be fixed shortly.
This updates prim counts correctly if an object is moved by something other than an avatar (e.g. scripts, region modules)
Create TestMoveOwnerObject() regression test for this case.
However, the calls to the land management module to record prims need to remain, since they were also being used to return owner object lists, etc.
This is probably why prim counts were being done there in the first place.
This applies to adding/removing estate users, groups, managers and bans.
This is the application of the AllEstates_0.5.patch from http://opensimulator.org/mantis/view.php?id=5420
Thanks very much, Snoopy!
WARNING!!!!!
You can TAKE them, but you can't REZ them again. Only the first of the contained
objects will rez, the rest is inaccessible until rezzing them is implemented.
Also, rotations are not explicitly stored. This MAY work. Or not.
Added a prim counts test to reinforce this - shift-copy was no incrementing prim count. This will sometime become a basic scene test.
New code needs to be refactored so we just call SceneGraph.AddSceneObject(). This will happen in the near future.
With this, basic owner prim counts on a single parcel appear to be working fine (with the same previous existing taint calls as used by the land management module).
More work to do.
To do this, a new SceneObjectGroupsByFullID index in SceneGraph which just index's prims by their root part UUID, in order to avoid the inefficiency of filtering existing lists.
Existing callers to SceneGraph.ForEachSOG() did not fail due to the multiple per SOG action executions - they were probably just much less efficient.
Code suggests that no callers expected ForEachSOG() to execute actions on sog multiple times
In order to pass ILandObject into IClientAPI.SendLandProperties(), had to push ILandObject and IPrimCounts into OpenSim.Framework from OpenSim.Region.Framework.Interfaces, in order to avoid ci
Counts are showing odd behaviour at the moment, this will be addressed shortly.
OnParcelPrimCountAdd had the wrong semantics for the PrimCountModule - it was invoked for every entity in the scene, not just new ones, which would screw up the untainted count.
Extend automated test for this scenario.
This should resolve issues where the creator for rezzed objects was being shown as "Unknown user" where previous behaviour was to show the OSP resolved account.
This is being done by parsing the serialized objects and updating the CreatorID if no CreationData exists. This operation might be expensive for sculpties where the sculpt texture is inlined with the object data. Will just have to see.
This relies on the IAR streaming inventory data before asset data (as is currently the case). Will need to introduce more stringent checks for file order on loading (much like JAR zips must start with the manifest file).
This is for IAR loading only. Tests updated to check this behaviour.
child agents in neighbor regions. This means you can extend
the view on a simulator beyond the default 3x3 regions.
This uses a region default draw distance and should be
replaced at some point by the avatar specified draw distance.
That will require more careful, dynamic recomputation of child
agents every time the draw distance changes.
WARNING: this is experimental and has known instabilities. specifically
all regions "within site" should be running the same default draw distance
or agents will not be closed correctly.
This test was non-viable. Keeping inactive T021_TestCrossToNewRegion() around for now since it's still useful for reference purposes in constructing a future working test.
Going this extra step doesn't appear to cause any test failures.
This is arguably better for test purposes, though at some stage another method may arise which does just call AddRootAgent().
Justin Clark-Casey (justincc)