Server Deployments Week 4
The RC channel deployments went ahead as planned on Wednesday 23rd January. BlueSteel and LeTigre Received the Threaded Region Crossing Code, and Magnum the Interest List code.
The week 3 maint-server release had been the only contender for the Main channel on Tuesday 22nd January, but was not deployed due to the issue of places not indexing correctly in search. A fix was available for this issue, but was rolled to Magnum as a part of that deployment.
There have been widespread issues in regions on the Magnum channel since the deployment, some of which have been reported in the deployment discussion thread on the forum, others of which have been reported in groups such as the Firestorm Support group. These issues may be related to a high bandwidth issue leading to packet loss for people on slower connections. Symptoms include:
- High packet loss / ping to the simulator
- Avatars initially unable to move on arriving in a region
- Avatars apparently unable to move on arrival, but then suddenly “warping” to new position if movement keys have been pressed
- Avatars already in the region being visible to a newly arrived avatar, then vanishing the first time the avatar moves or rotates camera
- Objects failing to rez or to rez correctly (including attachments on avatars)
- Other issues as reported in the forum discussion thread, including notable issues being encountered with JVA bots.
At this time, the issues remain under investigation by the Lab.
Deployments for Week 5
There is currently no clear news on deployment plans for the week commencing Monday 28th January. However, if there is a Main Channel release, Maestro Linden is of the opinion that it will likely be the threaded region crossing code.
The maint-server release originally on Magnum in week 3 will be re-deployed on an RC (which one is TBA at this point), which includes a number of additional fixes, including the fix for the search indexing issue.
There has been little direct news on the materials processing project from those working on it. However, at the Server Beta User Group meeting on the 24th January, Maestro Linden reiterated that the server-side code is very close to a Release Channel deployment and, “May even get a slot next week [week 5].”
Maestro also gave some information on new options for what the alpha channel means during rendering, with four settings available:
- None – the alpha channel is ignored, rendering the face opaque, or
- Alpha blending – essentially the same as we currently have for any alpha texture, or
- A 1-bit alpha mask with each pixel either 100% transparent or 100% opaque, with a cutoff setting to determine where the threshold is (alpha masks should render faster than alpha blending, and eliminate issues with alpha layer sorting), or
- Emissive mask – so the alpha layer is interpreted as a per-pixel glow setting.
(Note that these options appear to suggest a surface cannot have both an alpha mask (or alpha blending) and an emissive mask; however, as Maestro Linden pointed out, there will still be options in the build floater to set glow or face transparency.)
Maestro additionally indicated that the remaining “mesh sandbox” regions on Aditi (DRTSIM-169 channel: Mesh Sandbox 3, Mesh Sandbox 6, Mesh Sandbox 22) have been updated with the server-side materials processing code, so that builders can test the new capabilities once a materials processing viewer is available.
Even though the server-side code is available on selected Aditi regions and may be deployed to a Release Channel in week 5, it will not be usable until such time as a materials processing project viewer is made available. Currently, this is unlikely to be for another few weeks, as there is further work to be completed on the viewer itself, including UI updates (such as the new build floater), code for fetching the additional materials data and for rendering it.
Server Object Rezzing Code
As I outlined back in week 1, Baker Linden is working on improving how objects with large file sizes (as opposed to them being physically large when rezzed in-world) are handled by the simulator software when being rezzed.
In the first part of this update, I reported that Baker hoped the code would be progressing through LL’s QA for deployment to an RC channel in the next few weeks. In the meantime, the code is now available on the DRTSIM-194 channel (e.g. CCMTEST26).
The key point about this work is that it is specifically aimed at preventing the simulator processes from choking and a region stalling when there are a number of large object files being read / parsed, not at actually “speeding up” the physical rezzing process. As such, it is unlikely that objects will appear any faster in people’s in-world view as a result of this work. However, what it does mean is that the simulator code will be better able to handle rezzing multiple “large file” objects without the attendant region lagging which can occur as a result of the simulator being unable to process messages from viewers and other simulators, etc.
Issues continue with Aditi, both in terms of people being able to log-in, and with inventory syncing problems. It is currently unclear as to what the status is regarding potential solutions which have been mentioned in the past – culling “stale” accounts from Aditi and obtaining additional hardware to handle the load. In the meantime, problems continue for some, and the advice remains to keep trying a password change and waiting 24-48 hours for it to fully propagate before attempting to log-in to Aditi once more.
Note that all SLurls given in this report are for the Aditi (Beta) grid.