As always, please refer to the week’s forum deployment thread for the latest news and updates.
Second Life Server (SLS Main) Channel – Tuesday September 17th
The Main channel received the HTTP updates previously deployed to Magnum in weeks 36 and 37. Overviews of these changes, which will be transparent to users pending viewer-side updates, can be found here and here. These changes introduce new capabilities for mesh fetching operations and should lead improvements in the reliability in viewer / server connectivity when fetching mesh and textures as the viewer-side updates are released.
Release Candidate Channels – Wednesday September 18th
BlueSteel and LeTigre should remain on the same maintenance package as week 37, but additionally should receive two updates to the package:
A fix for a newly discovered crash mode
The HTTP updates deployed to Magnum in weeks 36 and 37 and to the Main channel on Tuesday September 17th.
Magnum should receive a new maintenance package which again includes the BlueSteel / LeTigre updates, and includes a number of crash fixes and an update to parcel access priorities “making it so that avatars who are on the ‘allowed’ list can bypass some of the other access restrictions (payment info on file was listed specifically)”
Commenting on the crash mode fixed on BlueSteel / LeTigre, Andrew Linden said, ” The crash bug I fixed was actually rather rare… a corruption of the terrain data when building packets. Happened maybe… 5 times in three weeks. But we thought maybe it was related to some interest list changes so I looked into it anyway.”
Viewer Updates
Maintenance RC Release
A new RC viewer reached the release channel on Friday September 13th. Second Life RC viewer 3.6.6.280939 includes the following core updates:
Automatic avatar render limit and feedback system
Support for the additional LSL particle parameters.
rendering optimizations
avatar render cost information
simple impostors
graphics pref update
new debug setting “RenderAutoMuteRenderCostLimit” sets render cost cut-off point (default 0 = disabled cutoff check)
The glow effect basically looks the same as the prim glow setting on prims, adding PSYS_PART_START_GLOW and PSYS_PART_END_GLOW, which take a float in the 0.0 to 1.0 range
The particle blending takes 2 parameters, PSYS_PART_BLEND_FUNC_SOURCE and PSYS_PART_BLEND_FUNC_DEST, and each of those takes one of the 8 ‘values’ listed underneath, so there are actually 8*8 = 64 blend options. It exposes OpenGL’s glBlendFunc to LSL, see the glBlendFunc documentation at http://www.opengl.org/sdk/docs/man/xhtml/glBlendFunc.xml
An example of how the now ribbon capabilities might be used in SL, showing the arc of the sword through the air, supplied by Maestro Linden (courtesy of Hollowfear.com)
The new ribbon capability should allow for much better particle effects for things like ropes and chains links between objects (amount other things), using a ” go-from” prim/position (the prim centre), and a “go-to” prim/position (defined by PSYS_SRC_TARGET_KEY), the advantage being there would no longer be any gaps in the particle stream. However, there may be times when the ribbon effect may not be facing your camera (so there may be times when you need to reposition your camera in order to see the effect).
Update, July 31st: further to the note below relating to the BlueSteel RC deployment, it appears the bug fix did not clear QA in time for the deployment to occur. Maestro Linden has updated the deployment thread to read: “BlueSteel’s planned project hit some last minute issues, so the update has been canceled for this week. Instead, BlueSteel will not be rolled this week (it will match the version on the ‘Second Life Server’ channel).“
Server Deployments Week 31 (Week Commencing Monday July 29th)
As always, please refer to the week’s forum deployment thread for news, updates and feedback.
Second Life Server (SLS Main) Channel
On Tuesday July 30th, the SLS Main channel received the server maintenance package previously deployed to BlueSteel in week 30 and LeTigre in week 29. This project includes:
A further fix for the issue of pathfinding characters using CHARACTER_STAY_WITHIN_PARCEL getting stuck if they somehow exited their home parcel
Fixes for objects failing to detect collisions after teleporting (BUG-969) and run time permissions failing to function correctly on attachments (BUG-2931)
New capabilities to the materials system to better handle texture requests.
Release Candidate Channels – Wednesday July 31st
Magnum and LeTigre will remain SSA enabled and both receive the updates deployed to the Main channel.
BlueSteel should receive a new server maintenance project. However, a last-minute bug was found in the code. While this has been fixed by Kelly Linden, it has still to pass LL’s QA at the time of writing. Assuming the package passes QA and is deployed, it will include:
Fixes for some simulator crash modes
A fix for BUG-3291 (“llListen in linked objects is listening at root instead of linked object local position *after re-rezzing the linkset*.”)
A fix for BUG-3307 “(llApplyImpulse called from attachment does not work on avatar if script is reset or started when attached”).
Doyouthinkhesaurus – Baker Linden (far right), in his new avatar look, literally towers over the start of the Simulator UG meeting on Tuesday July 30th.
Server-side Appearance
As noted above and in part 2 of last week’s report, SSA will not be enabled on any additional server channels this week, but does remain enabled on LeTigre and Magnum as the Lab continue to gather statistics and monitor performance, etc. Commenting on the state-of play, Nyx Linden said, “Testing seems to be going well, but we’re being on the cautious side – making sure that the back-end can handle the load. There are a few reported bugs in JIRA, but *most* are minor and we’re working on the not-so-minor ones.”
Issues
I provided an update on some of the more serious issues the Lab has been addressing with SSA in part 2 of my week 30 report (see the link in the paragraph above). Since then I’ve been poked about additional advice the Firestorm team have put together for those experiencing issues, including SUN-98,and I’m providing the relevant information here.
Avatar textures remaining grey / SUN-98: is generally the result of wearing a corrupted clothing asset, and as such is “expected behaviour” in order to avoid cases of accidental nudity, as I explained last week. To help diagnose the problem, the Firestorm team suggest you:
Remove all clothing and allow the avatar to bake with just the skin layer worn. If it fails to bake properly, the skin is the corrupted asset and needs to be replaced
If the skin bakes correctly, start adding the clothing layers of the outfit one at a time and check each to see how it bakes
If an item shows-up fully or partially grey, that is the corrupted asset. Replacing it should allow everything to bake and render correctly.
The Firestorm article also includes some Firestorm-specific actions for problems, and is a work-in-progress, so you can refer to it via the link above for further advice.
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 (3.6.0.275764) 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 – 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.
As noted in part 2 of this report, due to issues with the JSON deployment made to all three Release Candidate channels in week 20, there was no Main channel deployment in week 21.
Maestro Linden likes to keep fit while chairing the Server Beta meeting
On Wednesday May 22nd, the three Release Candidate (RC channels should each receive the following updates:
Magnum received an update to the server maintenance project deployed to all three RC channels in week 20 which includes fixes for bugs within the LSL support to create and parse JSON-formatted strings. Release notes.
BlueSteel received a further update to the experience tools project, and there should be no visible changes with this update. Release notes
LeTigre received an update related to the simulator’s interest list subsystem which reduces scene loading time when entering a new region. Release notes.
As mentioned above, the Magnum updates included a fix for an issue within the LSL JSON capabilities deployed to the three RC channels in week 20. Currently, the fix appears to have resolved the issues, so it is possible the JSON capabilities will reach more of the grid once more in week 22.
“json is a javascript way to describe data and pass data between scripts or services. In that regard one of the biggest benefits of json in LSL is for improving the ability of LSL to interact with 3rd party APIs,” Kelly Linden explained at the Server Beta meeting on Thursday May 23rd after questions were asked as to the purpose of the capabilities. “Because it is simple and relatively ‘complete’ even non-javascript services use it on the internet to exchange data … I’ve been interested in services like parse.com for example which let you store and retrieve data very easily … in json … https://parse.com/docs/rest this is what would work with LSL.”
Kelly also noted the new capability might be used within LSL, but with a small caveat, saying, “If you are only working within LSL there may be some specific cases where it is beneficial, but other string to list functionality will probably be fine.”
The package deployed to Magnum also included a fix for the bug introduced into the RC channels in week 20 which affects control event triggering in attachment’s child prims after changing regions. However, the fix as deployed is described as “interim”, and corrects the problem (which is described in full here) by reverting the fix for SVC-8227 (ApplyImpulse now works only in the root prim). Referring to the situation at the Server Beta meeting on Thursday May 23rd, Maestro Linden said, “we hope to get a ‘real’ fix in for that sometime in the future.”
SL Viewer
Further to part one of this report, Oz Linden has clarified the function of the new “Willing to update to release candidate” option in project / beta viewers. As I’ve previously mentioned, when a viewer is believed to be of release quality, it will be put into a release candidate, which will be released to a chosen number of users (the number determined by Linden Lab). By leaving this new option checked, users are indicating that they are willing to receive any such release candidate updates if they are selected by LL to receive them. Unchecking the option means that a user will not be included in the count for any release candidate update, and so will not receive any updates until such time as the viewer reaches release status.
The new “Willing to Update” option
Even so, leaving the box checked does not mean a user will automatically receive release candidate updates – as noted above, LL will determine the total number of users who will receive any given release candidate updates. These will be chosen at random from those who are using the project / beta viewer, and once this number has been reached, no further users will receive the update regardless as to whether the option is enabled or not. If necessary, the selection process can be additionally targeted at specific operating systems, but the Lab currently don’t have plans to use this capability.
While the new release process is not dependent upon Materials Processing project viewer reaching a beta release status, it still appears unlikely that the new processed will be deployed until after Materials has done so. Once the new release process has been deployed, Oz indicates that it is likely that a number of viewer candidates will appear – such as a bug fix candidate a Snowstorm candidate and possibly others as well, although the exact timing and spacing of the releases is unclear.
Interest List News
Andrew Linden
Also attending the Server Beta meeting, Andrew Linden provided a further update on the interest list updates deployed to LeTigre. These amount to a number of fixes and updates to the code.
“The main thing in that RC is some minor tweaks to help the scene load a little faster on login and teleport. The effects are small, especially in the case where you have a full cache for that region so I’m guessing that no one has really noticed the scene loading any faster.” Andrew explained, “There was [also] one minor bug I fixed for people with really low-bandwidth settings… the updates were not properly getting re-sorted when the camera moved around, so the scene would continue to stream in based on where you were standing when you arrived but most people with >500kbps bandwidth shouldn’t notice that problem — the scene usually loads fast enough now. ”
He went on to reiterate that the LeTigre deployment also includes a partial fix for the “Meeroo update” problem of objects not updating correctly after being outside of the camera’s field-of-view. Again, as mentioned in part 2 of this report, the fix works with affected objects which are up to 10 metres away. However, he believes he now has a more complete fix for the problem, but has yet to test it. He also believes that the issue causing the “Meeroo update” problem may also be responsible for BUG-2644 (pathfinding characters not updating behind the camera) is the same problem as the Meeroo animation, and is hopeful his intended fix will correct that as well.
Finally, the update fixes a minor bug where the green avatar dots on the mini map would not update correctly for avatars behind the camera.
The downside to the LeTigre update is that it did introduce a crash mode, which Andrew described as “rare… only about 6 per day,” and which is currently being investigated.
Server-side Baking / Appearance
As noted in week 20, it has been hoped that the server-side of the SSB/A code would be enabled on two test regions on the Main grid. These regions are Intended specifically for TPVs to carry out functional tests on the viewer code away from the distractions of broader issues which interfered with testing on Aditi. As such, they should not be considered a sign that deployment of the server-side code had commenced. It had been hoped that the two regions would be enabled this week, but at the time of writing, this is not yet the case. This doesn’t necessarily mean the project is delayed, however.
In terms of overall deployment, matters are unlikely to have changed since week 20, and the Lab will still in part be looking at this initial “TPV test” period as an opportunity to gain further additional metrics on the system and to look for anything untoward occurring prior to committing to possible dates.
As always, please refer to the release forum thread on the weekly deployments for the latest updates and discussions.
Due to issues with the JSON deployment made to all three Release Candidate channels in week 20, there has been no Main channel deployment in week 21.
On Wednesday May 22nd, the three Release Candidate (RC channels should each receive the following updates:
Magnum should receive an update to the server maintenance project deployed to all three RC channels in week 20 which includes fixes for bugs within the LSL support to create and parse JSON-formatted strings, which I reported on in my week 20 report. This week’s update fixes some bugs related to the changes. Release notes.
BlueSteel should receive a further update to the experience tools project, and there should be no visible changes with this update. Release notes
LeTigreshould receive an update related to the simulator’s interest list subsystem which reduces scene loading time when entering a new region. Release notes.
Interest List Bits
Andrew Linden (image captured by Opensource Obscure)
As noted in week 18, Andrew Linden has been working on fixing a bug which he specifically mentions in terms of Meeroos, but which can affect other animals as well, which he described 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)
Providing an update at the Simulator User Group meeting on the 21st May,, he said, “I do have a little news about the Meeroo animation bug… I wasn’t able to fix it after all… but I did reduce it or eliminate it for meeroos that are nearby (closer than 10m).” He also noted an issue with the Meeroos’ animations which he believes to be “Mostly by slow scripts, low bandwidth connection, or general lag,” which results in the Meeroos walk animation appearing to be broken. He believes the fix in his new project will enable nearby Meeroos to update correctly when being viewed, and he’ll be revisiting the problem once the initial fix has been deployed, although he’d be interested in hearing back on how well the partial fix works, once the fix has gone out.
Baker Linden: Group Ban List and Other Work
Baker Linden: getting closer to working on group bans
Baker Linden reports that he is making “really great progress” on fixing leading and trailing spaces in display names. He’s currently working on some unit tests and dealing with a couple of minor issues, but he hopes that overall it will be ready for QA later in the week. He did admit that, “I’m unsure how useful it’ll be — anyone that wants to game the system will just append a bunch of other characters that appear before letters… But at least whitespace will be stripped.”
Once this has happened, he’ll be finishing-off the fixes for name searches using the People floater and the correct removal (unmuting) of muted avatars and objects from the viewer’s mute list. As soon as these two issues have been dealt with, Baker will be pushing forward with the new group ban list capability as requested in JIRA SVC-8127.
As noted in week 18, Andrew Linden has been working on fixing a bug related to Meeroos (but which I’ve seen affecting other animals as well).
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)
Reporting on the situation at the Simulator User Group meeting on Tuesday May 7th, he said, “Right before this meeting I was rounding up some meeroos to do some testing on the beta grid. The bug is theoretically fixed, but I’ve yet to actually see it work. We’ll be testing this week.” If all goes well, the fix may well be progressing towards an RC release in the near future.
“Missing Prims”
Still no major news on this issue in terms of a lasting fix becoming available. Commenting on it again during the Simulator User Group Meeting, Andrew Linden said:
We were having trouble reproducing it on one of our more recent viewers; the viewer that will eventually go along with the recent interest list fixes, is currently stalled for a mysterious crash bug.
We think the “right click to make the object show up” bug is related to loading of object cache in the viewer and that loading code has had an overhaul in this recent viewer project. So we think the bug is fixed there, but we have yet to test it a lot. Because there is a crash bug we’re still trying to track down.
“Missing” prims – viewer-side fix stalled; code might be made available to TPVs anyway?
The question was asked if the code could be made available to TPVs as it is, even if prone to crashing. Doing so might provide extra eyes on the problem which may both help to resolve the issue and fix the crash issue. Andrew replied to the question by saying, “Oz asked us to put that code out on a public repo, but that was before we realized we had a crash problem.” However, he agreed to take the request back to the office and see what the reaction might be.
Other Bits – Griefing Issues
There has been a long-standing issue with objects sitting on the region borders being very hard to return to their owners, and which has become something of an exploit where mainland griefing is concerned. It had been hoped that the fix for the issue would be deployed to the grid this week, However, in reviewing matters, Andrew linden regretfully reported that “It appears that ‘return of objects at region border’ bug fix is not deployed at the moment, as far as I can tell.” There is currently no date as to when this will be deployed,
Similarly, there is still no news as to when the particle muting capability (right-click on a particle to stop your viewer generating the particle stream in your world-view) might make a viewer-side appearance.
There are reports of a new form of particularly malicious griefing involving spinning / flashing objects which appear deliberately designed to trigger epilepsy or migraine. At the Simulator UG meeting, Simon Linden indicated that the Lab is at least aware of this form of attack.
Blocking Banned Users’ Objects from Rendering
A suggestion has been put forward at several Simulator UG meetings where griefing has been discussed that all objects on a parcel belonging to a user banned from that parcel for griefing should no longer be rendered for other users within that parcel.
This is seen as a particularly useful option at events, etc., where time would otherwise be taken up in trying to locate and return objects which may have been left behind when banning the user, and / or in telling other people in the parcel how to mute offending objects from their view.
Commenting on this as a possible server-side capability, Andrew Linden said, “More fidelity of visibility on a per-parcel level would further complicate things that are already fairly complicated. I’m not saying it can’t be done, but it would be tricky and I would worry about lag issues… server lag as it picks up more work.”
However, after a discussion on the viability of viewer-side blocking and server-side blocking, he commented, “I’m hip… if visibility of banned owners’ objects were to be done… it would probably be easiest to do it at the server.” Even so, there would still be a range of issues to deal with, were such a capability to be put into place. As it stands, it appears to be more a case of food-for-thought than a definite step to be taken.
Forced Object Return
Another griefing attack is one which sees an object deposited in a region but which doesn’t actually trigger until after the region is restarted. This means it gets included in the region back-up – and any subsequent region restart, leaving it free to annoy.
A suggestion was put forward at the Server Beta meeting on Thursday May, 2nd to force a return of all objects in a region which are not set to the required Group as a part of the region restart process. This idea gained some support at the meeting and might have resulted in a feature request being filed. However, it is not without issues of its own – such as with regions where Group object rezzing isn’t a requirement, where it could result in a lot of items which might otherwise have been “safe” returned to their owners.
Inara Pey: Living in a Modemworld 