This week the main channel got the code that had been running on Blue Steel and Le Tigre. This means the new version of Havok 2012.1 is going to be running in all channels as of Wednesday. So, the region crossing problems for vehicles should stop… well those caused by the Havok version difference.
The release notes are here for version: 12.10.26.266333. I’ve listed them several times in previous articles so I’ll skip providing them again.
Blue Steel & Le Tigre
This channel is getting a maintenance package. It will include bug fixes generated from code running on the Magnum channel in week 44. The most notable change is in BUG-166 – Something invisible pushes avatars around on Dore. This fix has to do with link sets larger than 64m failing to rez.
What was happening is griefers were rezzing 256x256x256m mega prims, which users can’t see, unless they have estate manager status. It looks like the Lindens are bringing back restrictions on rezzing objects larger than 256x256x10m. That size was selected because some race tracks make legitimate use of large thin objects to achieve seamless race tracts.
Magnum
Magnum will run the same code as last week with the addition of the changes rolled to the main channel, plus additional big fixes.
This is the code with the Large Group Edit fix. You will still need to run a special project viewer to take advantage of the changes. See the release notes for a link or try LATEST Baker Build (266337 as of 11/7). Consider both of these pre-beta versions and expect them to be buggy.
Baker Linden tells us his viewer side code has moved into Beta Viewer repository. We should see the Large Group Edit in 3.4.2 versions of the SL Viewer. Rumor is the code is already in a Firestorm Viewer (official beta) that is in their QA and working well.
Summary
Not much new on the server front. The last few weeks have been jammed up from problems. Hopefully we are getting past the problem and things will move forward again.
The big things remain on the distant horizon; avatar bake, materials, and threaded region crossings. We have no idea where in the development and QA process they are. There is some rumor that threaded crossings are on the ADITI grid, somewhere.
Viewer News
The Lab has been fighting memory leaks in the Beta and Development viewers. A couple of times they thought they had the problem fixed. Again they think they have it. The result is a new Beta Viewer will be out Thursday (11/8)… with standard caveats.
This viewer has a number of open source contributions, Linden features, and fixes that the memory problem has help up for weeks.
Oz Linden says, “New volume controls, blocking the worn lights on blocked avatars, copying SLURL’s from landmarks in inventory, an animation fix for hands, and a bunch of other fixes…”
Other features may be delayed as the holidays are coming up. Significant changes are generally not released near a holiday.
Last Position
Once up on a time it was possible to rez something back to its last in-region position from inventory. That feature is coming back in some third party viewers. Firestorm has it. I’m not sure if it is in the Beta or current release version. Dolphin 3.3.23-24802 has it.
There are problems with the feature that are confusing and surprising. When an item is rezzed in a different region the item can end up at <0,0,0> or the southwest corner of a region. In some cases it would not rez if you did not have rez rights at 0,0,0.
I’ve never had a need for the feature, so I have no idea how well it works or how the viewers with the feature handle the problems of trying to rez something to a last position not in the current region… but, some people want the feature, so it is in some viewers.
Sailors Mini Map
The Dolphin Viewer has a new feature labeled the Sailor’s Mini Map. Check it out on the Dolphin Viewer’s blog. You can see the difference between the standard mini map and the Sailor’s Mini Map.
Catznip R7 has a similar new mini map and a bunch of new features in the current release.
Restore To Last Position is extremely useful – well at least I know I and other people find it so – not only in case you remove something accidentally but also if you need a copy of an object rezzed with two of the three same x,y,z positions. (In the latter case, you make a copy, move the original to a different x, y or z, and then restore the copy to the last i.e. original position.)
The feature stopped working properly a while ago – if an object is close to the parcel boundary, it won’t Restore To Last Position now. I believe it to be the same bug that makes it possible for a neighbour to return one of your objects if it’s close to the parcel boundary.
Please please please LL can we have this fixed!
Thanks for commenting on how you and others use Restore to Last Position.
Some of the Restore problems started when the Lindens responded to user complaints and changed how ‘encroaching’ prims are handled.The change to 64m prims and continuing to allow the use of megaprims was creating encroachment problems. If the center of an object is on your parcel and a part of it extends into a neighbors parcel, they had to file a trouble ticket to get it removed. With 64m objects it was possible to encroach a bit over 31m. There was nothing they could do about the encroachment. Now those being ‘encroached’ can return the encroaching object.
Mesh and sculpty objects with odd bounding boxes often encroach without their owner realizing. See my article on Second Life Render Metadata for help seeing bounding boxes. If you are seeing objects returned that do not encroach, please file a BUG report in the JIRA.
In my experience, this isn’t a problem just with mesh and sculpty objects with odd bounding boxes – any object too close to a parcel boundary is unlikely to be able to Restore To Last Position and also runs the risk of a neighbour being able to return it.