The code in question is over three years old and just be catching an inconsistency rather than being wholly necessary.
This commit still carries out the check and prints all the previous log warnings but a 'failure' no longer prevents avatar region crossing or teleport, and it doesn't give the client the error message.
This will have some kind of impact on http://opensimulator.org/mantis/view.php?id=5672
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
This method wasn't actually doing anything since dropped attachments retain a PCode of 9.
Also, behaviour of dropped attachments in other places appears to be that they persist after avatar logout rather than get deleted.
Even though we don't use these on rez they are still present after an unlink, after which selecting them causes various viewers to crash
Hopefully really does address http://opensimulator.org/mantis/view.php?id=5664
It's never possible for SOG to have no RootPart, except in the first few picosends of the big bang when it's pulled from region persistence or deserialized
The only times when ParentGroup might be null is during regression tests (which might not be a valid thing) and when scene objects are being constructed from the database.
At all other times it's not possible for a SOP not to have a SOG parent.
The approach here, as in other parts of OpenSim, is to return a copy of the list rather than the attachments list itself
This prevents callers from forgetting to lock the list when they read it, as was happening in various parts of the codebase.
It also improves liveness.
This might improve attachment anomolies when performing region crossings.
On making a root agent, we need to reset the ScenePresence.m_movement_flag so that it doesn't remember the
movement registered to the client when it exited the initial region.
If this is remember, then the client avatar movement isn't updated and it appears to stall in mid-air, though this is resolved with a prod/release of any other direction key.
This bug was probably introduced a few weeks ago. Surprised that nobody brought it up.
Apart from one obvious bug, this was failing because attempting to serialize the script from inside the script (as part of saving the attachment as an inventory asset) was triggering an extremely long delay.
So we now don't do this. The state will be serialized anyway when the avatar normally logs out.
The worst that can happen is that if the client/server crashes, the attachment scripts start without previous state.
llRegionSay will now message avatars on chan 0
and will message attachments on the avatar that
listen on channels other than 0.
This behavior is consistant with the LL
implementation as tested on regions in Agni
with one exception: this implementation does
not include issue:
https://jira.secondlife.com/browse/SCR-66?
This meant punching in another AddUser() method in IUserManagement to do a direct name to UUID associated without the account check (since NPCs don't have accounts).
May address http://opensimulator.org/mantis/view.php?id=5645
This is done by introducing a PresenceType enum into ScenePresence which currently has two values, User and Npc.
This seems better than a SaveAttachments flag in terms of code comprehension, though I'm still slightly uneasy about introducing these semantics to core objects
Default for this function is now not to automatically land.
This allows better control by scripts when an avatar is going to be landing on a prim rather than the ground.
Stopping the avatar involves faking a collision, to avoid the pid controller making it overshoot.
A better approach would be to gradually slow the avatar as we near the target
this is to allow walking on prims. it will be up to the script writer to be sure that there is a continuous path.
currently implemented in osNpcMoveToTarget(), but none of this is final.
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 doesn't help where the target is a prim surface. In these situations, it might be better to provide manual overrides so the script can control whethre an avatar flys there/lands, etc.
This makes the movement exact. Regression test changed to check avatar reaches exact target.
Also has the nice side effect of making NPC animations continue to work after the first movement (which wasn't working). However, avatar still pauses in mid-stride
Avatar moves and stops. However, will stop in mid stride.
And if the move to position is in the air, avatar will continue to make vain and quite hilarious attempts to take off (but never doing so).
Clearly more work is needed.
This now works again except that it requires a click or avatar mvmt to get going
This is because the ScenePresence.HandleAgentUpdate() method doesn't trigger until the client does something significant, at which point autopilot takes over.
Even clicking is enough to trigger.
This will be improved presently.
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.
This is to prevent situations where the first name returned by GridService.GetRegionsByName is not one that exactly matches the given region name, even when there is an exact match later on in the list.
Only the above two functions call this teleport method (the map uses a different routine) so this seems safe to change.
Addresses http://opensimulator.org/mantis/view.php?id=5606
This is to accomodate situations where the authorization service is being used by the hypergrid, where visitors have no user account.
See http://opensimulator.org/mantis/view.php?id=5517, this code is somewhat adapted/cleaned up from Michelle's patch
I'm a little ambivalent about this since visitors could put anything in firstname/lastname so it's not much of an auth measure.
It's up to the auth service to decide which data it actually uses.
Possibly we should be passing through other info such as agent circuit ip
Some items had completely wrong permissions - this is easier than correcting them all.
The ability to set permissions in xml is retained since there are use cases for this (e.g. to create no-mod library scripts)
Library items always need the same permissions, so it doesn't make sense to load them from the xml files. This just opens the door to permissions mistakes.
Fixed this by inspecting Shape.SculptEntry at various places instead of Shape.SculptType. Sculpties actually have a SculptType of Cylinder - only true mesh is SculptType.Mesh
This addresses http://opensimulator.org/mantis/view.php?id=5595
This stops problems when we undo a few steps and start off down another path.
Surprisingly, apart from this now fixed problem, redo appears to be working too.
I think (ha ha) this largely fixes undo, except for the fact that rotation a set of prims with 'edit linked parts' selected doesn't quite work properly (though this works fine if the checkbox isn't selected).
Also, the double undo bug for resize is still present.
Redo might be incredibly buggy, haven't even looked at that yet.
The only obviously broken things right now are the undo of the position of just a root prim (stays in place) and the fact that resizes need two undoes.
However, what happens now is that undo just doesn't do anything when the root prim is selected on its own. This requires more code than just fiddling with undo states.
This involves implementing a boolean in UndoState to signal whether the undo needs to be done for an entire group/linkset or just a single prim
Resizing individual components of linksets is still dodgy.
Resizing still has to be down twice, since for some reason the client is sending two multiobjectupdate packets on every resize except the very first. This applies to single prims and linksets. Need to look into this.
Undo rotation and position appear to be working.
Resizing a single prim appears to be working, though the undo has to be done twice.
Resizing a group of prims still does not work properly - possibly because in the UndoState we don't store a knowledge of when we're resizing a whole group rather than individual prims.
This needs to be addressed.
Also fiddle a bit with undo. This is not currently working properly, though to be fair it also didn't appear to work in 0.7.1.1 either (at least for resize).
Will get some more attention soon.
Unable to get to the bottom of why resizing a mesh fails to properly reset the physics proxy, when toggling phantom does
After a mesh is generated, the existing sculptdata is set to zero in PrimitiveBaseShape to save memory
When phantom is toggled, the sculptdata is regenerated before remeshing.
But on resize, the sculptdata is not regenerated.
So clearly, resetting sculptdata is possible, but haven't quite been able to pin down how this is being done when phantom is toggled.
If a user with a very large inventory right-clicks on their "My Inventory" folder, viewer 1 code will send a massive number of Fetchinventory requests.
Even though each is handled asynchronously via a pool thread, the sheer frequency of requests overwhelms the pool and freezes inbound packet handling.
This change makes the first Fetchinventory thread also handle subsequent requests, freeing up the other threads.
Further efficiencies could be made by handling all the items in a particular FetchInventory request together, rather than separately.
This is to avoid problems with corrupt inventories where an inventory link target points back at the source's folder
No viewer has been observed to set these up as of yet. If this ever happens, we will need a more sophisticated solution to track sent folders within the recursion
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!
Many thanks to the aurora project for pioneering this.
This code is almost certainly not bug free, but it does at least appear to handle simple meshes (except when the viewer crashes - but it is beta!).
Justin Clark-Casey (justincc)