| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
|
|
|
|
|
|
|
| |
them as UUID.Zero.
Leaving them at UUID.Zero meant that when a viewer 2 logged into a region that had been freshly created, it received UUID.Zero for these textures, and hence display the land as plain white.
On a simulator restart, the problem would go away since when the database adapators loaded the new region settings, RegionSettings itself has code to use default textures instead of UUID.Zero.
This commit resolves the problem by saving the default texture UUIDs instead of Zero.
However, we currently have to do this in a roundabout way by resaving once the RegionSettings have been created by the database for the first time. This needless complexity should be addressed.
This change will also have the effect of replacing any existing UUID.Zero terrain textures with the default ones.
However, this shouldn't have any effect since the UUID.Zeros were already being replaced in memory with those same UUIDs.
|
| |
|
|
|
|
| |
This is only called by a region console command.
We should also be locking m_partsUpdateQueue when dequeueing the next part, or locking m_pendingObjects in QueuePartForUpdate().
However, I won't do this now since I don't have time to analyze how this would affect liveness.
|
| |
|
|
|
|
| |
useless work as a closed scene object is never reset.
Strictly speaking, we could also stop bothering to clear the m_updateTimes and m_partsUpdateQueue if we are sure that the whole SceneViewer is shortly to be garbage collected anyway, but we'll leave them around for now.
|
| | |
|
| |
|
|
| |
m_pendingObjects lock in order to avoid the race condition seen by danbanner in http://opensimulator.org/mantis/view.php?id=5669
|
| |
|
|
| |
IAttachmentsModule.RezSingleAttachmentFromInventory() with the updateInventoryStatus switch, since this is never called with false
|
| |
|
|
|
|
|
|
| |
actually has an impact.
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.
|
| |
|
|
|
|
|
| |
SOG.ClearPartAttachmentData() is called.
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
|
| |
|
|
| |
the code becomes simpler if this is set from the outside - only one place needs to do this.
|
| | |
|
| |
|
|
| |
calling through the SOP, which doesn't make conceptual sense anyway.
|
| |
|
|
| |
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.
|
| | |
|
| |
|
|
| |
SP.AddToPhysicalScene()
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
|
| |
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.
|
| |
|
|
| |
remove some now duplicated method doc
|
| | |
|
| |
|
|
| |
This adds an incomplete IScenePresence to match ISceneEntity
|
| | |
|
| | |
|
| |\ |
|
| | |
| |
| |
| |
| | |
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
|
| |\ \
| |/ |
|
| | |
| |
| |
| | |
Signed-off-by: BlueWall <jamesh@bluewallgroup.com>
|
| | |
| |
| |
| |
| |
| |
| |
| |
| | |
crossing.
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.
|
| | |
| |
| |
| | |
stored in the root part's state field.
|
| | |
| |
| |
| | |
pointless duplication of identical values
|
| |\ \
| |/ |
|
| | |
| |
| |
| | |
This does a tiny bit to reduce code complexity, memory requirement and the cpu time of pointlessly setting this field to the same value in every SOP
|
| | |
| |
| |
| | |
AttachmentsModule.DetachSceneObjectToGround() and remove redundant code
|
| | |
| |
| |
| | |
object group direct
|
| | |
| |
| |
| | |
AttachmentsModule.DetachSingleAttachmentToInv()
|
| | |
| |
| |
| |
| | |
IsDeleted is never set for an SP, even though it's on EntityBase.
It might be an idea to set it in the future
|
| | | |
|
| | |
| |
| |
| |
| |
| | |
readability
use these in some sog methods
|
| | |
| |
| |
| | |
AttachmentsModule.AddSceneObjectAsAttachment()
|
| | | |
|
| | |
| |
| |
| | |
currently hardcoded offset
|
| | | |
|
| | |
| |
| |
| |
| |
| | |
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.
|
| | |
| |
| |
| | |
DetachSingleAttachmentToInv() for consistency and to reflect it's actual behaviour
|
| | | |
|
