SL projects news week 8/1: server, viewer and log-in issue PSA

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
Maestro Linden
Maestro Linden

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
  • The HTTP RC was updated on Wednesday, February 19th to version
  • 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.”

Materials Handling

Scripted Control

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.

A typical Simulator UG meeting (stock)
A typical Simulator UG meeting (stock)

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.

Other Items

Log-in Issues

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.  

llAttachToAvatarTemp() Issue

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.

5 thoughts on “SL projects news week 8/1: server, viewer and log-in issue PSA

  1. Just as a quick note here RE: scripted material changes:
    We ended up dropping that from the initial version largely due to the reasons outlined above. Materials are constructed of a special format that’s intended to be easily extended in the future if new parameters were to be added. The previous system for adding parameters is actually pretty clunky, and isn’t really the most ideal way to have an extensible system that allows SL’s materials system to stay with the times.


    1. To expand here: the current solution uses XML transferred via HTTP. Every face of an object that has a unique material assigned to it will need to request that material via HTTP, and similarly submit materials via HTTP for each change. It does come at a cost to some extent, but the goal here was extensibility as it made more sense to add new rendering features “down the road”.


      1. Regardless of the cause, the issue remains. Lack of LSL control of normal and specular maps limits the usefulness of this capability quite a bit. And really, the requested functionality would greatly enhance the quality of in-world content.


        1. That may be, but the overall point still stands with regards why it wasn’t done from day one: materials as-is cost extra to request and send to a viewer. HTTP requests aren’t cheap enough that each and every viewer connected to a simulator can hammer it with requests for new material parameters every time an object’s material ID changes.

          Scripted objects with materials were talked about early on, but it was determined that it’d be better to get the basic functionality out the door sooner and into content creator’s hands than years later to overcome the technical hurdles that adding scripting to the mix brings. I agree with that decision, largely because constantly changing material parameters, whether transferred over HTTP or not, will thrash the sim pretty hard. That’s a pretty big hurdle to have to overcome, and by throwing something out into the public without taking it into consideration you end up degrading the experience for everyone in the process. This is why scripting was considered a future goal instead of an initial goal. It’s not that anyone thought it was a bad idea, just that the technical challenges were far out of scope for the initial version.


Comments are closed.