This may have been the trigger CheckSendingPatchesToClients() dictionary out of sync exceptions in today's load test.
Don't need to check ContainsKey() since Remove() returns false on a request to remove a key that it doesn't have
This, by default, enables terrain patches being sent to each avatar
from the avatar away (rather than the old outside-in pattern), only
sending terrain patches within the avatars view distance (making
view loading quicker), and sending multiple terrain patches per
protocol packet (making terrain loading and editing quicker).
This should eliminate much memory thrashing and CPU usage while sending initial
terrain.
The old way of passing terrain was to convert it to an array of floats. This is
really bad for large terrain (think 4096x4096 floats). This change passes a dummy
float array since the real region info is used anyway and the floats are ignored.
(The ignoring the terrain floats is a kludge so as to not change IClientAPI.)
than everytime terrain is changed.
The TerrainModule now hooks the frame event and, if terrain has changed,
sends terrain updates to the clients. This polling pattern replaces
the previous push on change pattern and will make it easier to do per
client throttling and per scene presence terrain update ordering.
the size of the input stream. This is required since the raw heightmap
format (.r32) does not contain any size information.
The estimation relies on terrain being square.
Modify archiver to use terrain merging when loading oars.
This makes displacement AND rotation properly work on terrain when loading oars.
Especially useful when loading legacy region oars into large varregions.
Adds displacment to all objects and terrain loaded from the oar.
As an example, if you have a 512x512 region and an old 256x256 oar, doing
load oar --displacement "<128,128,0>" oarFile.oar
will load the object (and terrain) into the middle of the 512x512 region.
If displacement is not specified, 'load oar' works like it always has.
If you have a 5
Rename 'RegionWorldLocX' to 'WorldLocX' and same for Y and Z.
This keeps the downward compatibility and follows the scheme of 'region'
and 'world' location naming that is happening in the Util module.
Routines in Util to compute region world coordinates from region coordinates
as well as the conversion to and from region handles. These routines have
replaced a lot of math scattered throughout the simulator.
Should be no functional changes.
-- addition of varaible region size in X and Y
-- internal storage of heightmap changed from double[] to short[]
-- helper routines for handling internal structure while keeping existing API
-- to and from XML that adds region size information (for downward compatibility,
output in the legacy XML format if X and Y are 256)
Updated and commented Constants.RegionSize but didn't change the name for compatibility.
count number to integer world coordinates.
Added new methods RegionWorldLoc[XY].
Refactored name of 'RegionLoc*' to 'LegacyRegionLoc*' throughout OpenSim.
Kept old 'RegionLoc*' entrypoint to RegionInfo for downward compatability
of external region management packages.
The encodings are thread-safe and already used in such a manner in other places.
This isn't done where Byte Order Mark output is suppressed, since Encoding.UTF8 is constructed to output the BOM.
