In the USA Thursday 11/22 is Thanksgiving Holiday. So, week 47 is going to be a ‘no change window’ for Second Life™ upgrades. Also, the normal Server Beta User Group meeting won’t happen.
Server Side Memory Leak
Some people are hearing of script lock ups. Examination of the servers where this is reported reveals memory use at the 32-bit process limit. Maestro Linden thinks recent sensor changes were the source of that problem. In any event the sensor memory leaks have been fixed. I’m unclear on whether those fixes are in the current RC channels.
Still some locks up are being seen. If you are experiencing them, file a JIRA BUG. Script item, region, and as precise a time as possible are needed.
Interest List Update
Andrew Linden’s work on the Interest List is moving forward. He announced earlier that he might be able to demo the code for the Thursday Sever Beta meeting. Part of the problem with doing a demo and getting a good measure of performance differences is the need for identical regions running on different server code.
Andrew had a demo of the new code using a ‘jumper,’ a scripted object that jumps… But, he couldn’t rez it in Morris. Maestro had just taken over as owner of the region. Between rez-rights and the ADITI password-change-inventory problems Andrew couldn’t rez it… which is both funny and sad. Also, a number of people could not log into ADITI with their normal accounts and arrived at the meeting wearing alternates. ADITI is a test grid and prone to odd problems.
So, the meeting moved over to Ahern. Once in Ahern Andrew had everyone turn on: Show Updates to Objects. (Ctrl+Alt+Shift+U or Develop-> Show Info-> Show Updates to objects) This feature causes a stream of red, blue, or green particles to appear above the object to show when an object gets a full or terse update.
I have written about this debug feature before, but Andrew provided a bit more information saying, “Blue updates are known as “terse” and just have position/velocity info, and face color too. Red updates are “full” and happen whenever the object changes scale, or floating text, and misc things. Green updates are known as “KillObject” updates, and basically mean the object was deleted or… was removed from the server’s interest list –> it isn’t going to send updates for that object anymore.”
Maestro added, “Also, Red appears when an object first appears in your view, since a full update gives the viewer all the info it needs to render the object.”
Andrew’s ‘jumper’ is a cube scripted to jump every 3 seconds. This creates a stream of updates each time it jumps.
I’ll paraphrase Andrew’s description of the demo. In this new interest list code the server will stop sending you updates if the object is out of the field of view for a time. To see that happen, one goes into mouse-look and looks at the cube/jumper. You will be able to see the particles streaming out the top and up. Title the view up until the cube/jumper just goes out of view at the bottom. For a time you will see the particle stream continue. After a time the stream will stop when the server decides to stop sending updates.
If you try the experiment anywhere in the channels of AGNI, the particle stream will continue. That is the difference between the current interest list code and Andrew’s new code.
You may occasionally notice object flashing/flying through your view. This can happen repeatedly if you find a Pathfinding character on patrol. Say the character is patrolling from A to B. Adjust your view so either A or B is near the edge of your field of view and that path from A to B is mostly in your view. Change you view to just move either A or B just out of your view. When the character makes it to the patrol point and heads toward the other point you should see a copy of the character fly through your field of view. Depending on I don’t know what all, the direction and speed can vary.
Officially I guess this problem is: PATHBUG-183 – Physical swimming dolphin ghosts flying off out of the sim since Pathfinding deployed.
Andrew says the new interest list code should fix that problem.
Andrew is not sure exactly how fast moving objects will work. A fast mover coming from outside the field of view, crossing, and leaving the field of view are expected to be more likely to never be rezzed.
Also, there is a packet expiration of 5 seconds. If an update packet gets lost, it expires. I suppose the idea is to keep late arrivals from upsetting things. Remember. The viewer attempts to predict where things are going. Updates that disagree with the viewer’s prediction in the case of avatars is what we call rubberbanding. Before totally ignoring an object’s expired update packets, additional checks on updates are made to help to decide what to do with or how to update the object… or something along that line.
What this means is that if you look away from a pile of the demo cube/jumpers it can take up to 5 seconds for them to start getting updates when you look back. Andrew says they are experiementing with the 5 second value to see what works best.
Visibility and LoD
Another change in the Interest List Code that Andrew told us about is the reference point for which Level of Detail (LoD) display is calculated. Now LoD is calculated relative to the camera all the time. This is a change from calculating it based on the avatar position.
You have probably noticed that if you change your camera to unrestrained (top menu: Advanced-> Disable Camera Restraints) and begin to cam around as you get farther from the avatar small things stop rezzing. The farther you get the more things do not rez. This change to using the camera position will change that. As you pan about, things will more correctly rez for the camera.
There is still an avatar position factor. The LoD will be better for the camera up to 128m from the avatar. Farther than that and things will tend not to rez. Andrew says they clamp the distance your camera can move from the avatar.
In the main grid with the camera restrained I can move it about 300m from my avatar. Even into the next region. If I click off the restraints I can move the camera more than 512m from the avatar. However, only things within 300m of the avatar render, except the ground which renders out to 512m or 2 regions out.
I cannot log into the ADITI grid with my main avatar. Even with an Alt I had so much trouble I could not test the camera limits in Ahern. So, I don’t know if they are changing.
Apparently there is a problem with the new code and mesh. When you cam a distance to look around the LoD on mesh may not work so well. Andrew is looking into that problem.
There was some problem in Ahern with parts of other peoples HUD’s being visible in other people’s viewer… appearing on their screen.
Whether this is an ADITI thing or an Interest List thing isn’t known.
The problem is reported in BUG-797 – When HUD is attached, other avatars’ HUDs show up as invisble objects in centre of screen. It is described as:
At the Server User Group, on a simulator with the new interest-list code.
Right-clicking on the middle of my screen reveals random prims from other peoples HUDs.
The avatars shown as the owners confirmed that they were wearing HUDs with these prims.
The prims are able to be touched if they have a touch event (stealing touches from anything behind them), and the list of contents can be viewed if the prim has contents.
They are selectable, but completely invisible – no textures are shown.
They do not show up on my “Wearing” list.
This behavior cannot be reproduced if no HUDs are attached to me.
If they are, it seems to occur regardless of what attachment point my HUD(s) are attached to.
See the opening image for an example from the JIRA.
The image shows Ana Stubbs’ screen with parts of MellAnnColi Lyric’s HUD.