The Server Beta meeting provided more insight into new Linden Scripting Language (LSL) functions, but no rollout surprises. Server rolls were as planned, see: Second Life News 2013-24 #2.
Kelly Linden posted in the Deploys thread about the new LSL functions for returning items. (See: post) Kellz provided some basic guidelines and thoughts on exploits.
- There are no cases where one of these new LSL calls would return an object that you could not manually return yourself.
- There are some cases where these new LSL calls will not return objects that you could manually return yourself:
- To prevent severely damaging accidents the mass returns by owner (llReturnObjectsByOwner) will not work for your own items, items owned by an estate owner or manager or items that are owned by the group the land is ‘set’ to.
- To protect some of our back end systems there are some fairly generous throttles in place. These functions should be able to return everything on your land within a region in one go, but not necessarily more than once an hour for such a large return.
- There is a required runtime permission.
- This is not a solution to griefing or ‘grey goo’ attacks. These calls can help with sandbox cleaning and automated rental property management. In some limited cases it may help with griefing cleanup, but the throttles mean it will only be effective after the cause is cleaned up or stopped. It is also not great for dynamic content (alife etc) because objects are returned to their owners inventory – there is no way to return to an object’s contents or ‘delete’ an object with these methods.
I suppose the idea is if you can return something using land tools in the viewer, then the new LSL function allows you to automate that task. You don’t get any new powers.
Kelly made clear in the post and at the meeting that these tools were not intended as anti-griefing tools.
There have been questions about the return throttles. These throttles are limits set to protect the servers from high loads. Basically, if your parcel has 100 prim limit, your script can return 100 prims per hour. If your land has a 500 prim limit, you script can return 500 prims per hour.
Also, the throttles are per owner, not per script. So, you cannot put 3 scripts in your object or 3 objects with one script each on your 100 prim parcel and expect to get a 300 prim/hour return rate.
Andrew Linden told us the Magnum package got two additional fixes; the excessive Avatar-Appearance packets, and his final fix for Meeroos, which is the fix for slow viewer updating of animated objects. The bug happens when you turn your back on any animated object. The new Interest List processing cut back on updates of the item. The viewer then had to catch up when the item came back into view. The result being the animation appeared to be broken.
Andrew has been working on get this fixed for a couple of weeks. Each iteration of the fix has gotten better.
There has been a problem with scripts that use HTTP functions losing connection with their remote hosts. That apparently was related to the Mass Disconnections people experienced, a network problem. It was thought to be fixed with the release of this week’s rollout to the main channel.
Users are reporting it was not a complete fix. Maestro and Kelly Linden are looking at the problem. It is a confirmed bug the Lab can reproduce, so they are working on a fix.
The subject of texture induced viewer lag came up at the meeting. As the viewer only allows the video card to devote a max 512mb of VRAM to texture storage the excessive use of 1024×1024 textures is creating excessive viewer lag.
It is possible to turn on texture compression in Preferences. (Preferences->Graphics->Hardware->Enable Texture Compression (requires restart)). This feature is for those with video cards that have small amounts of VRAM on the video card. It causes the textures to be compressed when stored in VRAM. It does degrade the quality of the rendered texture. You have to try it and see if the speed improvement is worth the loss of quality. If you have 1 or 2gb of VRAM, you’ll probably lose performance and quality if you use texture compression.
The SL Wiki describes the setting as:
Texture Compression (also called ‘lossy compression’ in other viewers) – switching this setting can drastically change the graphical performance of the viewer. On slower graphics cards it can give a huge performance boost, as texture compression reduces the amount of video memory used by the graphics card. It can also reduce the performance on computers with some faster graphics cards, because the computer needs to do some extra calculations to compress the textures.
See an example of the result in the SL Forum post: Bad Graphics.
I find it amazing that so many want more limitations imposed on Second Life just to save them some inconvenience. Whatever…
Refer to Penny Patton’s article: Building Better.
I think something that would be a big help is getting Render Advanced->MetaData->Render Complexity working again. Some tool that is easy for builders/creative types to use that easily shows the render weight of everything in a scene would be a big help.