| Commit message (Collapse) | Author | Age | Files | Lines |
|\
| |
| |
| |
| |
| | |
Conflicts:
OpenSim/Region/Framework/Scenes/SceneObjectGroup.cs
OpenSim/Region/Framework/Scenes/ScenePresence.cs
|
| | |
|
| |
| |
| |
| | |
numbered properly even when sets are linked to sets.
|
|\ \
| |/
| |
| |
| |
| |
| |
| | |
Conflicts:
OpenSim/Region/CoreModules/Avatar/Chat/ChatModule.cs
OpenSim/Region/CoreModules/Avatar/Gods/GodsModule.cs
OpenSim/Region/CoreModules/LightShare/LightShareModule.cs
OpenSim/Region/CoreModules/World/Estate/EstateManagementModule.cs
|
| |
| |
| |
| |
| |
| | |
from previous commit which sort out which iterator is used are left
intact. A discussion is needed as to what constitutes an avatar vs a
ScenePresence.
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
the 3 iteration functions so more of them are using the correct
iteration for the action they are performing. The 3 iterators that seem
to fit all actions within OpenSim at this time are:
ForEachAvatar: Perform an action on all avatars (root presences)
ForEachClient: Perform an action on all clients (root or child clients)
ForEachRootClient: Perform an action on all clients that have an avatar
There are still a dozen places or so calling the old
ForEachScenePresence that will take a little more refactoring to
eliminate.
|
|\ \ |
|
| |\ \
| | |/
| | |
| | |
| | |
| | |
| | |
| | | |
Conflicts:
OpenSim/Region/Framework/Scenes/SceneGraph.cs
OpenSim/Region/Framework/Scenes/SceneObjectGroup.cs
OpenSim/Region/Framework/Scenes/SceneObjectPart.cs
OpenSim/Region/ScriptEngine/Shared/Api/Implementation/LSL_Api.cs
|
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
UpdateFlag is now referenced/used only within SOP and SOG. Outsiders are
using ScheduleFullUpdate, ScheduleTerseUpdate or ClearUpdateSchedule on
SOP consistently now. Also started working toward eliminating those
calls to ScheduleFullUpdate, ScheduleTerseUpdate or ClearUpdateSchedule
from outside SOP in favor of just setting properties on SOP and let SOP
decide if an update should be scheduled. This consolidates the update
policy within SOP and the client rather than everywhere that makes
changes to SOP. Some places forget to call update while others call it
multiple times, "just to be sure".
UpdateFlag and Schedule*Update will both be made private shortly.
UpdateFlag is intended to be transient and internal to SOP so it has
been removed from XML serializer for SOPs.
|
|/ / |
|
|\ \
| |/
| |
| |
| | |
Conflicts:
OpenSim/Region/Framework/Scenes/SceneObjectGroup.cs
|
| |
| |
| |
| | |
We always use SOP.Rotation instead
|
| |
| |
| |
| | |
than calling SOP.OffsetForNewRegion
|
| | |
|
|\ \
| |/
| |
| |
| | |
Conflicts:
OpenSim/Region/Framework/Scenes/ScenePresence.cs
|
| | |
|
|\ \
| |/ |
|
| | |
|
|\ \ |
|
| |\ \
| | |/ |
|
| | |
| | |
| | |
| | |
| | | |
SP still has an implementation but this is now just a public method on SP rather than an abstract one in EntityBase.
No point making the code more complex until it actually needs to be,
|
| |\ \
| | |/
| | |
| | |
| | | |
Conflicts:
OpenSim/Region/Framework/Scenes/SceneObjectGroup.cs
|
| | |
| | |
| | |
| | | |
are only sent to affected clients.
|
| |\ \
| | |/ |
|
| | |
| | |
| | |
| | | |
This is moved into ScenePresence for now as a general facility
|
| |\ \
| | |/
| | |
| | |
| | |
| | |
| | | |
Conflicts:
OpenSim/Region/Framework/Scenes/Scene.Inventory.cs
OpenSim/Region/Framework/Scenes/SceneObjectPart.cs
OpenSim/Region/Framework/Scenes/SceneObjectPartInventory.cs
|
| | |
| | |
| | |
| | |
| | |
| | | |
reflect what it actually does
This also makes it consistent with some other methods that send data to the client.
|
|\ \ \
| |/ /
|/| | |
|
| | | |
|
| | | |
|
| | | |
|
| | | |
|
| | |
| | |
| | |
| | | |
selectively merge the changes made to core.
|
| | | |
|
|\ \ \
| |/ /
|/| /
| |/ |
|
| |
| |
| |
| |
| |
| |
| | |
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
|
| |
| |
| |
| | |
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
|
| | |
|
| |
| |
| |
| | |
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
|
| |
| |
| |
| | |
AttachmentsModule.DetachSingleAttachmentToInv()
|
| | |
|
| |
| |
| |
| |
| |
| | |
readability
use these in some sog methods
|
| |
| |
| |
| |
| | |
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.
|
| |
| |
| |
| | |
not yet complete.
|
| |
| |
| |
| | |
consistent with terminology used by scene object part and elsewhere
|
| | |
|
| |
| |
| |
| |
| |
| |
| | |
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.
|