* This was not a problem with objects consisting of less than 30 prims, since the extra schedules would be ignored
* However, above approximately 30 prims extra schedules would actually occur.
* For instance, a 140 prim object would end up triggering approximately 2500 ObjectUpdates to every avatar in range rather than 140
* Hopefully, this change will improve client responsiveness on deselect and was one of the reasons that the AgentThrottle restriction started causing problems yesterday.
The average-value of modify.ModifyBlock.Height in LLClientView.cs:4170
seem to be incorrect or it isn't the average? Mhhh...
So the terrain build -> Flaten Sphere is unuseable.
I have put in a patch that contains a workaround while
the main problem is not solved.
* Puts remote requests in a single worker thread
* Worker thread only starts when there are agents to serve
* When there are no agents to serve, it shuts down
* A good example of how to deal with threads in non-shared modules so they don't end up consuming threads per regions
If prim is part of SOG, then ask the SOG to update the
position, rather than asking the part itself.
Ghosted child prims should no longer result from llSetPos.
Not sure if this is the right approach for all cases ,
would appreciate feedback on the patch.
The attached patch fixes mantis bug 2312 (llGetPos() returns incorrect
values for child prims where the root prim is rotated). Regression
tests still pass.
Incidentally AbsolutePosition which was used before looks a little
suspicious to me as its always going to return the wrong value if the
root prim is rotated. GetWorldPosition does take the rotation into
account, but AbsolutePosition is used in a lot of places. Though i
don't understand why there is both GetWorldPosition as well as
AbsolutePosition so I've left the latter alone.
[i also cleaned up some indent problems, --- dr scofield]
Attached is a patch for LLGround which was just plain broken and could
cause a runtime error. It now returns valid data with valid input (ie
the offset does not take the position off the edge of the sim), but a
runtime error will occur if invalid data is given.
On invalid data the LL servers return the ground height based on a
valid point closest to the effective position calculated using the
supplied offset. Is the OpenSim convention to replicate the LL servers
as closely as possible? If so I can submit an additional patch to
replicate the LL behaviour.
Dahlia Trimble