My apologies for the late release of this update; things have been a little bit hectic, and I’ve been rushing to catch-up on posts and news.
Server Deployments: week 8 – recap
As always, please refer to the server deployment thread in the forums for the latest updates / changes.
- As there was no update to the RC channels in week 7, there was no update to the Main channel on Tuesday February 18th.
- On Wednesday February 19th, all three RCs received a new server maintenance package which comprised the following updates:
- Fix for BUG-5034 “If an EM restarts a region and then teleports out immediately, the EM will disconnect just after teleport”
- Fixed a rare case in which e-mails read by LSL scripts immediately after rez or region change would sometimes be missing the message body
- Fixed some crash modes
The region restart issue (BUG-5034) was described in part 2 of my week 7 report.
Commenting on the e-mail issue during the Server Beta Meeting on Thursday February 20th, Maestro Linden said:
The other bug fix was for some obscure e-mail issue that Kelly found, where e-mails to LSL scripts would be missing their message bodies under very obscure circumstances. Nobody’s filed a bug report about that happening, so maybe nobody ever saw it regularly.
In this case you’d see the e-mail, and see the subject but not the body. Or rather, I guess the body would be an empty string … I guess you’d only know if you had sent the e-mail yourself.
According to Kelly, it would only happen during a very narrow time window as the sim was starting up, so I could imagine most people who saw it once just shrugging after the issue didn’t occur a second time.
SL Viewer Updates
- The Maintenance release RC was updated on Tuesday February 18th to version 188.8.131.526708
- The HTTP RC was updated on Wednesday, February 19th to version 184.108.40.2066707
- The Google Breakpad RC has been removed from the release channel, having completed this round of tests.
Group Ban Lists
There’s not much more to report here than last week. Commenting on the overall status of the work at the Simulator User Group meeting on Tuesday February 18th, Baker Linden said:
I’m in the last stages of code cleanup and ensuring there aren’t any major bugs (which QA will surely find) and I’m wrapping everything up for deployment to Aditi this week (server-side stuff only right now).
It’s not clear if the server code did reach Aditi, or whether it may appear in week 9. Commenting on the status at the Server Beta meeting later in the week, Maestro Linden indicated the code was “inching closer to Aditi”, and will be available “as soon as we’re confident that the backend host and simulators are playing nicely. If there’s a bug which is definitely viewer-only, that’s not a blocker for Aditi at all.”
The ability to control materials (normal and specular maps) via scripts has been an oft-discussed topic in User Group meetings and the subject of MATBUG-359. The subject was again raised at the Simulator User Group Meeting on Tuesday February 18th, to which Simon replied, “I’ve been looking into that, and hope to get to it soon, but it keeps getting pushed back with other more immediate issues cropping up.”
One of the concerns with scripted control of materials maps in that if manual changes are made to materials too quickly in the build floater, they will often revert, as if the server is unhappy in receiving too many quick updates. Commenting on this, Simon added:
That’s an interesting point and something we’ll have to look at after doing the basic scripting change. If it’s somehow worse than the current scripted texture changes, we’ll have to have some sort of throttle to slow it down.
The question was raised on why normal and specular maps appear to work different to diffuse (texture maps), with the server better able to handle fast changes to textures when compared to normal and specular maps. Simon indicated that both normal and specular maps are handled differently in order to minimise the impact of multiple usage. Expanding on this is terms of scripted control, he went on:
I was just looking at the materials code, and the complication this has compared to regular textures is how materials have their own layer of special data packaging instead of a just a UUID on a face. I’m not sure yet how script access is going to thrash that data or not.
There also may be something of a cost / benefit issue within the Lab when it comes to adding scripted control to materials – would the potential uses be broad enough to justify the time required to avoid issues of data thrashing, introducing throttles on updates, etc. Hence Simon asked for some specific examples of where scripted control of materials would be beneficial, so he could carry them back to the Lab’s product managers.
Negative Offsets for Materials
Another problem with materials is that negative values for offsets and rotations would revert to positive values on closing the build floater (MATBUG-268). An interim “fix” for this was to clamp materials offsets / rotations to positive values, which was hardly ideal. However, a more flexible fix is in the pipeline whereby if the diffuse texture has negative offsets / rotations, the viewer calculates the matching positive offsets / rotations and applies them to the materials maps.
During the Server Beta meeting, Maestro Linden raised what he called a “public service announcement” about a log-in issue which is impacting some users:
Recently we discovered an issue related to logins. Certain users who belong to groups or have display names set to certain strings will always fail to log-in. The error message is of the ‘cannot connect to a region’ sort. [BUG-5130 – see details here if you don’t have JIRA access (click to zoom).]
We discovered the cause today; if you belong to a group with a name that looks like a 64 bit integer [e.g. just a numeric value for the name, > 2 billion], you will have this issue, ditto if your display name follows that format.
Where this is the case with a group name, the group tag doesn’t even have to be active in order for the login attempt to fail. Maestro continued:
This is fortunately very rare, but if you have a friend who’s affected, please advise them to contact support for a workaround [and] who can either change their display name (for one guy, I just added a space to get around it), or mess with the ‘problem’ group.
There will be a fix, now that we’ve identified the problem, but I don’t have an ETA yet.
The Server Beta Meeting saw a spirited discussion on the issue of llAttachToAvatarTemp(). Currently, objects attaching with llAttachToAvatarTemp() have their active group set to ‘none’ upon attach, which is seen as a bug and problematic. Two differing opinions have been put forward within the JIRA as to how this might be resolved:
- SCR-395 – which suggests the active group should change to the active group of the avatar to which it is being attached – an option seen as “reasonable” by the Lab
- BUG-5183 – which suggests that the active group should not change, even if the wearer is not a group member. The Lab sees this as being more useful for game / combat environments, as it allows visitors to wear objects (e.g. guns) which can then rez objects (e.g. bullets) on group-build-only land, even though the visitors can’t otherwise rez on the parcels, although the question has been raised on whether this might lead to problems.
A third suggested option was to extend the still-to-be-released Experience Tools to handle situations where the latter is required, through the use of a new property, such that objects or scripts are whitelisted by setting them to the same experience as the region. However, this is something of a potentially longer-term solution.
In terms of the two offered solutions, the Lab is both concerned with potential exploits and the risk of content breakage. Options were discussed and ideas suggested during the meeting (which will be recorded in the meeting transcript), but anyone with views on this topic may want to attend the next Server Beta Meeting, where it is likely to be discussed again.