Jump to content
Sign in to follow this  
Oskar Linden

Deploys for the week of 2012-10-22

You are about to reply to a thread that has been inactive for 2816 days.

Please take a moment to consider if this thread is worth bumping.

Recommended Posts

 

Second Life Server (main channel)

We are promoting the code from Magnum to the main channel this week. This is a maint-server project.

  • Bug Fixes
    • Back end infrastructural changes.
    • No intentional change to behaviour.

  2012-10-23, 5:00am: Release Notes: https://wiki.secondlife.com/wiki/Release_Notes/Second_Life_Server/12

  

Second Life RC BlueSteel

This is a maint-server project. There are no simulator changes. It's all back-end infrastructure work. 

2012-10-24, 7-11:00am: Release Notes: https://wiki.secondlife.com/wiki/Release_Notes/Second_Life_RC_BlueSteel/12

 

Second Life RC LeTigre

This channel has updates to Havok among other things including bug fixes. 

 

  • Features and Changes
    • Updated the Havok physics engine to version 2012.1
    • Enables Havok's "Collision Geometry Optimizer" for the terrain, which simplifies the physics shape of the terrain for improved performance.
      • This can be disabled by region owners and estate managers with the Region Debug Console command "set optimize_terrain false".
    • Includes a new LSL function to access simulator statistics, llGetSimStats.
      • Usage: float llGetSimStats(integer stat_type)
      • Currently, this function accepts only SIM_STAT_PCT_CHARS_STEPPED as its parameter, which returns the % of pathfinding characters skipped each frame, averaged over the last minute. The returned value corresponds to the "Characters Updated" stat in the viewer's Statistics Bar.
    • Includes a new option for llCreateCharacterCHARACTER_ACCOUNT_FOR_SKIPPED_FRAMES. Default is true to match pre-existing behavior. If set to false, character will not attempt to catch up on lost time when pathfinding performance is low, potentially providing more reliable movement (albeit while potentially appearing to be more stuttery).
    • Changes to pathfinding character throttling, so that characters may be permitted to exceed the previous 50µs limit per frame if there is sufficient spare time available.
    • Added a new parameter to llGetObjectDetailsOBJECT_PATHFINDING_TYPE, which returns the pathfinding setting of any object in the region. It returns an integer matching one of the following new constants:
      • More details about pathfinding types can be found here
    • Other internal system changes
  • Known Issues
  • This version changed default HTTP headers sent by llHTTPRequest
    • Previous server versions sent a "Pragma: no-cache" header; this version does not.
    • Legacy llHTTPRequest() behavior can be restored via the HTTP_CUSTOM_HEADER option, e.g. llHTTPRequest(url, [HTTP_CUSTOM_HEADER, "Pragma", "no-cache"], "");
  • Mesh objects (such as vehicles) cannot physically cross from a region running Havok 2012.1 into a region running an older version of Havok, due to the upgrade to a newer version of the Havok physics engine. Currently (2012-10-17), RC LeTigre is the only channel with the latest Havok upgrade.

2012-10-24, 7-11:00am: Release Notes: https://wiki.secondlife.com/wiki/Release_Notes/Second_Life_RC_LeTigre/12

 

Second Life RC Magnum

Magnum had serious issues with llSensor() and was stopping breedables from breeding. We are removing the new code and replacing it with the code that is on BlueSteel. It will have the changes listed in BlueSteel instead.

2012-10-24, 7-11:00am: Release Notes: https://wiki.secondlife.com/wiki/Release_Notes/Second_Life_RC_Magnum/12

 

Second Life RC Snack

Welcome back Snack! If yo udon't know we occasionally use the snack RC for smaller use cases. They're purpose made and usually not around for very long. This time Snack will have the code that got pulled from Magnum. It is only on 4 regions on the main grid. Search for 'Snack' from the map window.

The most notable change is the fix for large groups (over 10,000 members). On the Snack regions, with the development viewers linked below these groups will load!

 

  • Bug Fixes
    • Linkability distance rules are broken
    • Group won't load - too many members. This provides a new capability to viewers to fetch member lists for large groups.
    • Get the development viewer here:
    • Converted over 50 hard-coded messages on the server to a localizable data format that can be properly displayed in the correct language in the viewer. A future viewer release will contain the messages and tags for translation.
    • Thanks to a newly added capability the simulator can now report information about script permissions granted to objects within a region. A future viewer update will use this.
    • Restored functionality of the Estate Tools, Debug, Disable collisions feature. Invoking this feature will put the affected region into a state with very limited physics. This is useful when trying to untangle performance issues or clear unwanted objects.

2012-10-24, 7-11:00am: Release Notes: https://wiki.secondlife.com/wiki/Release_Notes/Second_Life_RC_Snack/12

 

