Server Deployments – Week 39
As always, please refer to the week’s forum deployment thread for the latest news and updates.
Second Life Server (Main Channel) – Tuesday September 24th
The main channel updated to the server project that was on Magnum last week, comprising:
- A fix for the llXorbase64 issue reported on in my week 35 (2) update (BUG-3763)
- A fix for an issue where an avatar sitting at high altitude may appear to be located at 0,0 on both the world map and mini map (BUG-3332)
- A fix for “llReturnObjectsByID breaks on string uuids”
- Fixes for a number of JSON function issues:
- Nerfing of recursive rezzing. Again, this was outlined in my week 35 (1) report. Under the new code, the copy of the original object will inherit the temp-on-rez and parcel time of the originating object and so be returned at the same time
- Users who are on a parcel’s “Allowed Access” list now correctly bypass other parcel restrictions (such as “Payment Info On File”) when entering the parcel
- Crash mode fixes.
Second Life RC BlueSteel, RC Magnum, and RC LeTigre – Wednesday September 25th
Region Restart Issues
The last few weeks have apparently seen an increase in the number of reports being filed against regions restarting in an unhealthy state following a restart. Talking at the Simulator User Group on Tuesday September 24th, Whirly Fizzle related the problems thus:
After rolling restarts, many regions come back in an unhealthy state in that no mesh will rez on them, you appear offline to all your friends if you are on said region, your friends lists & groups lists don’t load, you cannot initiate IM sessions & you usually disconnect when attempting to TP out of those regions. (Caps fail I guess?). Restarting the region fixes it. As far as I know this used to happen rarely after rolls but now it appears pretty common.
Both Simon and Andrew Linden leaned towards the problems being indicative of a caps fail issue, with Simon speculating, “I suspect the caps system is overloaded in a server restart … there may be too many regions coming up at once, doing all the housework to get into the grid, etc, and it falls apart. That’s just a wild guess, however.” He also pointed to the problem possibly being connectivity-related.
As a result, Andrew has said he’ll look deeper into the problem and also check with LL’s Release team, who actually handle the rollouts to see if they have any insight into what may be happening, and if it is a broken caps issue. In the meantime, those experiencing issues of the kind indicated by Whirly should file a bug report, making sure they include the server names (e.g. simXXXX.agni.lindenlab.com available in Help > About Second Life) both before and after running a manual restart.
SL Viewer Updates
There has been no release candidate promotion to the de facto release viewer as yet in week 39. However, the remaining two release candidates updated recently as follows:
- The Maintenance release RC (support for new particle capabilities; automatic avatar render limit and feedback system) updated on September 20th to version 184.108.40.2061236, and then on September 24th to version 220.127.116.111385
- The Snowstorm contributions RC (request teleport feature) updated on September 20th to version 18.104.22.1681199.
More on “Avatar 2.0”
The subject of improving the avatar base was again raised at the Content Creation meeting on Monday September 23rd, with a series of suggestions being made as to how the introduction of such an avatar might be handled, comprising:
- Pushing STORM-1800 to a project viewer
- LL to start work on “Avatar 2.0”
- Make the new avatar base available alongside the current avatar base, with explanation so to the differences and leaving it to content creators to specify which clothing / attachments fit which avatar form
- Configure the system so that content creators and users will be able to use custom avatar bases
- Develop a mesh deformer that works with “all possible” avatar bases.
While this may sound like a reasonable list, it covers a huge amount of ground – and a large number of issues, technical and otherwise. Perhaps the biggest of the latter is that even among content creators, there is frequently disagreement on how a new avatar base should be defined, what it should support / be capable of, etc.
So even were LL to push ahead with developing an additional avatar form, they’d likely run into a storm of equal measure whether or not they consulted with content creators and designers beforehand. No consultation would leave them facing potential anger and upset from all sides, while consultation would likely leads to a huge number of feature / capability requests, some of which could well be mutually exclusive (and thus subject to further disagreements).
As mentioned the last time I reported on this, there are other generic issues to be considered as well, again without even touching on the deeper complexities of such a project. Concerns were again raised over the level of communications required for people to understand the differences between “avatar 1.0” and “avatar 2.0” – and not just by the Lab, some of those attending the meeting pointed to these concerns.
The concern here is that communications don’t just need to be made at the point of sale as to which items of clothing / attachments work with which avatar form; they need to be made much more broadly for people to understand why an item purchased for the one will not work with the other. The problem being that even with such attempts at notification, many people will see, like, buy, without considering broader implications.
While Nyx did not out-and-out rule out any work on “Avatar 2.0” – as he said, “Our next priorities are not public nor are they set in stone, so I can’t speak to what the priority would be on an avatar 2.0 project,” it is clear that given the breadth and depth of both the technical and non-technical issues facing such a project, it is unlikely to be near the top of the Lab’s list of priorities. Which is not to say that possible improvements to the current avatar form are similarly out-of-the question.
Another topic of recent discussion has been that of texture downloads – specifically, how they are handled where some sort of “preloading” of textures are required for something like a vendor display, or a slide show, such that the next image to be displayed is loaded on a non-visible face of an object (or possibly a face of an object which is coloured black, so the image texture is effectively “hidden”, or one that is 100% transparent), prior to being “properly” displayed.
Replying to a question on this at the Content Creation meeting, Nyx Linden said:
Short answer is if the face is rendered, we will compute how much of the screen it takes up, and download the texture to the appropriate detail level. I believe we download textures that are facing away from you, as the culling of back-facing geometry is done later in the pipeline. If a face is 100% transparent…I’d honestly have to look up at what point we stop drawing that to know if its textures are downloaded.
He went on to say that on a broader level, knowing how much of, and at what stage, a texture will get loaded/utilised in the viewer is complicated by a number of factors: what gets sent over the network; what is stored in your viewer’s cache between sessions; what gets decoded and to what level, and what decoded texture data actually gets transferred/stays in GPU memory.
Generally speaking, textures within the avatar’s field of view are downloaded, regardless as to whether or not the object face on which they appear is visible. However, those that are not immediately visible may only initially be downloaded at a low resolution prior to being “properly” displayed when they come into view.
This discussion also touched upon texture sizing, with Nyx reminding people that any clothing layers, etc., at 1024 resolution are automatically downsampled, as avatar bakes are (and always have been) automatically capped at 512.
Maestro Unveils his Disco Meeting Venue
Purely as an item of trivia, and a foretaste of the Server Beta meeting due on Thursday September 26th, Maestro Linden has completed his promised overhaul of the Server Beta meeting area, and his new disco format is ready to go.
There are a number of disco poseballs within the set, flares, medallions, bling and 70’s looks entirely optional (I hope!). Attendees are invited to bring their own preferred dances and / or chairs to sit on.