| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| | |
|
| | |
|
| |
|
|
| |
Will help in automation of setting version info for addin dependencies.
|
| |
|
|
|
| |
This reverts commit ab446bc692782b75fd27105fc3370a16b4fc17d8.
Need to look into this
|
| |
|
|
| |
Move addin information from attributes to RegionCombinerModule.addin.xml to aid in automation of addin dependency tracking.
|
| |
|
|
| |
dictionary on RemoveRegion(), causing a later issue if regions were restarted (removed then readded).
|
| | |
|
| |
|
|
|
|
|
|
| |
false, since this allows one to go back from a megaregion to normal regions.
Adapted from a patch by Garmin Kawaguichi in http://opensimulator.org/mantis/view.php?id=6027
Garmin says that fix-phantoms allows one to reset objects when going back from megaregion to normal regions as well as the othe rway around.
Thanks!
|
| | |
|
| |
|
|
|
|
| |
saved) will have a size larger than 256x256
Not yet read. Do not rely on this information yet, it may change.
|
| |
|
|
| |
rather than copy/pasting the necessary calculations in lots of places.
|
| |
|
|
| |
so that it's easy to tell whether they refer to the root region connection or a new region connection
|
| |
|
|
| |
root region of a megaregion relative to an added region
|
| |
|
|
|
|
|
| |
of over-inflated.
This was previously over-inflated because adding a region to the NE of the root region resulted in double counting of regions already added.
An accurate extent will also be necessary for other purposes.
|
| |
|
|
|
|
| |
more than one megaregion in a simulator, separated by water.
Rename IsRootRegion() to IsRootForMegaregion()
|
| | |
|
| |
|
|
|
|
|
|
| |
future use. Please do not rely on this remaining here.
An adaptation of part of Garmin's patch from http://opensimulator.org/mantis/view.php?id=5975, thanks!
Flag only written if the SW corner OAR is saved - this is the only one that captures object data presently (though not land or terrain data).
This adds an IRegionCombinerModule interface and the necessary methods on RegionCombinerModule
|
| |
|
|
|
|
| |
makes use of the SLUtil copy via a method rather than each LLClientView loading a separate copy.
As per opensim-users mailing list discussion.
|
| |
|
|
| |
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.
|
| |
|
|
| |
passed to ForEachScenePresence checks for !IsChildAgent first. It consolidates child and root handling for coming refactors.
|
| |
|
|
|
| |
However, the calls to the land management module to record prims need to remain, since they were also being used to return owner object lists, etc.
This is probably why prim counts were being done there in the first place.
|
| |
|
|
|
|
|
|
| |
parcels from the OAR.
The region spanning parcel shouldn't exist in this situation. If it does, when the land data is loaded it is repersisted with a local ID which comes after the ones loaded via the oar, which obliterates the oar loaded one.
Resaving the data we just loaded from the database is somewhat odd in itself (though this makes sense from the way that OAR loading was already using the same event).
|
| |
|
|
|
|
| |
of merged.
The --merge switch will still merge the old and new land parcelling.
|
| |
|
|
|
|
|
| |
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.
|
| | |
|
| | |
|
| |
|
|
| |
restored to some heavy casting in order to preserve RegionCombinerModule semantics, pending better events.
|
| |
|
|
| |
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.
|
| |
|
|
| |
joins parcels in an area, osParcelSubdivide splits parcels in an area, osParcelSetDetails sets parcel name, description, owner and group owner. Join and Subdivide methods in LandChannel are exposed.
|
| |\ |
|
| | |
| |
| |
| | |
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.
|
| | |
|
| | |
|
| |
|
|
| |
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.
|
