| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
|\
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Conflicts:
OpenSim/Framework/Monitoring/BaseStatsCollector.cs
OpenSim/Region/Application/OpenSim.cs
OpenSim/Region/Application/OpenSimBase.cs
OpenSim/Region/Framework/Scenes/SceneManager.cs
bin/OpenMetaverse.Rendering.Meshmerizer.dll
bin/OpenMetaverse.StructuredData.dll
bin/OpenMetaverse.dll
bin/OpenMetaverseTypes.dll
prebuild.xml
|
| |
| |
| |
| |
| | |
This is fired when all regions are ready or when at least one region becomes not ready.
Recently added EventManager.OnRegionReady becomes OnRegionReadyStatusChange to match OnLoginsEnabledStatusChange
|
| |
| |
| |
| |
| | |
Changes to the scenes dictionary are exceedingly rare and using atomic
operations makes the chance of collisions nearly nil in any case.
|
|/ |
|
|
|
|
|
| |
It makes far more sense anyway to use TryGetRootScenePresence().Scene, in common with the rest of the code
This method could also return any scene for child or root agents, depending in which order the scenes happened to lie in the list
|
|
|
|
| |
This allows someone with access to this command on the XMLRPCAdmin interface to teleport an avatar to an arbitrary region and/or position.
|
|
|
|
|
|
| |
not just root ones.
Also adds scene name and client type (root|child) to logged information.
|
|
|
|
|
|
| |
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.
|
|
|
|
| |
passed to ForEachScenePresence checks for !IsChildAgent first. It consolidates child and root handling for coming refactors.
|
| |
|
|
|
|
| |
without a getter
|
|\
| |
| |
| |
| | |
Conflicts:
OpenSim/Region/Framework/Scenes/SceneManager.cs
|
| | |
|
|/ |
|
|
|
|
| |
Remove no-arg backup method for simplicity as it only make sense to call non-forced backup internally
|
|
|
|
| |
Scene and SceneGraph. This was the only change in this patch to keep it isolated from other recent changes to the same set of files.
|
|
|
|
| |
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>).
|
|
|
|
|
|
| |
eliminating option to return the actual list. Callers can now either request a copy of the array as a new List or ask the SceneGraph to call a delegate function on every ScenePresence. Iteration and locking of the ScenePresences now takes place only within the SceneGraph class.
This patch also applies a fix to Combat/CombatModule.cs which had unlocked iteration of the ScenePresences and inconsistent try/catch around the use of those ScenePresences.
|
|
|
|
|
|
| |
relevant test code has been obsoleted
this allows the tests to pass on my local system
|
|
|
|
|
|
|
| |
the new AgentTransferModule, in line with what MW started implementing back in May -- ITeleportModule. This has been renamed IAgentTransferModule, to be more generic.
* HGSceneCommunicationService has been deleted
* SceneCommunicationService will likely be deleted soon too
|
|
|
|
| |
unfortunately, these commands cannot yet be properly relocated to the region modules due to deficiencies in the region module infrastructure
|
|
|
|
| |
avoiding locking and copying the list each time it is accessed
|
|\ |
|
| | |
|
| | |
|
|/
|
|
|
|
|
|
| |
LayerInfo.End values and creating guessed default layer boundaries on failed decodes Changed a noisy J2K decode log message from Info to Debug Replacing openjpeg-dotnet decoding with managed CSJ2K decoding. Should be much more reliable, faster, and use less memory
* Re-added openjpeg-dotnet files since they are used elsewhere in OpenSim * Updated prebuild.xml with a reference to CSJ2K
* Renamed IJ2KDecoder and J2KDecoder member names to follow standard naming conventions * Removed j2kDecodeCache cruft and replaced it with the OpenSim cache system * Rewrote the default layer boundary algorithm to use percentages instead of an exponent * Switched from an infinite in-memory cache to an expiring cache (10 minute timeout) * Slightly quieted logging errors for failed texture decodes
|
| |
|
|
|
|
| |
LICENSE.txt.
|
|
|
|
|
|
|
|
|
|
|
|
| |
-- please see the example. Affects region servers only.
This may break a lot of things, but it needs to go in. It was tested in standalone and the UCI grid, but it needs a lot more testing.
Known problems:
* HG asset transfers are borked for now
* missing texture is missing
* 3 unit tests commented out for now
|
|
|
|
| |
were loaded.
|
|
|
|
|
|
|
|
|
| |
* Added log4net dependency to physxplugin in prebuild.xml.
* Added missing m_log fields to classes.
* Replaced Console.WriteLine with appropriate m_log.Xxxx
* Tested that nant test target runs succesfully.
* Tested that local opensim sandbox starts up without errors.
|
|
|
|
|
|
| |
* This is always available at Scene.CommsManager.AssetCache
|
| |
|
|
OpenSim.Region.Environment into a "framework" part and a modules only
part. This first changeset refactors OpenSim.Region.Environment.Scenes,
OpenSim.Region.Environment.Interfaces, and OpenSim.Region.Interfaces
into OpenSim.Region.Framework.{Interfaces,Scenes} leaving only region
modules in OpenSim.Region.Environment.
The next step will be to move region modules up from
OpenSim.Region.Environment.Modules to OpenSim.Region.CoreModules and
then sort out which modules are really core modules and which should
move out to forge.
I've been very careful to NOT BREAK anything. i hope i've
succeeded. as this is the work of a whole week i hope i managed to
keep track with the applied patches of the last week --- could any of
you that did check in stuff have a look at whether it survived? thx!
|