The Havok™4-based Second Life simulator v18.104.22.168444 has been deployed to the Beta Preview. If this version looks solid on the Beta Preview overnight and into tomorrow, then tomorrow (Friday) we will deploy this version to the Early Adopter regions.
What Has Changed In This Version?
Changes in this build include (SVC items were submitted on the public jira issue tracker / DEV items are internally discovered issues / there are a few in this list that were fixed without jira tracking #’s…).
SVC-1923: Mass calculations on small path-cut, hollowed and dimpled prims adjusted to be much closer to the masses calculated on the current release simulator. Masses on these small complex objects may not be exactly the same, since we now account for scale when calculating minimum size prims, and a few other variables, but it will be much closer)
SVC-1856: Unassisted flight at high altitudes is now possible with reduced fall rates. The fall rate is not quite as low as the current release simulator, but is now much closer.
DEV-12601: Floating object no longer falls (this was a secondary effect of issues like
SVC-1923 – mass calcuations not correct for twisted shapes)
DEV-12637: Kart no longer sometimes spins on it’s top after crossing region boundary
SVC-1792: llSetBouyancy = 1.0 now handled correctly (another fix for avatars not holding altitude correctly with a HUD attachment)
SVC-1520: Reduced the amount of “float” between avatar feet and floor
DEV-12320: llGetBoundingBox now includes the object the avatar is sitting on
SVC-1473: Hollowed and path-cut prims now align better when using copy selected
DEV-12585: Relaxed 256m megaprim size limitation to 64km based on continuing discussions and analysis. See the section below for details.
DEV-12585 Details: Megaprims discussion # who knows by now? attempt at a joke 🙂
In office hours discussions it had seemed that no one was using megaprims over 256m in general ways, but Andrew had the good idea to scan the grid just to check… What we found surprised us. There are over 80 regions using larger than 256m megaprims, in almost all cases in order to generate an artificial horizon – either sky or water.
Given the number of these completely legitimate builds that would be affected, and the ability to implement megaprim clamping code essentially on a moment’s notice if it seems appropriate, we reached a new and somewhat different conclusion. In addition, I will be doing some performance and capacity work to determine specific overhead for this amongst other cases so that we understand the real impact of these on region design.
We have now decided that the best path will be to not restrict megaprim size to 256m as we had previously discussed at length (for months), but to only limit them to 64k meters, and have an upcoming project create better tools for managing large prims, both in terms of tracking them and providing methods to prevent mis-use that create problems for residents in overlapped parcels (where a megaprim overhangs their property, for instance).