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