SL projects update 23 (1): server releases, general notes

Apologies for the slight delay in getting this update out, real life is proving a little time-consuming at the moment.

Server Deployments, Week 23

As usual, the latest updates, feedback and comments can be found on the deployment discussion thread. Anyone encountering a specific bug is asked to file a JIRA.

Second Life Server (Main) Channel

No rolls are planned for the week 23.

Release Candidate Channels (RC)

On Wednesday June 5th, the Release Candidate channel should receive the following:

  • BlueSteel and LeTigre should get a new server maintenance project.  This project addresses a disconnection issue and also fixes a crash mode – see my notes from week 22, and a fix for a crash mode
  • Magnum will remain on the same interest list improvement project as originally deployed to LeTigre in week 21, and to Magnum and BlueSteel in week 22, with some updates. Two of these fix what Andrew Linden describes as “two rare crash modes”. The package should also include the same disconnection issue fix.

A further fix had been planned for the RC channels. This relates to people’s inability to download “large” scripts. This relates to the code path used for script uploads  / downloads having a bug, such that you can write a lengthy LSL script and save (upload) it, but on trying to edit it once more, the text of the script will not display. The issue is thought to be related to bandwidth use, and while a fix has been developed by Andrew Linden, but it failed to make the QA cut for this week’s RC releases.

Viewer News

There have been reports of issues with the materials beta viewer, including:

  • Crashing when logging-in to SL on systems using Intel graphics
  • Issues with transparent alphas showing as white and semi-transparent alphas showing as black, which also appears linked to systems with Intel-based graphics

The Lab is currently working on a fix for the Intel issue, but the alpha issue is apparently providing difficult to consistently reproduce

That the materials beta viewer ( installs into a different folder to previous SL beta viewers (SecondLifeBeta rather than SecondLifeBetaViewer), as reported in my overview of the materials beta release, appears to have been an error on the Lab’s part, and it appears likely the additional releases will revert to the SecondLifeBetaViewer folder until such time as the new viewer release process comes on-stream.

Server-side Baking / Appearance

The Lab continues to investigate SUN-74, although there has been no major progress since my last update. The JIRA itself has been updated as a result of further TPV testing.

In terms of any deployment time frames, the Lab still will not be drawn on dates at the moment (again, understandably, even the likes of SUN-74 and the need to try to push more users into updating to viewers which do support SSB/A). Replying to a question on possible deployment beyond the current close beta regions at the Content Creation UG meeting on monday June 3rd, Nyx Linden would only say, “SSA will be deployed slowly and carefully when its ready, we’re working with third-party devs to make sure the last of the bugs are found and hunted down.”

Interest List Update

Andrew Linden
Andrew Linden – who marked his 11th rezday on June 4th, 2013!

As Andrew has been involved in trying to resolve the “large” script bug described above, he’s not had time to make further progress on the “Meeroo issue”, which can affect other scripted animals, etc., as well, and which he describes as:

If you turn your camera away from a crowd of Meeroos, wait several seconds, then turn back around… the Meeroos will be updated, but not quite in the right order. So sometimes you’ll see a head move to the new position, then a fraction of a second later the rest of the body.  So I have a theoretical fix that doesn’t crash the simulator (anymore).

As noted recently, he has developed a partial fix for this problem was deployed as a part of the current interest list updates, and he now hopes he’ll be able to focus on developing a more complete fix, which will mark the final aspect of server-side interest list work for the moment.

Baker Linden’s Bug Stomping

Baker Linden: getting closer to working on group bans
Baker Linden: getting closer to working on group bans

Baker Linden continues to bug stomping his way towards implementing a group ban function for groups with open enrollment, as per JIRA SVC-8127. As has been reported quite regularly in these pages, he’s been engaged in trying to fix a number of other issues in preparation for this work.

Speaking at the Simulator User Group meeting on Tuesday June 4th, he said, “I have the fix ready for removing leading / trailing spaces from display names, and I’m working on a mute list (blocked list) fix now. It will resolve the issue where muted agents don’t necessarily get removed from the mute list. After that, I’ll start working on the group ban system. I won’t have an estimate for when that’ll be done right now. When it’s ready is all I can say :).”

Other Bits

Group Notice Attachments Failure

I’ve touched on JIRA SVC-7129 (Attachments to group notices malfunction after some time) in the past. It covers the issue of receiving a group notice with an attachment (e.g. a notecard, texture or object). If the notice is ignored for a time (some reports suggest an hour or so on v3-based viewers, while the time might be longer on v1-based viewers), clicking on the attachment link will fail to deliver the attachment to inventory.