We will be monitoring this thread during the next week so please feel free to post issues that you feel have been introduced by the new code. Please file a JIRA for issues you find and post the JIRA link into this thread. It really helps us out. When determining if issues are relevant or not research is key. Tracking down exactly the right situation where an issue is occurring greatly speeds up the development process to get fixes in place.

I appreciate your help. Have a good week!

 

__Oskar

 

p.s. If you are interested in helping test SecondLife in beta please join the group "Second Life Beta" in-world. We also have an email list where we communicate upcoming projects and how you can help. (https://lists.secondlife.com/cgi-bin/mailman/listinfo/server-beta ) Once a week we meet on ADITI to discuss new features, new bugs, new fixes, and other fun stuff. You are more than welcome. Information is here:https://wiki.secondlife.com/wiki/Server_Beta_User_Group

 

This is not a forum thread for off-topic and unproductive ranting. I will no longer tolerate it. This forum thread is to discuss newly found issues in the Release Candidate channels. If you feel the need to have your opinions heard on topics unrelated to new bugs then please start your own thread. If an individual continues to post unproductive and off-topic comments I will take measures to remedy that.

If you are unsure about your posting please read this : "Linden Lab Official:Community Participation Guidelines"

Share this post


Link to post
Share on other sites

Thanks, Oskar.

I'm confused about LeTigre: Apparently it's scheduled for a roll tomorrow (the 24th), but the update list looks the same as what was rolled on the 17th. (Or maybe I've lost track of what happened with LeTigre last week. Or maybe I'm just being dense.)

Share this post


Link to post
Share on other sites


Qie Niangao wrote:

Thanks, Oskar.

I'm confused about LeTigre: Apparently it's scheduled for a roll tomorrow (the 24th), but the update list looks the same as what was rolled on the 17th. (Or maybe I've lost track of what happened with LeTigre last week. Or maybe I'm just being dense.)

You are correct! The same changes as last week with the added bonus of the code from trunk.

__Oskar

Share this post


Link to post
Share on other sites

Zen Estates has been down all day since the rolling restarts, any idea whats up? anyone who Tp's there crashes. I tried phoenix and SLviewer. Jaida Linden said they had no problem going there and reports it is up. I trird logging in as wel lto the Estate.

Please get this one fixed been about 5 hours at least, since it came back from the rolling restarts. Thanks

 

**Update** Fixed, unsure what the cause was that affected at least one tenant and myself. But can now TP to it without crashing!

Share this post


Link to post
Share on other sites

LeTigre has an interesting thing that should be noted. We documented it in the release notes for this week, but the issue exists previously:

This version changed default HTTP headers sent by llHTTPRequest

  • Previous server versions sent a "Pragma: no-cache" header; this version does not.
  • Legacy llHTTPRequest() behavior can be restored via the HTTP_CUSTOM_HEADER option, e.g. llHTTPRequest(url, [HTTP_CUSTOM_HEADER, "Pragma", "no-cache"], "");

If you have code that uses llHTTPRequest() it is possible that the data it is pulling might be stale. You should look into your code if you are seeing issues on LeTigre.

__Oskar

Share this post


Link to post
Share on other sites

On Magnum regions, llSensor() and llSensorRepeat() using moderate to long ranges (24m - 96m) are not detecting agents or objects closest to the object the sensor script is in. This is affecting all sensor types; ACTIVE, PASSIVE,SCRIPTED. Please investigate the cause. Thanks.

Share this post


Link to post
Share on other sites


Lucia Nightfire wrote:

On Magnum regions, llSensor() and llSensorRepeat() using moderate to long ranges (24m - 96m) are not detecting agents or objects closest to the object the sensor script is in. This is affecting all sensor types; ACTIVE, PASSIVE,SCRIPTED. Please investigate the cause. Thanks.

Thanks Lucia. We're looking into it.

__Oskar

 

Share this post


Link to post
Share on other sites

We are in the process of rolling back Magnum as we speak. The issues found are serious enough to warrant it. Updates here as I ahve them.

__Oskar

Share this post


Link to post
Share on other sites

Oskar

I guess you guys are busy with the Rollback on Magnum, but LeTigre sim Woods of Heaven (was sim 8910) has been down now for 45 mins, and the logout was a bit abrupt...no warnings were given.

 

ETA: OK just worrygutting it is back and all seems OK.  Just a longer downtime than I'm used to.  That and the abrupt logout.

Just one comment, I have a distinct suspicion that sculpties are getting more difficult to resolve.  Any possible reason  for that?

Share this post


Link to post
Share on other sites

Just one comment, I have a distinct suspicion that sculpties are getting more difficult to resolve.  Any possible reason  for that?

I was noticing that even simple prims are taking much longer than usual to rez-in -- and not even the textures, just the basic geometry. I wonder if maybe the internal network gets particularly swamped while updates are underway, since it seems particularly bad today.

As to the Magnum thing, yeah, wow, that was strange. As best I can tell from my scripts, stuff was getting detected, but llDetectedOwner() seemed to be returning something unexpected (although I'm not exactly sure what).

Share this post


Link to post
Share on other sites


Qie Niangao wrote:

Just one comment, I have a distinct suspicion that sculpties are getting more difficult to resolve.  Any possible reason  for that?

I was noticing that even simple prims are taking much longer than usual to rez-in -- and not even the textures, just the basic geometry. I wonder if maybe the internal network gets particularly swamped while updates are underway, since it seems particularly bad today.

As to the Magnum thing, yeah, wow, that was strange. As best I can tell from my scripts, stuff was getting
detected
, but llDetectedOwner() seemed to be returning something unexpected (although I'm not exactly sure
what
).

Ayesha, Qie: Is it just LeTIgre that has the longer rez times?

__Oskar

Share this post


Link to post
Share on other sites


Oskar Linden wrote:


Qie Niangao wrote:


Just one comment, I have a distinct suspicion that sculpties are getting more difficult to resolve.  Any possible reason  for that?

I was noticing that even simple prims are taking much longer than usual to rez-in -- and not even the textures, just the basic geometry. I wonder if maybe the internal network gets particularly swamped while updates are underway, since it seems particularly bad today.

As to the Magnum thing, yeah, wow, that was strange. As best I can tell from my scripts, stuff was getting
detected
, but llDetectedOwner() seemed to be returning something unexpected (although I'm not exactly sure
what
).

Ayesha, Qie: Is it just LeTIgre that has the longer rez times?

__Oskar

I know you directed your question at Ayesha & Qie but Last night on my home SIM (main channel) for a while I had a terrible time changing outfits, twice getting the error "SL couldn't create the requested object."

I did a few relogs.  On one of them 2/3 of my house never rezzed and I had to relog again.

Later on last night at another Main channel SIM with two other friends we were all three having trouble getting into 'edit appearance,'  We were working on adjusting poses and need to change our Avatar heights to do what we needed. Each of us had to relog at least once to get it to work.  This was an Estate Sim and we were the only three on it at the time.

While doing this in the period of an hour I crashed twice.  My two friends each crashed once. 

 

 

I was only In World for a few minutes today to check out the new CHUI Viewer and can't say if the problems from last night have persisted.

 

eta:  I don't file bug reports as a general rule and surely not every time SL has the hiccups and only request my Land Lady file a support request if a problem is persistent.

 

 

Share this post


Link to post
Share on other sites

Oskar

I might be just being subjective but the last two updates on LeTigre do seem to have lengthened rez times for some prims. I noticed the sculpties primarily because although they would appear, it took some time before they adopted the correct shape.  I thought it was my GPU at first, but others were seeing it as well.  Simple prims sometimes just do not appear until I click where I "know" they are.

While the issue seems worse on LeTigre it does seem general, though less severe, throughout SL.

One other "observation" that may be relevant: the LeTigre sims where the sculpty and simple prim rezzing is slowest also have the least "spare" time.

Oh, and just one more thing (apologies to the late Peter Falk): apropos of Perrie's comment; I've seen "Failed to create requested object" and "requested item not found" errors a lot more frequently of late, despite the "requested" object or item actually appearing!  BTW I do know that my ISP and local connections are good and are regularly rebooted!

Share this post


Link to post
Share on other sites

Oskar, this rezz time problem seems general, but it is worse in server which allocated memories that have grown significantly since the restar.  Two come readily to memory Turnip which appears to have a significant memory leak that was not fixed in the last restart, and Echo Park which has a similar problem.  Ironically Turnip in on the Blue Steel system and Echo Park the  main server group.  Significantly, Echo park also shows huge lag in general while turnip is slow at time to rezz but except after teleports and login otherwise show no severe lag.


Ironically, Osbourne Walk which has not growing allocated memory problems and Zerango which has in the past had a severe problem which apparently was fixed again in this last restart are performing fairly well.  I hope this helps in tracking down this problem because even though FPS and other traditional signs of lag has improved lag persists and the only probably explanations for it I can see are a leak that is causing massive increases in allocated memory and scripts timing out and corrupting our cpu caches.  Both these problems see to be happening and seem to be relieved by relogging our entire systems and clearing cpu cache.  Hopefully this can lead to some resolution for in some areas this is a crippling problem.

Share this post


Link to post
Share on other sites

Awesome news! We were sad that the large group fixes on Magnum were not able to get out because of the llSensor() bugs. So we put the code on the Snack regions so people can take advantage of the large group loading fixes. You will need one of these viewers:

The llSensor() bugs will STILL be there. So don't rez breedables on the test regions :-)

You can discuss the Large Group Fix changes here:

 - http://community.secondlife.com/t5/Second-Life-Server/Large-Groups-Fixes-LIVE-on-AGNI/td-p/1711341

__Oskar

Share this post


Link to post
Share on other sites

Tonight has been smooth sailing so far in world.

Normally if I'm just having a problem, well, I know many different things can cause hic cups and often times they go away after a good burp.

But last night was different when three of us were having the same problem on the same SIM.

Share this post


Link to post
Share on other sites

Oskar Linden wrote:

Ayesha, Qie: Is it just LeTIgre that has the longer rez times?


Oskar, you know, I'm not sure. The place where I first noticed it and saw it most often during the updates was LeTigre, but I saw it on Magnum sims too (pre-rollback, anyway)... but now I'm beginning to doubt myself: thinking back, I may have had shadows turned on at the time; trying again now, the moment I switch off shadows, everything in the slow-to-rez scene renders instantly, and at least right now, things seem normal when I rez new scenes with shadows turned off. I'm running the viewer on a brand new, way higher performance machine than before, so I'm now questioning my reliability as a source on such subjective things.

As to the Ayesha's mention of "Simple prims sometimes just do not appear until I click where I "know" they are", a version of this has been happening to me for months (so at least my experience of that is not RC-specific, although of course Ayesha may be seeing something new and different). The main concern I have about what I've been seeing is the prospect that it may confound future efforts to debug Andrew's interest-list refinements, because it seems to be that the sim is (probably correctly) not sending geometry that isn't quite in-view initially and somehow still excluding them when the view moves to where they are, until they're selected. Unfortunately, I've not found a very solid repro for this.

Share this post


Link to post
Share on other sites

On Magnum after the first roll out yesterday, when I logged back in I had a dozen or so random items from my inventory attached to my avatar,  things like trees and other items.  

I found an other issue but not sure if it's new or not I've been underwater for a few months,  with LIghting and Shadows turned on, Prim Point Light and Light Projectors doesn't work under water, I tried it with firestorm 4.2.2 (29837) and the LL Beta viewer 3.4.1 (266073), all so tested setting it with scripts and setting it manually from the prim.  Tested this on Magnum and the main server channel. I read the Deferred rendering test wiki but I don't see any thing suggesting that light shouldn't work under water

http://wiki.secondlife.com/wiki/Deferred_Rendering_Test

 

 

Firestorm 4.2.2 (29837) Aug 27 2012 19:20:05 (Firestorm-Release)
Release Notes

You are at 204,371.0, 231,573.0, 36.9 in Wyrd Up located at sim9126.agni.lindenlab.com (216.82.42.62:13028)
Second Life RC Magnum 12.10.19.266079
Error fetching server release notes URL.

CPU: Intel® Core i7-2630QM CPU @ 2.00GHz (1995.5 MHz)
Memory: 8170 MB
OS Version: Microsoft Windows 7 64-bit Service Pack 1 (Build 7601)
Graphics Card Vendor: NVIDIA Corporation
Graphics Card: GeForce GTX 560M/PCIe/SSE2

Windows Graphics Driver Version: 9.18.0013.0697
OpenGL Version: 4.2.0

RestrainedLove API: RLV v2.7.0 / RLVa v1.4.7a
libcurl Version: libcurl/7.21.1 OpenSSL/0.9.8q zlib/1.2.5 c-ares/1.7.1
J2C Decoder Version: KDU
Audio Driver Version: FMOD version 3.750000
Qt Webkit Version: 4.7.1 (version number hard-coded)
Voice Server Version: Not Connected
Settings mode: Firestorm
Viewer Skin: firestorm (grey)
Font Used: Deja Vu (96)
Draw distance: 184
Bandwidth: 500
LOD factor: 4
Built with MSVC version 1600
Packets Lost: 0/646 (0.0%)

Share this post


Link to post
Share on other sites

Oskar

After another day's SL I am now pretty sure that the prim rendering issue is significantly worse on LeTigre compared with other Server channels, and it is significantly worse this week than before.

Share this post


Link to post
Share on other sites

Heya  Phaedra,

These are all Viewer issues.

SH-2911  Projectors are not rendered when the viewpoint is underwater (Expected behaviour)

VWR-29323  Deferred turns off all underwater lightsources

(Shiny also doesnt work underwarer in deferred rendering)

 

 

 

Share this post


Link to post
Share on other sites
You are about to reply to a thread that has been inactive for 2816 days.

Please take a moment to consider if this thread is worth bumping.

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Sign in to follow this  

×
×
  • Create New...