Deploys for the week of 2013-06-17 (Updated @ 2013-06-18 16:18PDT)

[Maestro Linden]

Updated the version number for the RC updates, at 2013-06-18 16:18PDT.

 

Second Life Server (main channel):

The main channel is getting the interest list improvement project that was on Magnum last week.  This change reduces scene loading time when entering a new region.

https://wiki.secondlife.com/wiki/Release_Notes/Second_Life_Server/13#13.06.07.277164

Scheduled Tuesday 2013-06-18 05:00-12:00 PDT

 

Second Life RC BlueSteel, Second Life RC LeTigre, and Second Life RC Magnum:

All three RC channels are getting the server maintenance project which was briefly on BlueSteel and LeTigre last week.  This project fixes some crash modes, addresses an issue with neighboring region visibility, and adds some new scripting features.

https://wiki.secondlife.com/wiki/Release_Notes/Second_Life_RC_BlueSteel/13#13.06.18.277494

https://wiki.secondlife.com/wiki/Release_Notes/Second_Life_RC_LeTigre/13#13.06.18.277494

https://wiki.secondlife.com/wiki/Release_Notes/Second_Life_RC_Magnum/13#13.06.18.277494

Scheduled Wednesday 2013-06-19 07:00-11:00 PDT

 

We will be monitoring this thread as the code gets released, so feel free to note any observations you have about the server updates.  If you have a specific bug you'd like to report, please file a Jira. 

[Honza Noyes]

Thank you guys very much for pushing BUG-2833 fix to the RC channels. It means a lot to me.

[Amber Murfin]

I notice this in the release notes for the RC channels...

• Neighboring regions should now appear to the viewer sooner after a region restart (SVC-8019[c])

Just so we know what we are expecting, is this a complete fix for the regions appearing to be off line on the mini map even though they are back up and running after a re-start? are we able to define "Sooner" is that an hour, a day?

This has been one of the most frustrating bugs in the Fighting sail community as some sims stay affected and only (sometimes) appear correctly on Monday only to be restarted on Tuesday and be back to square one again! as i'm sure you can understand, being hit by ships / people in sims you can't even see is preventing many people from having as much fun as they would otherwise have.

any information about what we should be able to expect to see would be greatly appreciated, and i'll be keeping a close eye on it  

 

Amber

[Maestro Linden]

Hi Amber, the original bug in this particular case is that regions wouldn't communicate with their neighbors for up to an hour after a region restart, causing neighboring regions to be invisible and also block things like LSL chat across sim borders.  With the fix, the hope is that regions should reconnect to each other after a few minutes of a region restart.

[Amber Murfin]

---

Maestro Linden wrote:

Hi Amber, the original bug in this particular case is that regions wouldn't communicate with their neighbors for up to an hour after a region restart, causing neighboring regions to be invisible and also block things like LSL chat across sim borders.  With the fix, the hope is that regions should reconnect to each other after a few minutes of a region restart.

---

Thanks Maestro, I appreciate you may not know, but Regions appearing as red on the minimap, and not being visible in world, then being visible when you change sim bug that's been ongoing for a number of months (I don't have the Jira reference i'm afraid), is there an ETA for that at all? 

I seem to remember it got better for a week or 2 after some re-organisation at the network end but in recent weeks and month shad got worse again. it is highly frustrating when trying to run battles accross multiple sims and it seems to have been with us for quite a while now...

When in the Region Following Seas for example, it is incredibly rare i will be able to see into Cursed Rock, despite being able to see sims around / beyond it. Sometimes when First TP'ing in you will see it, but it eventually vanishes after around a minuite or so.

[Maestro Linden]

That case you describe could be the same bug, or could be a different bug, such as SVC-8130.

One way to investigate is to note whether the disconnect is due to a breakdown in simulator<>simulator communication between neighboring regions, or just an issue with viewer<>simulator communication.  In the latter case, scripted objects in neighboring regions should be able to hear each other's chat when within range.

[WolfBaginski Bearsfoot]

If it is Viewer-Server that's the problem, there might be a difference between viewers, but it would depend on just where the problem lies in the Viewer code. Would any developer have ever bothered to work on that part of the system? Still, it would make some sense to report the Viewer being used.

I routinely use Firestorm, and sims do go missing, or take a very long time before they suddenly rez. Usually, it's still possible to teleport into them, and the built-in radar system in Firestorm can list the people there. But I shall have to see what the changes have done.

 

[Amber Murfin]

---

Maestro Linden wrote:

That case you describe could be the same bug, or could be a different bug, such as 

SVC-8130

.

One way to investigate is to note whether the disconnect is due to a breakdown in simulator<>simulator communication between neighboring regions, or just an issue with viewer<>simulator communication.  In the latter case, scripted objects in neighboring regions should be able to hear each other's chat when within range.

---

