C:SI Now Using Monthly Payments!?

This has just been posted on the C:SI website. April Fools', right? That's what I thought, until my sword requested permission to take Lindens from my account. I choose "Deny" and it disappeared from my inventory! WTF? I hope the devs realize how many customers they are going to lose because of this.

Mono Listener Performance Update

Time for some updates about SVC-1862, which is the bug I reported concerning listeners performing worse in Mono compiled scripts.

• It has been marked as relating to SVC-1398, which is about link messages in Mono being 2 times slower. Link messages were something I was going to test myself until I saw that this bug had already been reported.
• Lee Ludd commented that it might be related to Mono using 16-bit characters instead of 8-bit characters. I ran the tests again using different string lengths to test this theory, and there wasn't any noticeable change.
• Gordon Wendt says he mentioned it during Linden Office Hours, so hopefully this is something they will look into soon. Still no comments from any Lindens on the Jira page, though.
  

Getting Back to Building

I haven't done much with my Go board recently. Mostly because I am once again trying to switch to using a Linux environment as much as possible, but have been discouraged from using Second Life because of sound problems.

However, I now have three people who have expressed interest in owning one, so that has encouraged me to try to get back to work.

I'm thinking about changing the way my board handles the stones. Right now, each time a stone is played it rezzes a prim for the stone. The other option is to have an invisible stone fixed at each location on the board, and then when a stone is played make it visible and set its color. The advantages to the second method are that now the players can just click on the board to place a stone instead of having to type in the coordinates. Also, the stones can be grouped with the board so that if the board is moved, they will move as well. It doesn't seem like there is a way to group prims through scripts, so some other method that would most likely be more complicated and not work as well would have to be used to get the same effect.

The obvious disadvantage, and the original reason I went with the first method, is that the board will require 368 prims at all times. Using the current method, it only needs 7 prims when not in use, and if the players are only using a 9x9 or 13x13 size board, they won't come near 368 prims. Even on a 19x19 board, not all games will use 368 prims. As I think about it more, though, is there really an advantage to having it only take 7 prims when not in use? They will still need 368 prims available when they want to use it, and I doubt many people will want to have to return all their furniture or something each time they want to use the board, then re-rez it when they are done.

I have come across two other Go boards in SL. One of them uses this method I'm describing of just having invisible prims for all the stones. The other had the user click the board which would rez a stone, then the user had to edit the stone and move it onto the correct board position. I'm not a big fan of that last method.

Any suggestions?

Enough with the Frequent Problems!

Second Life seems to have problems on a weekly (or daily?) basis. It wasn't always this way, although I think it's more that Linden Lab is being more public about the problems on the blog and SL isn't necessarily more unstable than it used to be (although that could still be the case). There have been announcements of problems today, yesterday, Saturday, Friday...I'm getting tired of linking, but there were also problems last Monday, Tuesday, and Wednesday. Along with many of these problems (including all of the ones I linked to) comes LL advising people not to make any transactions, which can significantly hurt business as some have pointed out.

This pattern has been going on for a while, and I'm starting to wonder how LL is responding to these problems. It almost seems like they are just working to get things back to normal as quickly as possible, but in the process are not making any attempt to actually figure out how to prevent the problem from happening again in the future. With the frequency of these problems, and the fact that they have been going on for months at this frequency, I find it very unlikely that all of these problems are caused by unique issues. Some of them must be recurring problems that we have had before.

Now, with all the linking I have done back to the official Second Life blog, it's very likely that a Linden Lab employee will end up reading this post. I understand that you want to fix these problems as quickly as possible, but I, for one, would prefer to have the problem persist for longer if it means that you can take the time to diagnose the cause and make adjustments so that the problem isn't likely to happen again. I think in the long run this will make the users of SL happier and increase the uptime of your services in the future.

Linux Client Sound FAIL!

I'm trying to use the Second Life client on Linux again, which I haven't done in a long time. I posted a while back about the differences between the clients, and in the last paragraph of that post I talk about the sound problems I have had in Linux. Well, the problems seem to have gotten worse. Now the sound stutters (like when you're trying to play a scratched DVD). Hopefully I will be able to find a way to fix it. At this point, I'm not even sure if it's a result of changes in the Second Life program or in Ubuntu.

Edit: The shell script that runs Second Life has some sound configuration options. After playing around with them, it looks like Second Life is using OSS instead of ALSA. This is probably the source of the problem, now I just need to figure out how to get it to use ALSA.

Second Life Command Line Options

There are some useful command line options for Second Life that I'm not sure many people know about. To add a command line option in Windows, you have to right-click on the Second Life shortcut, choose "Properties" and then add the options to the end of the "Target:" line. Mac users...you're on your own. Maybe someone who owns a Mac can post a comment explaining how to do it.

-multiple
This will stop Second Life from preventing you from running more than one viewer at a time, allowing you to log on to multiple accounts simultaneously on the same computer.

-autologin
Bypass the login screen and automatically log on with the name and password that is stored. You can also use "-login <first> <last> <password>" to log in as any account without the login screen.

-purge
Clears the cache when it runs. This is useful because normally if you want to clear the cache you have to log in, click "Clear Cache" in the options, then log out and log back in. There might also be a case where the cache is corrupted and you crash before you can even get to the "Clear Cache" button.

-safe
If you set some options that now cause your viewer to crash immediately, you can run with this parameter to reset your options.

-local
This didn't work for me when I tried it, but it's supposed to run the viewer without connecting to the simulator. I was interested in seeing what that was like, and what exactly you could do without a simulator.

There is a full list of command line options here.

Go Board Updates

I was glad to see that one of the changes for the new server code being updated this week is "Support for PRIM_GLOW in llSetPrimitiveParams - this will require a forthcoming viewer update to author and compile scripts that use this, however". I was looking for this feature a few days ago because I wanted to add a feature to my Go board that made the last move glow.

Speaking of that, I have been spending a lot of time working on it since my last post (though I've been focused on the Mono testing these past few days). Most of the work has been in things that aren't finished, aren't visible, or were dead ends (at least I was learning how NOT to do things). Here is a quick list:

• The board state is now stored (storing 19x19 integers comes very close to the memory limit for scripts, so I had to make a script that is basically a data server and other scripts query the data through link messages).
• With the board state stored, I can now report an invalid move if a stone has already been played there.
• I added the board's rotation into the stone placement, so it no longer has to be aligned along the world y-axis to place the stones in the right place :P
• I spent a TON of time fooling around with llSetCameraParams, trying to get the camera to face straight down on the board from above. This was in preparation for an idea for a HUD which would overlay things onto the board. Unfortunately, the camera controls don't really allow for precise placement. I was able to get the camera to face straight down on the board, but I could not control the "roll" of the camera (up vector in more technical terms). The SL camera always tries to keep its up vector as vertical as possible. When the camera is facing straight down -- so the up vector becomes completely horizontal -- it apparently always points along the positive x-axis. I could not find a way to change this after much tweaking of the llSetCameraParams arguments. I had to give up.
  
• I started looking at HTTP requests. I had code for a multi-threaded web server from a networks class I took, so I got that running and was able to send a message to it from SL and get a response. It shouldn't be too hard to have it run copies of GNU Go and pass GTP messages back and forth.
• I downloaded QAvimator and started learning how to make animations.

This Go board project is pushing me to learn a ton of different aspects of Second Life content creation. It's great.