| Commit message (Collapse) | Author | Age | Files | Lines |
|\
| |
| |
| |
| | |
Conflicts:
OpenSim/Region/Application/OpenSimBase.cs
|
| |
| |
| |
| |
| |
| | |
makes use of the SLUtil copy via a method rather than each LLClientView loading a separate copy.
As per opensim-users mailing list discussion.
|
|\ \
| |/
| |
| |
| |
| | |
Conflicts:
OpenSim/Region/Framework/Scenes/ScenePresence.cs
OpenSim/Region/ScriptEngine/Shared/Api/Implementation/LSL_Api.cs
|
| |
| |
| |
| | |
This is rather than checking whether the avatar is sitting and doing its own calculation.
|
| |
| |
| |
| |
| |
| |
| | |
(saving extra null checks, etc.)
However, it looks like we should retain SP.ParentID since it's much easier to use that in places where another thread could change ParentPart to null.
Otherwise one has to clumsily put ParentPart in a reference, etc. to avoid a race.
|
|\ \
| |/ |
|
| | |
|
|\ \
| |/ |
|
| | |
|
|\ \
| |/ |
|
| | |
|
| |
| |
| |
| |
| |
| | |
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/CoreModules/Avatar/Chat/ChatModule.cs
OpenSim/Region/CoreModules/Avatar/Gods/GodsModule.cs
OpenSim/Region/CoreModules/Avatar/InstantMessage/MessageTransferModule.cs
OpenSim/Region/CoreModules/World/Estate/EstateManagementModule.cs
OpenSim/Region/ScriptEngine/Shared/Api/Implementation/LSL_Api.cs
|
| |
| |
| |
| | |
passed to ForEachScenePresence checks for !IsChildAgent first. It consolidates child and root handling for coming refactors.
|
| |
| |
| |
| |
| |
| |
| | |
Remove the too coarse CanEditParcel method in favor of a CanEditParcelProperties
method that takes a GroupPowers argument to specify what action is to be
taken. Also, make the method to set parcel data much more granular. Permissions
in a deeded setting should now work.
|
| |
| |
| |
| |
| |
| |
| | |
Remove the too coarse CanEditParcel method in favor of a CanEditParcelProperties
method that takes a GroupPowers argument to specify what action is to be
taken. Also, make the method to set parcel data much more granular. Permissions
in a deeded setting should now work.
|
|\ \
| |/ |
|
| |
| |
| |
| | |
list of all locations fresh for every scene presence on every frame, we will instead compute the list once every 50 frames and send to all connected presences at that time. Also, we only add 60 items to the list when there are more than 60 presences in the scene. For 1000 users, this change yields a 99.8% reduction in list processing and a 98% reduction in network bandwidth for coarse locations.
|
|\ \
| |/ |
|
| |\ |
|
| | |
| | |
| | |
| | | |
really don't need two methods doing the same thing, but differently.
|
| |/
| |
| |
| | |
GetAvatars have been removed to consolidate locking and iteration within SceneGraph. All callers which used these to then iterate over presences have been refactored to instead pass their delegates to Scene.ForEachScenePresence(Action<ScenePresence>).
|
| |
| |
| |
| |
| |
| | |
* It does this by tweaking the throttles on child agent connection to a megaregion and multiplying the land throttle by 50. (various bit and byte magic ensue)
* While, I doubt this will cause terrain crater sized potholes.. since it actually increases the bandwidth available for land in child regions when MegaRegions area active, more testing would be good.
* This, in theory, also shouldn't cause missing objects in child regions.. because all objects are in the root region anyway. As I said, more testing would be good.
|
|/
|
|
| |
really don't need two methods doing the same thing, but differently.
|
| |
|
|
|
|
| |
miguel, and the fabulous bug reports by our community members.. The workaround fix for the "ERROR:metadata.c:3211:mono_metadata_token_from_dor: code should not be reached" bug in the RegionCombinerModule.
|
| |
|
|
* Moves the mono_metadata_token_from_dor message to a different module on loading.
|