New Version Released With New Features

Finally got a new version out! This was planned a lot sooner, but things got quite busy here, and the new feature required rather more coding than expected.

The new feature is that now there’s a checkbox in the chat history to enable logging of the owners of talking objects, as well as the location if available. This helps track down objects that spam or that are cleverly hidden somewhere they’re hard to find. It will also tell you the owner and the location of an object IMing you, so even if there’s an object on some entirely different part of the grid, you’ll be able to know who owns it, and where it is.

Silencing the Voice of God

Yesterday I had a lot of fun tracking down a spammer.

Sesh Kamachi IMed the Linux group asking how to find a location of an object that keep spamming messages. I gave him a tool I made for the purpose, which shows the last speaker’s name, owner (if it’s an object) and location. Sesh reported that this didn’t work, so I came there to check it out myself.

Viewer 1.18.1.2.127 released

For the people who wanted voice support, here it is!

However, as I’ve not yet determined whether I can distribute the Vivox components or not, I’ve marked them non-redistributable as a precaution. So to get that working you will have to install the standard 1.18.1.2 viewer first, then mine. I’ll change that if I determine that Vivox files can be safely included.

Update: Confirmed that voice components are unfortunately not redistributable. That means that an install of the standard 1.18.1.2 viewer will be needed, so that my installer can grab the files from it.

On non-redistributable components

The viewer’s source is released under the GPL2, however, some components use other licenses.

Most parts of the viewer can be redistributed by people making their own viewers. One exception is Kakadu, the JPEG 2000 library. This is the component that decodes textures. Its license prevents distribution by anybody but Linden Lab. Fortunately, there’s an alternative, called OpenJPEG.

The reason SL doesn’t use it by default is that it’s still not as good as Kakadu. Initially, OpenJPEG was very, very slow. It worked as a proof of concept, but it was unusable in practice. Every texture decoding made the viewer freeze, and it could take half an hour until things loaded. Fortunately, some of the other people working on the viewer contributed patches, and now performance is more than acceptable.

A few problems remain, however: OpenJPEG still has bugs Kakadu doesn’t, for example the problem with the world map is an OpenJPEG bug. It also crashes when uploading small images and has other uploading problems.

These bugs may manifest themselves in my viewer if you didn’t have the right original version of SL installed when you installed mine. This is because since Kakadu is not redistributable, my installer takes it from an existing install, if it can be found. If not, the viewer falls back to OpenJPEG. You’ll get a message about this during installation if the installer can’t find the file. To fix that is easy: Install the original SL version my viewer is based on (1.18.0.6 for example), then reinstall my viewer. FirstLook, beta, etc versions most likely won’t work, as the installer looks for a specific version of the file.

Currently I can’t fix those problems. Besides not being a problem with the viewer itself, I don’t know enough about image compression to figure out the problem. I could try to learn, but I think my time is better spent on my current work, especially since there are people who know about OpenJPEG a lot more than I do. If you want to help, vote for those bugs. Login with your SL username and password into Jira, then click “vote for it” on the left sidebar. This will help bring it to the LL’s attention.

[Done] Server’s RAID resyncing, please excuse the bad performance

My old UPS had a really worn out battery and was due to replacement. I got a new one weeks ago, but I was counting on replacing it during SL downtime. Only power happened to go out before SL went down for maintenance. So I plugged in the new UPS and all is good now.

Well, almost. Due to the unexpected powerdown, the RAID is resyncing and that’s making things very slow. So if you use TrustNet and notice errors or bad performance, this is why. It should be back to normal in about 4 hours (I intentionally slowed the resync so that things are at least usable, but performance will still be impaired meanwhile).

Update: It’s done now, things should be back to normal

[Solved!] Problems with group IMs

It seems that in my viewer group IMs aren’t working. That means that you won’t be able to receive or join group IM sessions. Normal IM from one person to another will work fine though.

I tried the unmodified source and it has the same problem. Trying to figure out now what is going wrong.

Update: Finally figured it out!
The viewer has something called the “message template”. This is a file that lists the various messages that SL uses to communicate with the grid and their format (field names, datatypes, etc). It is located in app_settings/message_template.msg.

The build instructions tell you to copy the file to its final location. This file is mandatory to have, and the viewer will complain loudly and exit with a fatal error if missing.

In the 1.18 version, the “message liberation” happened. Now new viewers can continue working on a grid that has more features than they support. I’ve not yet investigated the technical details very througly, but the basic idea seems quite simple: The viewer simply ignores the messages it doesn’t recognize. So for example, 1.18.1 adds the userlist to IMs. A 1.18.0 viewer doesn’t reconize the messages that send the list of participants, but can still join conversations.

Now, in 1.18 a new file was added: message.xml, and it seems to hold the messages that aren’t in message_template.msg. For some strange reason, missing it doesn’t cause a fatal error, so if it’s not there what happens is that the viewer fails to recognize anything that’s listed in it, which includes group IM messages, which apparently moved to this file in 1.18.

The build instructions I linked above don’t reference this file, and to my knowledge nobody mentioned it was necessary. Other people’s viewers are installed by overwriting an original install, which of course comes with the file correctly packaged, so they didn’t have this problem.

So, fix for the group IMs: Copy the app_settings/message.xml file from a standard SL install to mine.

I will be working on releasing an updated installer.

Update 2: Viewer released. It only contains a fix for this issue.

[Updated] Working on fixing the login page

As you can see, now the login page for my custom viewer includes this blog. I’ll use it in pretty much the same way as LL uses theirs.

Until recently the login page was static, so it wasn’t updating. I’m working on changing that. The RSS feeds now work, but grid status isn’t updating yet. I don’t have to stop just at this though, and will probably add something new to the page. I’m currently thinking of adding economic statistics. If anybody can think of something else useful to add, please add a comment.

Update:
Grid status and statistics now update. “Learn more” is still static, but everything else should work.