I can confirm that it doesn't matter which viewer i use, Looking from Following Seas into Cursed Rock as an example, i can't see the sim. I have tried Firestorm 4.4.0, the Materials Beta Viewer and have just installed and tested the Curent SL release viewer as well.

 

Scripted objects can communicate accross the border fine, you can sail or walk into the region fine, and infact if i walk west into Sabres Edge,  the sim appears both on the mini map and in the main viewer screen (Although Cartagena Isle then dissappears instantly). When i cross back east again (Back into following Seas), The Region stays rezed, although you'll sometimes stop seeing other objects or ships move if there are any in the region (may or may not be related), but after around 60 seconds or so the sim vanishes again...

 

I was hoping this was the fix being deployed when i first spotted it last week, unfortunatly, it is not all diagonal regions that are affected it seems, and i do not sail enough in any estates to accuratly tell if the version that rolls today fixes the issue or not (all the sims above are Main Server channel sims), although i will experiment and see if i can replicate this issue looking into (or out off) any RC sims.

[Maestro Linden]

Okay, then it sounds like you're seeing SVC-8130 after all, which has not been fixed with this RC update.

[Triple Peccable]

I believe the diagonal sim visibility problem is not a simulator<>simulator or a viewer<>simulator communication problem, it is a simulator<>central server communication problem.

The problem started over a year ago, when I filed a JIRA about TCP connections remaining open, causing 1000's of connections to pile up as one moved through different sims. At the time the issue was resolved, it was stated the problem wasn't with the server code, it was with the central servers code.

That is when the diagonal sim visibility problem initially started.

I believe a patch was applied back then that actually didn't fix the problem, it just masked it. I say that because ever since then a series of different problems have cropped up, all seemingly related to the simulator getting the wrong information from the central servers. Since then more patches have been applied to fix these different anomalies as they crop up, to the point now where it might not be fixable.

Here is a little demonstration that illustrates the corrupt data coming from the central servers:

Go to an area with lots of adjoining sims. I used Blake Sea - Nelson (128,128) because most of the surrounding area is open water. Open your mini-map, and zoom all the way out. Then turn your draw distance all the way up.

As they connect, you will see all the surrounding sims on the mini-map painted as blue squares. Now, turn your draw distance all the way down, and wait until the connections with the distant sims are dropped (at least one minute, each square changes from blue to black).

What you should see are only the surrounding sims in blue, but what I saw just now when performing this test is only 2 of the adjoining sims staying connected (the ones to the west and the south). There are 2 other sims in the wrong spots staying connected, which I assume should be the ones to the east and north. I submit that these sims are staying alive in the wrong spots because the data coming from the central servers is for the wrong sims (or the simulator is requesting the wrong data), and that it has been that way for over a year.

Even though I am the only avatar in the sim, I see lots of green dots plastered against the border to the north. Those avatars are in the sim to the north, but because that sim is missing the viewer has no other place to draw the green dots. That is just one example of the many different types of problems this central server problem is causing. Red mini-maps is another.

 

[Amber Murfin]

@ Triple Peccable. That's pretty much as i recall it.

 

I appreciate this is not maby the correct forum to raise this in (i will try and make the Meeting tomorrow) but is there an update on this at all as it has been going on a fair while now?

[Perrie Juran]

  

 

Brilliant continues to be unusable after the restarts.  I posted about this in last weeks notes. I see no signs of griefing, self replicating prims, particle spam, etc. so I don't know what to report.   Completely unable to move or do anything there.  It is a BlueSteel SIM.


You are at 255,921.0, 255,802.0, 52.7 in Brilliant located at sim10218.agni.lindenlab.com (216.82.49.140:13018)
Second Life RC BlueSteel 13.06.18.277494
Error fetching server release notes URL.

http://maps.secondlife.com/secondlife/Brilliant/177/58/53

[Maestro Linden]

Hi Perrie, you can't move in 'Brilliant' because physics is disabled in that region.  You'll need to contact support to clear that region setting.

[Perrie Juran]

---

Maestro Linden wrote:

Hi Perrie, you can't move in 'Brilliant' because physics is disabled in that region.  You'll need to contact support to clear that region setting.

---

Reported

Thank You

[Jean Horten]

Stuff ( prims, mesh, textures, avatars) loads really really bad with the latest interrest list changes on  main channel sims.  It takes between 5 and 10 minutes until I can see everything, using a dd of 128 here, triend with various viewers. Can we get this fixed please? Each interrest list 'improvement' seems to make it worse.

Jeannie

[Norton Burns]

my apologies, it's late Friday night & I don't have time to properly investigate, but I'm seeing major issues with my weapons scripting system in RCs, both sandboxes & 'user' regions. The only thing I can possibly imagine is it could be the perms changes, but I'm guessing. The 'broad' version is if I go to RC, the weapons will draw, once, then won't sheath, subsequent attempts fail, alphas don't change, but some draw/sheath anims [hard to tell quite which] do appear to trigger - but swapping between weapons, the HUD sends messages, the weapons don't repond correctly. The HUD itself appears to behave, sending messages, but the weapons no longer respond. [HUD needs no perms, weapons do - hence my first thought as to cause] - but end result; broken.

