Server Deploys for Week 24
As always, please refer to the week’s forum deployment thread for news, updates and feedback.
Second Life Server (Main) Channel
On Tuesday June 11th, the SLS channel received getting the server maintenance project that was on BlueSteel and LeTigre in week 23, and which is intended to fix a simulator crash mode, and a disconnection issue whereby multiple avatars would be disconnected from a simulator simultaneously, giving the impression the region had crashed when it had in fact not done so, and which also impacted LSL HTTP-in URLs.
Based on data since the deployment, it appears the disconnection issue has been addressed, although there was a report that problems of LSL HTTP-in URLs being dropped, Commenting on this issues at the Server Beta meeting on Thursday 13th June, Maestro Linden said, “I managed to confirm that it was a separate problem [to the avatar disconnection problem] Kelly has looked into it, and we think we’ll have a fix for that soon.”
Kelly Linden added, “I’ve been working on some http-in bugs for the last couple of days. I have some fixes but I can’t guarantee they will be 100% effective. There is more Rube Goldberg in that system than I’d like.”
Magnum Release Candidate Channel
On Wednesday June 12th Magnum received an update to the current interest list changes running on that channel, which addresses two bugs introduced by the project. The bug fixes were for the problem of the text of large scripts failing to display in the script editor for people on lower bandwidth connections, and a fix for the simulator spamming the viewer with AvatarAppearance messages when avatars were in view and were moving around, also resulting in bandwidth issues.
There have also been reports of an “invisible avatar” problem occurring on Magnum regions since the week 22 deployments. which take the form of avatars in the local vicinity de-rezzing following an in-region teleport, and will only re-appear following a relog. The issue was reported as still be present in week 23, and again following this week’s deployment. So far, the Lab has been unable to reproduce in-house, so investigations are proving difficult. As BlueSteel and LeTigre are now also on the same release (see below) the Lab will be watching to see if there are additional reports of this issue.
BlueSteel and LeTigre Release Candidate Channels
On Wednesday June 12th BlueSteel and LeTigre initially received a new server maintenance project to fix a number of crash modes, addresses an issue with neighbouring region visibility, and which added new adds new LSL pathfinding capabilities and object return capabilities.
However, soon after deployment, an issue was found on BlueSteel / LeTigre regions – Bug 2850 (Cannot rez objects in Bluesteel and LeTigre parcels which disallow object entry), which resulted in a rollback which saw BlueSteel and LeTigre updated with the Magnum release package.
“it turned out that if a parcel allowed build but disallowed object entry for your avatar, then your avatar would not be able to rez from agent inventory into the parcel,” Maestro explained at the Server Beta meeting on Thursday June 13th, “And your scripted objects (like the pop-gun) would also be unable to rez. Also, Lucia [Nightfire] reported a tangential issue, which was that rezzing in some group-owned parcels required your avatar to have the parcel’s group active, which is not usually a requirement. These bugs were bad enough that … we rolled BS and LT to the same version as Magnum.”
Fixes are underway for this issue, but it is currently not known if they will be ready for next week’s deployments.
Object Return Capabilities Update
Prior to the rollback on BlueSteel and LeTigre, an issue was noted with the llReturnObjectsByID function, resulting in the function being disabled server-side. “It should be (probably) re-enabled with the next release of that code,” Kelly Linden noted. “However it will have a new limitation – it will no longer be able to return objects owned by the parcel owner.”
“We were concerned about a potential griefing vector if a parcel owner absent-mindedly grants the permission,” Maestro added.
I’ve updated my overview of the new capabilities to reflect this change.
llSetLinkTextureAnim and Synchronised Animations
Jenna Felton asked the following at the Server Beta meeting on Thursday 13th June (wording cleaned-up a little):
A question about llSetLinkTextureAnim function. The function is able to start texture animation on multiple prims at same moment. Does the animation on different prims run synchronously, i.e. is it ensured, that when the animation uses frames, the corresponding frames (i.e. with same v,h numbers) are shown on the prim faces in request, or the animations can get out of sync on the involved prims and faces?
I guessed it will get out of sync because after a teleport to a place with linkset, the prims are loaded and shown at different moment. But in a test, the linkset was animated synchronously. Was this by chance, or is there a mechanism built into this function ensuring the animations are played in sync? [If] there is no such mechanism, I’d like to suggest a function that ensures this, [as it] might allow special installations for clubs or interesting environments without needs of enforced synchronisation by script.
Andrew Linden replied:
The texture animation is executed viewer-side. It probably starts as soon as the viewer gets an update for the animation info. So if the updates for all the prims arrive at the exact same frame, and the viewer processes them all within that frame, then I would expect the animations to run in lock-step. Dunno about the limitations of the viewer, but the server might not send all object updates within its same frame, and even then there is no guarantee that the viewer will receive them all with one of its own frames.
The feature would have to be a way to have all texture animations start at some specific time in the future. All the updates that describe the pending animation trigger would have to get to the viewer before the expiry.
Jonathan Yap suggested they could all register as a unit and once loaded the viewer would know to start them all at the same time, to which Andrew replied, “That would probably be easier… specify an animation channel per face, so that all faces on that channel run in lock-step. It is an interesting idea… but I wouldn’t put it on my short list of things to get done, unfortunately. I’ve got some stuff lined up that I would want to get done first. So we’ll have to kick that idea down the road and raise it again later.”
In the meantime, a feature request is being raised on the idea.
Bug Tracker and Feature Requests
The update of the JIRA system in 2012 saw the loss of the Feature Request category from the report form. This has left people confused as to how to file a feature request, particularly as many appear to get closed as “not applicable”, or “not a bug”, which tends to give the impression the request is simply being dismissed with no further action being taken – thus disheartening users from filing requests.
Maestro Linden commented, “The only real interface for [filing feature requests] is in the BUG project. We tend to not triage those beyond labeling them as feature requests and resolving as “Not a bug”, though. Once the issues are in this state, somebody from product can easily locate the feature requests.”
When asked if a feature request category could be added to the system, or if the labels used to “close” feature requests could be updated to something more meaningful, Maestro, replied, “Well, none of us here are in charge of the Jira flows, but I can pass those sentiments on.”
Similar concerns have been raised in other user group meetings as well – such as the open-source dev meeting – but it is unclear whether such concerns / feedback is causing any reconsideration within the Lab as to how the current JIRA is being presented to users.