Server Deployments – Week 40 Recap
As always, please refer to the week’s forum deployment thread for the latest news and updates.
- There was no Main channel deployment in week 40
- The three RC channels all received the same update, comprising a fix for a bug affecting group notice delivery to large groups whereby the notice randomly fails to reach some group members; a new JSON_DELETE option for llJsonSetValue(); interest list preparatory work for more correct sort order during scene load – release notes (BlueSteel).
Upcoming Bug Fixes
There has been a series of bug reports from across the grid being raised about problems with camera updates when operating in Mouselook with scripted objects using llGetCameraRot() (HUDS, weapons, etc), and which may also affect scripted objects using llGetCameraRot() when in 3rd person view. Commenting on the issue at the Server Beta meeting, Maestro Linden had this to say:
There were a few bugs reported today [Thursday October 3rd] about llGetCameraRot() being ‘lazy’ about updates, which we’ve been able to confirm. If you’re aiming in mouselook and make subtle adjustments, the llGetCameraRot() rotation doesn’t change (but should) …
In any case, Andrew took a look at the bug and found the cause; one of the interest list changes affected how often the simulator updates the reported camera rotation value. He had added some hysteresis so that only large changes that would affect your interest list (cone of objects you’re seeing) would cause the value to update, not realizing that it affected llGetCameraRot(). There’s a fix pending, so we should hopefully have that ready for the next rolls.
Group Access to Parcel when “Sell Passes” Set
I reported on this issue in my week 39 updates. Essentially, if a region is set to group access and to “Sell Passes”, Group members ended up unable to enter the parcel at all. The problem was accidentally introduced with the recent parcel access updates, and while not widespread, is still recognised as a pain for those using the option.
Region Crossing Fixes
There are two upcoming fixes for region crossings.
The first is a fix for “‘Ghost’ avatars and vehicles sometimes appear to an observer at the sim border”. This is caused by an avatar or vehicle making a region crossing just at the limit of the observer’s draw distance, so the simulator that the vehicle / avatar was leaving didn’t send an ObjectDelete message, since it figured the destination region would handle future object updates. However, as the observer’s viewer wasn’t connected to to the destination region, no update would be received, leaving the “ghost” image in view (“touching” it would cause it to vanish).
The second is a fix for “Vehicles which exit a region with a passenger are incorrectly autoreturned and ‘ghosted'”. This is related to a vehicle being rezzed in a region with auto return set, and then “loitering” in the area before coincidentally trying to cross the region boundary at the time the auto return delay expired. during the crossing process, the vehicle would appear to be unoccupied to the region it was leaving – and thus be returned to the owner. In addition, the vehicle’s collision body would be “left behind” (marked as “pending delete” without actually being deleted) which could then be run into as a “ghosted” object by other vehicles.
Currently, a region restart fixes this issue.
SL Viewer Updates
There has been no promotion of an RC viewer to the de facto release viewer so far in week 40. The Maintenance viewer (support for new particle capabilities; automatic avatar render limit and feedback system) gained a further update on September 30th, with the arrival of version 18.104.22.1681793.
Mac OSX 10.6 Viewer roll-back
As reported here, due to the recent Cocoa updates causing regression for users on Mac OSX 10.6, the Lab has opted to roll-back all users on that operating system to version 22.214.171.1240048 (August 20th, 2013).
Interest List Viewer
It’s now believed that the Interest List viewer is around two weeks from appearing as either a project viewer or an RC viewer.
Providing a further bulletin on the status of the upcoming SSA updates, and following-on from the Friday TPV Developer meeting, Nyx Linden had the following to say at the Content Creation meeting on Monday September 30th:
We’re testing the inventory changes and will continue to push out further code updates as things progress and we’re able to update the repository & make it reasonably stable. [There’s] nothing ready for the release pipeline yet, so please don’t make formal releases with the new code yet. We’re currently working on cleaning up unused bits of code and fixing bugs we did not have time to fully fix in the first release, so if you are still having problems with anything, please do make sure there is a filed issue for it.
Group Ban List
The group ban list project is being readied for internal testing by LL. Baker hopes to complete this by week 41, at which point the server code will be released to Aditi for further testing, and a viewer update should be made available, together with the code being released for TPVs to merge into their repositories.
Baker’s thinking is that while the group ban list is a significant feature, other than one aspect of refactoring, the code changes to the viewer are relatively small; therefore, it’s likely that the functionality will be rolled into something like a viewer maintenance RC rather than appearing in a viewer on its own.
It is likely that the capability will be put through its paces at the next Server Beta meeting, or possibly in week 42, depending on how the internal testing goes.
Extending the In-world Build Capabilities
The content Creation meeting on Monday September 30th saw a healthy discussion on possible additions to the current in-world build tool capabilities, such a hollowing-out an object through multiple axes (e.g. X and Y), allowing for “blind” holes, allowing a offset on a hollow, etc.
Whether any / all of these would be possible is debatable; some may be limited by the physics engine, others may be deemed as unworkable due to the amount of work required in refactoring prim geometry generation, and so on. However, commenting on the discussion in general, Nyx said:
There are a number of possibilities, I’d encourage anyone with ideas on ways to extend the system to file a JIRA request for each one. The cost of doing any given change is likely to be significant if more data fields need to be added to the protocol, but batching them up would be a more efficient use of the dev resources. That being said, I can’t speak to what the relative priority would be of extending the prim definitions.