At the Simulator User Group meeting on June 4th, Kelly Linden described the issue thus:

I believe what it is, is that at the time the notice info is sent to the viewer we create a ‘simuserop’ on the sim for the inventory transfer that expires after some (maybe too short time). The ‘id’ in this case is a generated transaction ID (that we put in the session_id field of improved_instant_message). If you refresh the view or re-request the notice, it makes a new inventory offer transaction with a new ID.

In other words, when a group notice is sent to the viewer, data for the asset item itself is not actually sent. Instead, the simulator to which the viewer is connected at the time the notice is received creates and stores a transaction ID linking the avatar in receipt of the notice with the physical asset data of the attachment. When the attachment link is clicked, the simulator uses this transaction ID to ensure the required asset data is requested from the asset server and sent to the user’s inventory.

However, in order to prevent this table from growing too large (with data for notice attachments people don’t click on as they’re not interested, etc., etc.), individual transaction IDs can expire after a specified time, or as a result of the table hitting an upper limit. An added complication is that transaction IDs are not propagated between simulators as someone moves between regions, so the notice link can become meaningless, also resulting in nothing being received when it is clicked.

When any of these expiry situations occur, the notice itself must be re-requested from the viewer. This generates a new transaction ID on the simulator the viewer is currently connected to, allowing the asset data to be fetched when the attachment notice is clicked. The most common way to achieve this is to open the relevant group’s floater and open the required notice from the floater’s Notices tab.

Commenting on the problem and a possible resolution at the Simulator User Group meeting, Simon Linden said, “I suspect fixing that involves some scary work around how those items are handled by the server and that’s why it hasn’t been worked on.”

In terms of notice attachment links becoming stale / meaningless as a user moves between regions, Andrew indicated a further potential problem, “the data about the notice would have to follow your avatar around. More data to persist for region crossings in other words … probably not the best solution.” However, Kelly Linden did muse on a possible means of easing this particular issue suggesting, “For group notices it might be a good idea for viewers to have better behaviour for already open notifications on region cross – force a re-request when they are viewed again or something … though it should use as lazy a method as possible. Perhaps marking all pending notifications as ‘stale’ on region change then when viewed re-requesting the notification from the server and updating the session_id [transaction ID] info.”

Given the complications and options involved, it is not clear how the matter will be handled. Summing-up the situation, Andrew Linden said, “Ok, so it sounds like there are some ideas on solving SVC-7129, and we have an internal jira for it. It will just have to get prioritised. The fact that it came up in discussion here puts some weight to its urgency, but I don’t know when exactly we’ll get to it.”

3 thoughts on “SL projects update 23 (1): server releases, general notes

  1. The group notice attachment thing is huge! It really is one of those very basic/comes up daily type of bugs. And it’s not just a question of the initial notice being “ignored” by the user….if “ignored” means that the notice comes in while I’m inworld but I just don’t get to it for awhile.
    If the user was not online at the time the notice was sent and logs in later, this bug happens. In fact, I am of the impression that… when I login and have several group notices in queue waiting for me, if I can open the first attachment, I can open them all. But if I can’t open the first, I can’t open any of them.

    Often I log in with the intent to do some particular activity. Now I’m dealing with group notices and NCs or LMs or Objects are attached that I cannot receive. I don’t have time to go to the group floater/window and get the attachment…as i need to tend to whatever the business it was that I came in to do. Later, I forget to open that group and get that attachment…or there were several and I can’t remember them all (until after I log out, of course!).

    This really is one of those non-sexy issues that doesn’t seem like the end of the world…but causes inconvenience on a regular, daily basis. The kind of thing that should have been fixed eons ago and that makes us think the Lindens are totally out of touch with what it is like to be inworld if they need to have this issue explained to them.

    By itself, it is almost nothing. I’ve been dealing with it since day one. Not giving it much thought other than in the moment of exasperation. I’ve never heard/seen anyone talk about this issue before, so how important can it be, right? Wrong. These are the things that add up. The stuff you can’t even think of when someone asks you to name your problems with SL. But it is these little things that add up to, among other things, people leaving SL.


    1. It’s one of a number of irritating isues, large and small, and as such one that tends to get lost in all the noise. Hence why having it (again) raised at user group meetings is, as Andrew says, a good move and it reminds the Lab that the problem is there and needs to be proded at some more.


      1. If might be easiest to fix by the Viewer displaying a button that opens the Group’s floater. How far you go in getting the Notices panel after that, that would cut out several mouse-clicks and seems likely to put a lower load on the current Server than trying to keep unresolved links alive.


Comments are closed.