Deployments this week are being delayed some 24 hours, which means the main channel deployment will not take place until Wednesday 31st October, and the RX channels on Thursday November 1st. This has led to concerns that the main channel deployment / restarts may impact any Halloween events taking place across the grid on Wednesday 31st. Simon Linden promised to raise the concerns at an internal LL meeting taking place later on the 30th October, however, at the time of writing, the Grid Status page reports that the deployment will go ahead, starting at 05:00 SLT on the 31st.
In the meantime, the deployments for the week remain largely as previously indicated:
- The main channel should receive the code currently on BlueSteel and Magnum. As mentioned above, the code has no externally visible changes but has some system level adjustments – release notes
- LeTigre will receive a further update for the code currently running on it, which will include a number of bug fixes and pathfinding updates – release notes
- On Friday 26th October, Simon Linden indicated to me that Magnum should be receiving the code planned for week 43 (the llSensor() problem has been fixed) which will include Baker Linden’s Group Services code currently on Snack, however, as of the Simulator User Group meeting on the 30th October, the final release notes for Magnum had yet to be published, so the update may still be in a state of flux
- BlueSteel should get the same code as is on LeTigre.
Andrew Linden has fixed a bug wherein some child prims in linkset fail to rez and he has carried out further work on performance issue he reported last time. This turned out to be an issue with the code which caused the simulator to send a full update of everything within view to the viewer each time an avatar within visual range moved. Understandably, on crowded regions, this led to performance issues.
The code is in the process of being revised to ensure it only calls for “terse” updates to be sent to the viewer, which will help ensure more relevant information is sent to viewers when updating, which should reduce the performance hits.
Baker Linden, speaking at the Simulator User Group on Tuesday 29th October, said that the server-side code for this project, which should improve the load times and editing abilities for very large group lists, seems to be working “moderately well” since the deployment to the Snack RC channel last week. However, some bugs have been found, Commenting on these, Baker explained that, “The group name, description, and other things don’t load right now on the Snack RCs.” However, the bugs have been investigated and fixes found, which should be merged into the code ahead of the planned deployments on Thursday November 1st. The fixes have also been tested on Aditi, where they’ve been found to induce a slight lag on group loading.
For the time being, testing this now code continues to require a dedicated SL project viewer (available for Windows, Mac and Linux), until such time as issues with the SL beta viewer code can be fixed and merges with viewer project code resumed / made available to TPV for integration.
Work is still progressing, Nyx Linden confirmed, talking at the content Creation User Group on Monday 28th October. How far down the road the work is, is unclear. The server-side of things will apparently be using the code being developed for the viewer, and it is this which is the focus of attention for the present, as has been the case for some time.In talking to TPV developers on the subject the last time the matter came up, Oz Linden confirmed LL’s plan is still to give TPVs “at least” 2 months (eight weeks) notice prior to anything being rolled out for testing, in order to give TPVs sufficient time to incorporate the code into project viewers of their own and assist with the overall testing.
Also during the Content Creation meeting, a problem with alpha textures as applied to worn skinned meshes was brought up. Theresa Tennyson demonstrated the issue during the meeting, which somewhat resembles the old invisiprim / alpha issue.
Siana Gearz suggested two possible causes for the issue, “[The] first is that rigged mesh transparent surfaces appear to be drawn before prim transparent surfaces. [The] second issue is that the shader apparently writes depth for whole fragment, not just for relatively in transparent pixels.”
Nyx Linden requested a JIRA item be raised for the issue, again highlighting the problem with the recent JIRA changes, in that outside of those with access privileges to the new system, no-one could actually confirm if a JIRA had already been raised.
ETA 31st October: Seems a public JIRA on the matter is available – see MartinRJ’s comments which follow this article. Many thanks, Martin!
With thanks to Theresa Tennyson for the Simulator UG meeting transcript