Second Life News 2019 w12

Last Friday was the Third-Party Dev UG meeting. The meeting ran for 52 minutes.

RC viewers to update in week #12. As of today, not yet. Security update for Chromium revealed some problems. Google has been updating all their Chrome products with the security patch. Oz Linden is encouraging all dev’s to update. That translates to users as a reason to get the next set of viewer updates.

Grab a beer and enjoy the sunset

Grab a beer and enjoy the sunset

This set of updates takes care of a problem that is in the wild and being used. I’ve heard you have to visit a malicious website for the exploit to be used.

The EEP, BoM, and EAM versions of the viewers are waiting for server-side updates. The hope is the server updates will make it through this week (#12). Rider Linden says the plan is for the EEP simulators to roll grid wide. Currently, EPP is on Blue Steel and Le Tigre RC channels. If they advance, it will be a big step for EEP (Enhanced Environment Project).

The Lab has been doing experiments, testing, and collecting data to sort out the problem of stuff detaching when crossing regions.

Some of the dev’s have noticed the problem seems worse when you have been in a busy region, have complex attachments (lots of parts in a link set), and have lots of attachments on a single attachment point. The probable cause is lost messages from a busy server. But, too soon to be certain.

Others think it is the sim you left sending detach messages. Some say they can get the problem to reproduce by crossing regions at corners, where two crossing are made in quick succession.

As a possible preventative make sure your attachments are not piled on your right hand. That right-hand attachment point is the default. Many designers never change that. With rigged-mesh-anything the attachment point used doesn’t matter location/position-wise. So, you can move things to other attachment points with no visible change.

Servers

Late Monday Caleb Linden posted the server’s Deploys post. It looks like EEP will go grid wide this Tuesday. So, the main channel will get version #19.03.07.525089, which is the EEP version that ran in the RC’s last week.

Blue Steel and Le Tigre – These channels will continue to run #19.03.07.525089, so no roll.

Magnum – This one is a little different. The update will happen on Thursday 7-10:30 AM PST. Version #19.03.15.525315. If I have it right, Magnum got the server OS update last week. This week EEP will be added to this channel. So, we have the new OS and EEP running in Magnum.

The Lindens are looking into the accounts of scripts using more memory and script time. Various region owners are feeling the pain and working to sort out the problem. The effort is resulting in requests for some new tools that would better report script use.

Viewers

Version 6.1.0.524670 is still running as the main viewer.

Second Life EAM Viewer version 6.2.0.524909 – Updated in week #11.

Second Life EEP Viewer version 6.1.1.525044 – Updated in week #11.

Second Life Love Me Render Viewer version 6.1.1.524929 – Updated in week #11.

Second Life Project 360 Snapshot Viewer version 5.1.6.515934 – Last updated in 2018 week #10. We are over one year.

Second Life Project Bakes On Mesh Viewer version 6.0.2.524367 – Updated in week #11.

Third-Party Viewers

Black Dragon 64x – Update 3.4.5 “Audible Dragon” – This release has the Google security fix for CEF, the browser and media display built into the viewer. Not much else.

This version switches to the new viewer update process. From what Niran says, this is on the experimental side. Until another update comes along you likely won’t notice the change.

 Other News

WARNING: Second Life Maintenance – The Lindens are advising there will be Inventory System Maintenance from 5:00 AM to 7:00 AM PST on March 20, 2019. So, during that time expect problems logging in, rezzing things, and conducting transactions.

Love Made in SL: Meet Calisto and Talon – Aaaw… here is another of those love-connection-made-n-SL stories. This popped up in SL’s blog section Featured News. Seems they are doing more with this Featured News channel of promotion. Whatever, this is a part of a series (playlist URL).

Ryan has an article on what your VR avatar may look like in 10 or 20 years. See Facebook Reality Labs Gives Us a Preview of What Your Avatar Could Look Like in the Future.

I keep wondering how they plan to capture facial expression when one is wearing a VR Headset… Obviously, the tech has to change.

I also wonder how many people will be interested in having their avatar look like their RL self? That is possible in SL now. Not many people do it.

2 thoughts on “Second Life News 2019 w12

  1. “Others think it is the sim you left sending detach messages.”

    I can prove it !

    Get the Cool VL Viewer, disable the workaround for lost attachments (un-check Advanced -> Network -> Ignore bogus kill-attachment messages), enable the “Attachments” debug tag (from Advanced -> Consoles -> Debug tags) and the debug console, then TP and/or cross region boundaries. Just watch the debug messages that will allow you to track every event dealing with your attachments thanks to the special debug code I added to understand and fix this issue.

    You will see that, often (but not always), the departure sim sends a “kill object” messages for your attachments (which causes them to de-rez in your viewer) while you are already in the arrival region; in this case, the arrival region usually sends a re-parenting message for your attachments (they get parented to your avatar again and thus re-rez). Sadly, the re-parenting message is sometimes (often) not always received or incomplete, or even received before the kill message from the departure region (race condition), causing some attachments not to re-rez in your viewer.
    Interestingly, the arrival sim always got the correct, full list of your attachments since you will notice that, even if not rezzed, they are still active (their scripts still work): this is also why, when TPing or crossing a boundary to another sim, your attachments often reappear (the region still transmitted them right to the next sim).
    To make things even more complicated, the bake server (which keeps a copy of your COF) seems to receive as well the kill and re-parent messages from the sims, and is therefore reflecting the same bad state for your attachments in its copy of the COF; this is why, in my workaround for that bug (which simply ignores the bogus kill object messages sent from the departure sim), I also trigger a COF resync and a rebake…

    What amazes me most, is that LL seems to be discovering this serious issue just now while it got suddenly introduced around the last rolling restart that happened just before Christmas.

  2. “Others think it is the sim you left sending detach messages.”

    I can prove it !

    Get the Cool VL Viewer, disable the workaround for lost attachments (un-check Advanced -> Network -> Ignore bogus kill-attachment messages), enable the “Attachments” debug tag (from Advanced -> Consoles -> Debug tags) and the debug console, then TP and/or cross region boundaries. Then, just watchethe debug messages that will allow you to track every event dealing with your attachments thanks to the special debug code I added to understand and fix this issue.

    You will see that, often (but not always), the departure sim sends a “kill object” messages for your attachments (which causes them to de-rez in your viewer) while you are already in the arrival region; in this case, the arrival region usually sends a re-parenting message for your attachments (they get parented to your avatar again and thus re-rez). Sadly, the re-parenting message is sometimes (often) not always received or incomplete, or even received before the kill message from the departure region (race condition), causing some attachments not to re-rez in your viewer.
    Interestingly, the arrival sim always got the correct, full list of your attachments since you will notice that, even if not rezzed, they are still active (their scripts still work): this is also why, when TPing or crossing a boundary to another sim, your attachments often reappear (the region still transmitted them right to the next sim).
    To make things even more complicated, the bake server (which keeps a copy of your COF) seems to receive as well the kill and re-parent messages from the sims, and is therefore reflecting the same bad state for your attachments in its copy of the COF; this is why, in my workaround for that bug (which simply ignores the bogus kill object messages sent from the departure sim), I also trigger a COF resync and a rebake…

    What amazes me most, is that LL seems to be discovering this serious issue just now while it got suddenly introduced around the last rolling restart that happened just before Christmas.

Leave a Reply

Your email address will not be published. Required fields are marked *