The Firestorm team have announced the re-opening of their Second Life release preview group, for those who are interested in assisting the team with identifying potential issues / bugs with new releases of the Firestorm viewer.
The announcement, entitled “Feeling Brave?” from Jessica Lyon, reads in part:
“The perfect understanding of an event after it has happened, often when you realize too late what you could have done to avoid it.” We had one of those moments shortly after our last Firestorm release when we discovered that quite a few users were experiencing a bug that made their screens pink. This bug had slipped past our Quality Assurance team and went out in the official release. The hindsight is that we could have offered a pre-release to a larger number of users than what we have in our beta group. Chances are they would have discovered the bug, we would have fixed it and it would not have been released with that bug.
Jessica Lyon: call to the brave – and those willing to follow the rules!
With this in mind, the Preview group has been re-opened in order to try to ensure potentially obvious bugs don’t slip through the net in future and, as with all Firestorm groups, is on open membership. However, as Jessica notes, there are some rules those joining are asked to abide by:
We need your feedback. Please do not just grab the pre-release and run away. That would defeat the purpose of what we are doing, and we will not do it again. Remain in the group and report issues you’ve found. It’s especially important that you report them to our JIRA. Not familiar with or comfortable using the JIRA? We have a wiki page and a Reporting Bugs class to get you acquainted with it.
Do not give the viewer download link out to anyone outside the group. That kind of thing goes viral very quickly, and if we discover during the pre-release test phase that there are some major bugs or worse — exploits — we will have already lost control of the build. If your friends want to use the viewer, the preview group is open to them, as well. The rules apply to them, too.
Re-read rules #1 and #2.
So, if you have an interest in test-driving viewers, and are willing to abide by the stated rules, the Firestorm Preview group might be a group to consider.
The SL beta and development viewers saw end-of-week updates in week 12, with the beta viewer rolling to release 3.5.0.272486 and the development viewer 3.5.1.272521, both on March 22nd.
The beta update is primarily focused on CHUI, and may be the final beta release for CHUI before the it appears in an official release version of the SL viewer (see below).
On March 20th, the Sunshine project viewer (Server-side Baking) updated to release 3.5.0.272211, which may be the last releases of the SSB code as a project viewer prior to the code arriving in the SL beta viewer – see the SSB section of this report (below).
Communications Hub User Interface (CHUI)
As indicated above, the Lab is hoping that CHUI, the Communications Hub User Interface, is now in its final beta viewer run with the release of 3.5.0.272486, and that the code should be appearing in the release version of the SL viewer, possibly later in week 13 (week commencing Monday 25th March).
CHUI: probably making a final appearance in the SL beta viewer prior to appearing in the release viewer
However, TPVs are still considering how best to tackle CHUI in terms of integration and deployment in their viewers. Part of the problem here is that for some TPVs, the CHUI user interface changes conflict with changes the TPVs have themselves made, and so consideration needs to be given as to which parts of the UI updates and changes a given TPV wishes to adopt. A wider issue, however, is that CHUI also includes a large about of v3 code refactoring, all of which needs to be considered for implementation into views, particularly those which are v3-based.
Further, as most TPVs have been focused on SSB updates, it may take a while before CHUI itself appears either in whole or in part, in some third-party viewers.
The CHUI updates don’t only impact TPVs – there is a knock-on effect with some of the upcoming changes / code contributions flowing into the SL viewer code as well. For example, the viewer side of the request teleport feature (STORM-1838), which I originally commented on in week 4, has been delayed while it is re-worked in light of CHUI-generated changes.
Server-side Baking
Viewer-side SSB Code
Following-on from the recent pile-on / load tests carried out using the official viewer (Thursday March 14th) and Firestorm (Friday March 15th), the Lab believes that the viewer side of the code is doing “quite well” in testing, with both tests recording very similar results, including hitting the same problems related to inventory fetching / rezzing issues for attachments.
As a result of this, the Lab have been looking at releasing the SSB viewer code to the SL beta viewer (with CHUI integration) on or around April 1st (week 14). However, the discovery of a bug with the latest version of the SSB project viewer code ( version 3.5.0.272211), may delay matters.
SUN-57, raised by Tonya Souther, reports a fix for earlier issues (non-public JIRA SH-3941 and SH-3954), now appears to cause avatar bake fail issues when running the viewer-side SSB code on regions using the current avatar baking mechanism. Whirly Fizzle has been able to reproduce the issue when using pre-saved outfits in her My Outfits folder, and describes it thus:
Replace outfit with a ready saved Outfit A from My Outfits folder (Right click -> Replace current outfit). Relog Usually, but not always, I will see part of my baked textures as grey with this certain outfit A. This session my torso texture appears grey to me. My torso fully rezzed without needing to rebake in about a minute.
[Now] Replace outfit with Outfit B, which is a ready saved outfit from My outfits folder (Right click -> Replace current outfit).Outfit B bakes fast & looks correct to myself.
Wait 30 secs or so [and] replace outfit again with outfit A. My avatar will then show the correct head and lower baked layers from outfit A but my upper/torso layer will be that of outfit B.
The SUN-57 issue, as defined by Whirly Fizzle: left – Outfit A from her My Outfits folder replaces whatever she was previously wearing, and appears correct; centre – after a relog, she replaces Outfit A with Outfit B, and again, everything appears correct; right – she replaces Outfit B with Outfit A, but her skin fails to bake correctly, the head and legs showing the skin associated with Outfit A, the torso still showing the skin from Outfit B (shown naked for clarity) – images courtesy of Whirly Fizzle / JIRA SUN-57
Whirly further reports that the issue doesn’t resolve itself after several minutes, and rebaking using CTRL-SHIFT-R has no effect (other than reducing her to a cloud in other people’s view), while using Edit Appearance also fails to clear the problem.
Again, this issue only occurs when using viewers incorporating the latest SSB code, and only on regions which are not themselves running the server SSB code. It is of concern because the viewer code is designed to work with both the current baking mechanism and the upcoming SSB mechanism, and will be expected to do so during the SSB deployment to the main grid, when there will be a period when both the “old” and “new” baking services will for a time be running side-by-side as the latter is gradually rolled-out.
Update March 26th: This article now includes the links to the relevant wiki pages for the new capabilities, as released on March 25th. Also, permissions to animate an avatar are only auto-granted when a prim using the new capabilities is attached to the avatar (PERMISSION_OVERRIDE_ANIMATIONS), otherwise explicit permission required.
Note: article title revised to better reflect contents
At the Beta Server meeting on Thursday 21st March, the Lab informally announced the forthcoming arrival of a server-side Animation Override (AO) system utilising LSL commands.
Coded by Kelly Linden, this new capability is not seen as a replacement to existing AO systems, but rather as a means of making them, in Kelly’s words, “Do a significant portion of their work easier and smoother.”
Overview
The new system utilises a series of new LSL commands, which can be placed in a script located in a prim which has permission to animate your avatar, much like current AOs (granted automatically if the prim is attached to your avatar). However, the advantage with the new calls is that they are keyed directly into the server’s animation states, unlike current AOs, which operate somewhat in conflict with the server’s animations states.
For example, with current AO systems, moving your avatar (i.e. walking) causes an update to be sent to the server, which initially tries to run the default animation required (i.e. the infamous “duck walk”). However, the AO script also detects the state change for your avatar, and then instructs the server to replace the default animation information with the required animation.
With the new system, rather than trying to run the default animation and then have an AO tell it what it should be doing, the server simply replaces the default animation with the required animation, thus vastly simplifying the process.
The new capability is currently available for testing on a number of regions on Aditi (CCMTEST17, CCMTEST22, CCMTEST23, CCMTEST26, and CCMTEST29, all on project channel DRTSIM-201), and it should be deployed to a Release Candidate channel during week 13 (week commencing Monday, March 25th).
Additional Notes
The new calls should be compatible with existing AOs, assuming appropriate priorities are used
Items such as idle animations and swimming animations are handled separately by the viewer, and so are not covered by the new calls
This capability does not require an viewer-side changes at present, although it is likely that a future update will be made to the viewer to allow the Stop Animating Me menu option to reset animation states set using the new calls
Seats and poseballs should continue to use trigger animations
Poseball type objects should use llStopAnimation(llGetAnimationOverride(“Sitting”)) instead of llStopAnimation(“sit”) in order to work smoothly with the new calls.
Animation States
New server-side AO capabilities coming soon
The animation states specifically covered by the new LSL calls comprise:
Standing
Sitting
Ground sit
Standing up
Crouching
Walking
Crouch walking
Striding
Running
Turning right
Turning left
Jumping
Pre-jumping
Taking Off
Hovering
Hovering Up
Hovering Down
Flying
Flying Slow
Falling Down
Landing
Soft Landing
LSL AO Calls
The following LSL calls have been defined for use with the above animations.
Sets the animation that will play for a given AO state, where: string anim_state is the name of the animation state being overridden (e.g. Walking), and string anim is the animation to be used
[New addition, March 26th]. Note that PERMISSION_OVERRIDE_ANIMATIONS Only be auto-granted for attachments, otherwise explicit permission required.
Testing and RC Deployment
As mentioned above, there are a number of test regions available on Aditi where the new AO calls can be tired out by scripters and TPVs, and the new capabilities should be arriving on an RC channel in week 13. Any issues found with the capability should be reported via a JIRA, and, if deemed appropriate, raised at the Simulator User Group meeting on Tuesday, March 26th.
The planned server deployed went ahead as scheduled and as follows:
Second Life Server (Main channel): on Tuesday 19th March, the SLS channel received the server maintenance package which had been re-deployed to Magnum in week 11. As with the Magnum re-deploy, it excludes the fix for VWR-786 while LL go “back to the drawing board” to try to correct issues. However, it does include the following two fixes:
BUG-1612: region Owners and estate managers finding they are unable to teleport back to their region after disabling direct teleports to the region
SVC-8019: region visibility delays following region restarts.
Release Candidate channels: on Wednesday 20th March, the three RC channels received the following updates:
BlueSteel and LeTigre: received the same updates as deployed to the SLS channel on Tuesday March 19th, but otherwise retain the same updates received in week 11 – release notes (BlueSteel)
Magnum: should receive further updates to Andrew Linden’s interest list work, as per the release notes. Specific interest list bug fixes included with this update comprise:
Updates for objects that are out of view are delayed for a maximum of 5 seconds, at which point they will be sent (mitigates BUG-1779)
Fix for “No object updates from vehicles after some region crossings” (BUG-1814) – see below
Fix for “Agent appears in incorrect position to other agents after being moved by a sim teleporter” (BUG-1795).
Interest List Updates
Vehicle Crossings
The Magnum RC channel received a potential fix for the vehicle crossing issues (BUG-1814) which have been experienced by many of late, and which appears to have been a major step in the right direction, going on feedback posted to the deployment thread on the forums.
Essentially, the problem lay in the fact that the recently deployed interest list code has only been updating the viewer with information relating to objects within the camera’s field-of-view. If an object moves out of the field-of-view for more than a few seconds, then updates cease until such time as it re-enters the field-of-view.
Where this becomes a problem when crossing a region in a vehicle, is that when transferring between regions, the camera position is effectively extrapolated first, and any vehicle the avatar is attached to is created “behind” the camera by the simulator just entered. Thus, to the interest list code, the vehicle is “outside” the camera’s field-of-view, and so updates on it are no longer sent to the viewer, and problems result.
The updated interest list code deployed to Magnum ensures updates relating to any object an avatar is sitting on are always maintained (or “subscribed to”, to use the official term) by the interest list code, regardless as to where the vehicle appears to be relative to the camera position. Thus, updates continue either side of a region crossing, allowing control of the vehicle to be maintained.
I took time out to test the code fix, with the aid of Erick Gregan, on Thursday March 21st and we agreed that for aircraft at least, it looked good – neither of us encoutered problems.
Flying a Spitfire XI by Erick Gregan over the four Magnum Sandbox regions, I encountered no issues with sim crossings
Those wishing to test the updated code across region boundaries with aircraft or ground vehicles can do so by visiting the Four Magnum Sandbox regions (accessible to members of the Beta Tester SL group – which is free to join). The update itself will hopefully be deployed to the entire grid in the week 13 deployments.
Object Updates
The lack of updates being received from objects outside of the camera’s field-of-view have resulted in other issues as well, which are also fixed in the Magnum release.
For example, if you are looking at a cube which is changing colour between red and blue every few seconds, and turn your camera so that it is outside your field of view and wait for it to turn blue before camming back, the cube will briefly still appear to be red in your view before suddenly changing to blue. This is due to the fact that when the cube is outside your camera’s field of view, the updates associated with it are no longer sent to your viewer until such time as it re-enters your field of view.
With the updates deployed to Magnum, updates for objects outside your field of view are once again sent to the viewer – but at a very low rate (around one update every 5 seconds). While this uses a little more bandwidth then sending no updates at all, it also means that objects in a state of change behave more predictably when camming away from and back to them (BUG-1779).
Cacheable Objects
The Magnum update also implements the first set of changes to the re-use of cacheable objects held by the viewer in order to speed up rezzing / rendering. These changes take two forms: a change in what can be cached in the viewer, and a change the order in which things are rendered.
Up until now, any object or item containing a script was considered non-cacheable by the viewer, whether or not the object itself has changed at all. So if the object disappears (because you teleport away from the region, for example), then all data relating to that object is discarded by the viewer, and has to be re-obtained from the simulator on re-entering the region, which slows rendering.
On Tuesday March 19th, the Main channel received the server maintenance package which had been re-deployed to Magnum in week 11. As with the Magnum re-deploy, it excludes the fix for VWR-786 while LL go “back to the drawing board” to try to correct issues. However, it does include the following two fixes:
BUG-1612: region Owners and estate managers finding they are unable to teleport back to their region after disabling direct teleports to the region
SVC-8019: region visibility delays following region restarts.
The release notes for the deployment are available on the SL wiki, as usual.
Release Candidate Channels
On Wednesday March 20th, the Release Candidate channels should receive the following updates:
BlueSteel and LeTigre: should receive the same updates as deployed to the SLS channel on Tuesday March 19th, but otherwise retain the same updates received in week 11 – release notes (BlueSteel)
Magnum: should receive further updates to Andrew Linden’s interest list work, as per the release notes. Specific interest list bug fixes included with this update comprise:
Updates for objects that are out of view are delayed for a maximum of 5 seconds, at which point they will be sent (mitigates BUG-1779)
Fix for “No object updates from vehicles after some region crossings” (BUG-1814)
Fix for “Agent appears in incorrect position to other agents after being moved by a sim teleporter” (BUG-1795).
Server-side Baking
As reported in week 11, the second official Server-side Baking pile-on / load test appeared to go well on Thursday March 14th. Speaking at the Content Creator’s User Group meeting, SSB project lead Nyx Linden reported:
Looks like things are going well overall – the back-end services are performing well. There are still some inventory and attachment rezzing issues, but these are believed to not be regressions from current limits.
A few reports of issues, some of which we have fixes for, others we’re investigating, and we’re looking at what it would take to fix up the systems that were falling over … there were a couple of new bug reports we’re investigating.
A further SSB pile-on / load test conducted in Friday 15th March, but exclusively with the Firestorm viewer pre-release with SSB support. Numbers at the Firestorm test were roughly the same as those for the “official” test, and overall, the outcome was the same – much lower reported SSB issues, but similar problems with outfit attachments rezzing from inventory (or rather, failing to), which was common to both parts of the test.
Peoiple gather for the Firestorm SSB pile-on / load test, March 15th
The inventory issues have themselves become more of a focus of investigation outside of SSB itself (attachments aren’t affected by the SSB code changes, which relate directly to the likes of skin, shape and clothing layer changes. While the inventory issues were thought to relate solely to Aditi, Nyx indicated that the problem is likely common to Agni as well. commenting:
We were seeing similar failures in inventory, etc on both the old pipeline and the new pipeline, and in areas that we didn’t change. So if we repeated the test on Agni we think we’d see similar failures. We’re looking at the root causes, but attachment rezzing failures won’t necessarily block our first release … We’re looking at the inventory & attachment issues and where their root causes are.
Expect further updates on the latter issue as they become known.
HTTP Testing
All of the test regions for Monty Linden’s upcoming HTTP updates are now up-and-running on Aditi, and available for public access (allowing for the caps on avatars in the primary test regions). The regions are:
As noted in previous project reports, Monty is keep to have TPVs and scripters test the capabilities in order to gather more comprehensive data on his work.
This summary is published every Monday and is a list of SL viewer / client releases (official and TPV) made during the previous week. When reading it, please note:
It is based on my Viewer Round-up Page, a list of all Second Life viewers and clients that are in popular use (and of which I am aware) and which are recognised as adhering to the TPV Policy
By its nature, this summary will always be in arrears
The Viewer Round-up Page is updated as soon as I’m aware of any releases / changes to viewers & clients, and should be referred to for more up-to-date information as the week progresses
The Viewer Round-up Page also includes comprehensive links to download pages, blog notes, release notes, etc., as well as links to any / all reviews of specific viewers / clients made within this blog.
Updates for the week ending: March 17th, 2013
SL Viewer updates:
Beta viewer rolled to 3.5.0.271843 on March 14th – core update: CHUI
Development viewer rolled to 3.5.1.271846 on March 14th – core update: CHUI integration (wiki page)
Niran’s Viewer updated to 2.1.3 on March 11th – core updates: UI updates; updates to texture handling
The Firestorm team have announced the re-opening of their Second Life release preview group, for those who are interested in assisting the team with identifying potential issues / bugs with new releases of the Firestorm viewer.
Inara Pey: Living in a Modemworld 