Script reset gives short-lived functionality, possibly same as at first entry to RC - i've been trying to accurately diagnose, but too much info, too late in the day.

Soon as I TP anywhere off RC, functionality is restored, no script reset required. The scripts themselves in normal use never reset, other than at owner change.

It might not be rocket science, but this is a very well routined, error-trapped script set, in use by some thousands of users.

Freebies available to anyone whose name begins with 'L' ;-)

I need to Jira, but... tomorrow... yawn... sorry.

[Norton Burns]

Filed as https://jira.secondlife.com/browse/BUG-2931

Transcript below, for those who can't see BUGs

I've marked this as showstopper, because for me this is a disaster… I have thousands of users, dozens of 3rd party makers using my scripts, who would all have to update their entire product lines to workaround this…

llRequestPermissions(ownerID,non-zero-integer);
calls run_time_permissions

llRequestPermissions(ownerID,0);
has stopped calling run_time_permissions

I was always taught never to guess, rely on runtime to know when perms are ready or not - so I use perms drop to trigger actions as well as perms acquire.

roughly …
run_time_permissions(integer permission) {
if (permission & various masks) {do appropriate setup, depending on mask;}
else if (!permission) {shut things down tidily;}
}

On all 3 RC servers this week, runtime is no longer called by llRequestPermissions(ownerID,0);

[Lucia Nightfire]

For the past few days I have also see many RC regions with bad performance with worn/rezzed mesh LOD, clothing/skin layer & texture loading. This even happens in regions with as little as 4 agents. Net timing, agent timing and simulator timing runs higher than average and all periodically spike. Script events seemed throttled whether or not these timings are lite or not, especially worn scripts. Also seeing reduction in running script % where some regions that had in the upper 90's are now running 75 - 80%. TD/FPS, though are ok.

@Norton, I also see that failing to trigger on server version 13.06.07.277164. It doesn't fail to trigger on version 13.05.20.276191 (tested on aditi)

 

 

[Norton Burns]

Simple test script for this - drop it into an attachment, doesn't work on the ground.
Click it on/off, perms integer is reported in chat. Should alternate between 20 (animation perms) & 0 (none)

integer switch;

default {

    touch_start(integer total_number) {

        if (switch = !switch) llRequestPermissions(llGetOwner(),20);

        else llRequestPermissions(llGetOwner(),0); }

    run_time_permissions(integer perm){

        llOwnerSay("perms=" + (string)perm);

    }

}

[Darien Caldwell]

Ehhh, that's a bad hack to rely on. I guess you thought calling with 0 released permssions, but that's not been the case for a very long time, see this JIRA:  https://jira.secondlife.com/browse/SVC-1006

There is no way to release perms, short of resetting the script, or calling for a different permission. (i.e. if you aquired PERMISSION_TRIGGER_ANIMATION, then later aquire PERMISSION_DEBIT without again asking for PERMISSION_TRIGGER_ANIMATION, the animation permission is lost.)

That being said, I think this should fall under legacy behavior as I'm sure many older scripts still use this convention, even though it doesn't actually peform any action.

Gets a +1 from me.

[Norton Burns]

Whther the prems are strictly 'released' or not was not really the issue I'm debating - I'm aware of SVC-1006 though I have been using this method since long before that was ever posted, probably since 07.

Everybody seems to call this a hack, but if you replace the last line with llOwnerSay("perms=" + (string)llGetPermissions()); you still get the same result, alternating between 20 & 0, unless you're on an RC sim, when you get no response for 0, as it doesn't go through runtime.

Changing the script to

integer switch;

default {

    touch_start(integer total_number) {

        if (switch = !switch) {

            llRequestPermissions(llGetOwner(),20);

            llOwnerSay("aquire perms=" + (string)llGetPermissions());

        }

        else {

            llRequestPermissions(llGetOwner(),0); 

            llOwnerSay("drop perms=" + (string)llGetPermissions());

        }

    }

    run_time_permissions(integer perm){

        llOwnerSay("perms=" + (string)llGetPermissions());

    }

}

 

actually reveals more - that the perms themselves are not dropped at all on RC

perms should alternate between aquire=20 & drop=0, whether or not runtime is called. On RC, that does not happen, the result is always 20.

PS - I just realised Maestro's test script in SVC-1006 relies on runtime to report the results ;-)

[Amber Murfin]

---

Maestro Linden wrote:

Okay, then it sounds like you're seeing SVC-8130 after all, which has not been fixed with this RC update.

---

After a lot of testing i have filed "BUG-2951 - Some regions not visible from other reasons despite being within Draw distance" which contains all my findings. I apprecaiate it is a long bug report but it is as comprehensive as i can be....