OpenSim
/
OpenSimMirror
1
0
Fork 0
Code Issues Pull Requests Releases Wiki Activity

* This makes in-world terrain editing smoother, even in MegaRegions. This change only affects the editing user's experience. Non-editing users will see nothing different from the current 'slow' result. See comments for the thought process and how the issues surrounding terrain editing, cache, bandwidth, threading, terrain patch reliability and throttling were balanced.

0.7.6-extended
teravus 2013-08-07 21:22:04 -05:00
parent ce1361f2fe
commit 99a4a91488
1 changed files with 30 additions and 3 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

33
OpenSim/Region/ClientStack/Linden/UDP/LLClientView.cs
View File

@ -327,7 +327,7 @@ namespace OpenSim.Region.ClientStack.LindenUDP
private PriorityQueue m_entityProps;
private Prioritizer m_prioritizer;
private bool m_disableFacelights = false;
private volatile bool m_justEditedTerrain = false;
/// <value>
/// List used in construction of data blocks for an object update packet. This is to stop us having to
/// continually recreate it.
@ -1239,9 +1239,32 @@ namespace OpenSim.Region.ClientStack.LindenUDP
LLHeightFieldMoronize(map);
LayerDataPacket layerpack = TerrainCompressor.CreateLandPacket(heightmap, patches);
layerpack.Header.Reliable = true;
// When a user edits the terrain, so much data is sent, the data queues up fast and presents a sub optimal editing experience.
// To alleviate this issue, when the user edits the terrain, we start skipping the queues until they're done editing the terrain.
// We also make them unreliable because it's extremely likely that multiple packets will be sent for a terrain patch area
// invalidating previous packets for that area.
OutPacket(layerpack, ThrottleOutPacketType.Land);
// It's possible for an editing user to flood themselves with edited packets but the majority of use cases are such that only a
// tiny percentage of users will be editing the terrain. Other, non-editing users will see the edits much slower.
// One last note on this topic, by the time users are going to be editing the terrain, it's extremely likely that the sim will
// have rezzed already and therefore this is not likely going to cause any additional issues with lost packets, objects or terrain
// patches.
// m_justEditedTerrain is volatile, so test once and duplicate two affected statements so we only have one cache miss.
if (m_justEditedTerrain)
{
layerpack.Header.Reliable = false;
OutPacket(layerpack,
ThrottleOutPacketType.Unknown );
}
else
{
layerpack.Header.Reliable = true;
OutPacket(layerpack,
ThrottleOutPacketType.Land);
}
}
catch (Exception e)
{
@ -6263,6 +6286,9 @@ namespace OpenSim.Region.ClientStack.LindenUDP
//m_log.Info("[LAND]: LAND:" + modify.ToString());
if (modify.ParcelData.Length > 0)
{
// Note: the ModifyTerrain event handler sends out updated packets before the end of this event. Therefore,
// a simple boolean value should work and perhaps queue up just a few terrain patch packets at the end of the edit.
m_justEditedTerrain = true; // Prevent terrain packet (Land layer) from being queued, make it unreliable
if (OnModifyTerrain != null)
{
for (int i = 0; i < modify.ParcelData.Length; i++)
@ -6278,6 +6304,7 @@ namespace OpenSim.Region.ClientStack.LindenUDP
}
}
}
m_justEditedTerrain = false; // Queue terrain packet (Land layer) if necessary, make it reliable again
}
return true;