Colin K's Blog

Monkey Karate

noreply@blogger.com (Colin) — Mon, 14 Apr 2008 23:59:00 +0000

MySql 5.1

noreply@blogger.com (Colin) — Sat, 12 Apr 2008 18:45:00 +0000

MySql is the database system that is used for all Second Life's databases, which have been the main cause of most of the problems that have been occurring the past few months. The release of MySql 5.1 is coming next week, and according to Sun it "should help MySQL compete in environments where performance and the ability to scale are critical." That seems to describe Second Life perfectly. Also, "5.1 has not only greater reliability, but a performance increase of 20 percent. It will be more in some cases and less in others, but there's a significant performance boost and scalability enhancements." So let's hope this update does something to improve the current conditions, and that it doesn't take LL two years to update to this new version.

Moving in SL using body motions

noreply@blogger.com (Colin) — Sat, 12 Apr 2008 18:37:00 +0000

SVC-1862 Fixed

noreply@blogger.com (Colin) — Mon, 07 Apr 2008 15:50:00 +0000

There was an update to the Mono beta regions today that claims to have fixed SVC-1862, the issue I reported about listener performance. I just ran my tests again and confirmed that it is indeed fixed. And it was fixed by improving the performance of listen events under Mono, not by crippling the performance of them without Mono :P

My Little Pony Troll

noreply@blogger.com (Colin) — Wed, 02 Apr 2008 05:13:00 +0000

I have been laughing at this so hard. It's a (pic of a) thread showing someone trolling a My Little Pony forum. Most of the troller's posts have been deleted by the moderator, but there are some priceless responses that are still there.

"How could you possibly know that Osama Bin Laden collects My Little Ponies? I think you're just making that up."

"...and your picture of Stalin riding a Year3 Limited Edition Starflower inside a German concentration camp was both upsetting and historically inaccurate."

"I don't know where you get your facts. The first generation of MLP's were made by Hasbro, not the Khmer Rouge. And Hasbro hasn't made toys out of human skulls since the 1960s."

Update: Well, I found a link to the Stalin pic...it's actually pretty gruesome, so much so that I wasn't going to link to it, but then I decided you can all make that decision for yourselves. But anyway, you have been warned. Link

C:SI Now Using Monthly Payments!?

noreply@blogger.com (Colin) — Tue, 01 Apr 2008 01:35:00 +0000

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

noreply@blogger.com (Colin) — Sun, 30 Mar 2008 00:24:00 +0000

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

noreply@blogger.com (Colin) — Sat, 29 Mar 2008 00:10:00 +0000

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!

noreply@blogger.com (Colin) — Tue, 25 Mar 2008 18:18:00 +0000

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!

noreply@blogger.com (Colin) — Tue, 25 Mar 2008 02:03:00 +0000

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

noreply@blogger.com (Colin) — Sat, 22 Mar 2008 03:38:00 +0000

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

noreply@blogger.com (Colin) — Mon, 17 Mar 2008 23:53:00 +0000

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.

LSL Listen Mono Testing

noreply@blogger.com (Colin) — Mon, 17 Mar 2008 16:56:00 +0000

I just did some Mono testing specifically with listeners, and came up with some interesting results. First I did a basic ping test. One object would start a timer and say "ping" to another object which would then say "pingback", and the original object would report the time when it received the message back. Averaged over 200 tests, without Mono the ping time was 0.066478 seconds. With Mono, it was 0.088936 seconds. I ran the tests multiple times, switching back and forth between Mono and non-Mono to make sure this difference was caused by Mono and not by other changes in the sim.

Next I took Robby's idea and had one object say "start" then "junk" 500 times then "finish". Another object would start a timer when it got the "start" message and report the time when it got the "finish" message. First, I used an unfiltered listener, so any messages sent on that channel would be forwarded to the script. The sender reported that it sent "finish" 0.600243 seconds after it sent "start". The receiver reported 33.476112 seconds between hearing the "start" and "finish" messages. I then recompiled with Mono and ran the test again. This time all the messages were sent in 0.178058 and received in 44.580690. The sending was over 3 times faster, but the receiving was slower with Mono.

Now I modified the script to only set up listeners specifically for "start" and "finish" messages. Without Mono, they were sent in 0.600193 seconds and received in 0.644574. With Mono, 0.133408 and 0.133169. All these numbers have taught me two important things: 1) USE FILTERED LISTENERS!!! 2) ESPECIALLY USE FILTERED LISTENERS WITH MONO!!!!!

Now comes the fun part. I copied the unfiltered listener so that there were 25 of them. Each of them ran at about the same time as the single listener. With 100, they still ran about the same. With 1000, still the same. With 10000 (I'm serious...screenshot below) it was finally a different story. First, the time the sender reported to send the messages shot up to 1.916057 seconds. From that number, I estimated it would take 10 minutes for the listeners to finish. I waited for 15 minutes, expecting a Linden to show up and wonder what the hell I was doing, and still there was no response from the listeners.Notice "Script perf" is 0 ips. I'm guessing they just haven't updated that to count Mono instructions.

With the filters, there wasn't much of a change until 400 prims (I increased the number of prims differently). At that level, the listeners finished between .133783 and .201377 seconds, but one of them took 45.042740 seconds, which is so close to the time for the unfiltered listeners it almost makes me think the server panicked and just started handing that one script all the messages. I doubt that's the case, though, because then scripts which used filters and as a result didn't have to check the incoming message would experience errors if they started getting unfiltered messages. At 800 prims, the range was .156157 - .224534, again with a single script reporting at 46.228270. At this point, I didn't go further because looking through a log of 800 messages was getting difficult. Looking back at the data from the unfiltered runs, there was similar variance in the times as seen here, but when it is taking 45 seconds it is much less significant.

One final weird behavior that I noticed while recreating these tests for the Jira issue (see below). I went back to the ping test and added filters for "ping" and "pingback". I didn't expect to see any difference, since all the messages sent are "ping" and "pingback" (on different channels, so that is already filtered). Indeed, there was no difference when not using Mono. But with Mono, it took longer! The time increased to 0.101741, which is an increase of about .02 seconds or a 25% increase.

In conclusion, I am definitely going to use filters all the time now. I have created a Jira issue about the performance decreases with Mono. Now what can I test!? :P

Benchmarking Mono-Compiled LSL

noreply@blogger.com (Colin) — Mon, 17 Mar 2008 05:34:00 +0000

After Robby's response to my post about listener lag, I had the idea to see just what sort of speed improvements Mono will bring. I made a fairly simple benchmarking script that does the following tasks:

Integer addition (7000 times)

Float addition (7000 times)

Integer multiplication (7000 times)

Float multiplication (7000 times)

Integer division (7000 times)

Float division (7000 times)

Grow a list by repeatedly inserting [0] (300 times)

Randomize a list and sort it (100 times, list size 300)

Break a string into a list of words and check whether each word is equal to "hello" or "world" (200 times)

The tasks are pretty basic. That last one is generally what a listener would do. I chose the number of times each would be repeated so that every task would take about 10 seconds.

In doing this, I discovered that the performance of standard LSL scripts is extremely variable. I configured the numbers so that each task would take 10 about seconds; at this point I was at my house on the normal grid. But when I logged into the beta grid and ran the script in a Mono sim (without compiling to Mono), the arithmetic tasks each took about 3 seconds. Thinking maybe for some reason normal LSL scripts also ran faster on Mono sims, I tried running it at various other sims on the Beta grid. In some it ran at 10 seconds, others 3 seconds, others 17 seconds. I couldn't really see a pattern (Havok1 vs. Havok4, Mono vs. non-Mono), although it was always 3 seconds on the Mono sims, but I did get 3 seconds once on a non-Mono Havok4 sim. The numbers fluctuated between sims, but if I ran it multiple times on the same sim, I would get about the same results. Are all the sims on the beta grid Tier 5? It probably just comes down to how much other stuff is going on in the sim. But the last 3 tasks were always about the same time...very strange.

Anyway, here are the results. For the non-Mono numbers, I chose the ones closest to 10 seconds.

Task	Non-Mono	Mono	% Increase	Times faster
Adding integers	12.356465	0.133350	9166%	92.662
Adding floats	12.643500	0.066761	18838%	189.385
Multiplying integers	12.310993	0.066601	18385%	184.847
Multiplying floats	12.556296	0.044415	28170%	282.704
Dividing integers	12.355354	0.066727	18416%	185.163
Dividing floats	12.555955	0.044925	27848%	279.487
List insertion	10.018719	0.000000	N/A	N/A
List randomize/sort	8.905011	0.000000	N/A	N/A
String tokenize	9.640886	0.138814	6845%	69.452
Total	103.343179	0.561593	18302%	184.018

So the claims that Mono is over 1000 times faster don't seem to hold up. But still...this is just amazing. I laughed out loud when the benchmark finished in under a second when I had just waited over a minute and a half for the previous one to finish. I especially like how the list operations were too fast to measure. I am going to make some changes tomorrow so that I can actually get some numbers that I can analyze. I also want to add some more tests that better simulate "real-world usage". If you have any ideas, please tell me.

Goban v0.1

noreply@blogger.com (Colin) — Fri, 14 Mar 2008 00:54:00 +0000

Back in November I wrote about building a Go board. This past week I actually started building and scripting it, and without too much trouble it now has the basic functionality.There are still a lot of things I need and/or want to add. The biggest thing is probably that when a move is made that would capture stones, the board does not automatically remove them (the prims have to be deleted manually). Adding this feature is going to require me to store the board's state, which means more use of LSL lists, which have a strange and not very elegant set of utility functions.I also need to figure out how to attach the stones to the board after I rez them. If the board is moved, the stones will just stay there and be floating in space. Also, does anyone if there is a way to prevent those particle effects when something is rezzed or an object says something?There are two "modes". Two avatars can click on the board and join the game, and then the board will have them take turns placing stones. There is also a "Free Mode" where stones can be freely placed. Stones have to be placed by typing a command on chat channel 1. In game mode, you can just type "/1 d12" when it is your turn. In free mode, placing stones resembles the GTP protocol (e.g., "/1 play black d12" or "/1 play w k4), but you can specify more than one vertex in a single command and it will place them all. I'd like to allow placing stones by clicking, but I'm not sure if that's possible. I would have to put an invisible prim at each vertex to detect the click.

The board can be changed to 9x9 and 13x13 as well as the normal 19x19 size.Feel free to drop by my house and try it out, or IM me if you want someone to play against or to teach the rules (despite my interest in Go, I have not played many actual games and am not very good). Any suggestions or bugs reports are welcome.

Why Do Listeners Cause Lag?

noreply@blogger.com (Colin) — Tue, 11 Mar 2008 18:29:00 +0000

This is something that I have never understood, and have always been a little skeptical about. I have heard many people saying that scripts which listen, especially on channel 0, are one of the biggest contributors to sim lag. Of course, anything that requires processing power is going to contribute to lag, but are listeners really one of the biggest contributors?

Even when there are tons of people around talking, the number of chat messages per second probably doesn't go above 5 on average. So each listen script would have the listen event triggered 5 times a second. For a computer that can process billions of instructions per second, I don't really see how that can have any significant impact.

Is there something I'm missing?

Update:
I just did a small test. I figure that most listen event handlers will tokenize the string and then check each token to see if it is a known command (probably will only check the first token, actually). Since in most circumstances, the message is not a command to that script, that is as much as it needs to do.

I wrote a program that tokenizes the string "This is a test message that will be processed by this program." and then checks whether each token is equal to "command", and reports how many times per second it is able to do that. Averaging over 120 seconds, it did it 101963 times per second. This is running on a machine here at school, and I'm not sure of the CPU speed. The OS is Solaris and the CPU type is Sparc. Also, my process was only getting 20% of the CPU.

Granted, this wasn't a very good test since there are so many unknowns, but at least it shows that there would have to be a lot of listeners to slow down the CPU.

Network Neutrality

noreply@blogger.com (Colin) — Wed, 05 Mar 2008 07:07:00 +0000

This is an excellent video about the issue of network neutrality. I didn't realize that basically the same thing happened with printing and radio, which makes me even more scared about the possibility of this actually happening. If the internet loses network neutrality, it will most likely spell the end of Second Life (among many other things), as I'm pretty sure Linden Lab doesn't have the money to pay the telephone companies.

p.s. (What? I'm just stating facts, I'm not pushing a specific candidate :P)
Obama is for network neutrality and has promised to make it a priority for his first year in office.
Clinton has said she is for network neutrality, but it is not something she has mentioned as part of her campaign.
McCain is either genuinely undecided, or doesn't want to publicly say he's against it. He has been quoted as saying, "When you control the pipe you should be able to get profit from your investment."
Sources: 1,2,3,4,5

Gizmondo

noreply@blogger.com (Colin) — Wed, 27 Feb 2008 04:33:00 +0000

Remember Gizmondo? Not Gizmodo, the tech site, but Gizmondo, the hand-held game device that was supposed to compete with the Nintendo DS and PSP? Neither do I. It was a huge flop and the company went bankrupt. But I came across this Wired article about a year ago, and I never get tired of reading it. The story behind Gizmondo is simply amazing. Here is the first paragraph to catch your interest:

THE BUMP IN THE ROAD that ended Bo Stefan Eriksson's fantastic ride is practically invisible. From 10 feet away, all you can see is the ragged edge of a tar-seamed crack in an otherwise smooth sheet of pavement. Only the location is impressive - a sweet stretch of straightaway on California's Pacific Coast Highway near El Pescador state beach, just past the eucalyptus-shaded mansions of the Malibu hills. On that patch of broken asphalt, there's barely enough lip to stub a toe. Of course, when you hit it at close to 200 miles per hour, as police say Eriksson did in the predawn light last February 21, while behind the wheel of a 660-horsepower Ferrari Enzo, consequences magnify.

This other article has more details about the history and especially the financial data of the company. After reading these two articles, I come to the same conclusion as one of the commenters on this article: "The whole thing was a front for the Swedish mafia to launder money."

And it looks like this story might not be over. From Wikipedia:

In November 2007 Carl Freer stated in an interview for the Swedish-American journalist Hans Sandberg that he was interested in starting up production of the Gizmondo again. The interview was published in the business news site Realtid.se, and a translated segment of the interview was made available on the author's blog The Nordic Link on January 23, 2008. The week before, Veckans Affärer, another Swedish business publication, had confirmed Realtid's story about Carl Freer's cooperation with the British company Plextek, who designed the original platform.

Skittles Commercial

noreply@blogger.com (Colin) — Thu, 21 Feb 2008 00:03:00 +0000

This commercial is amazing. I've seen it on TV a couple of times, but it was a shortened version that's missing some of the best parts.

Framerate and Ping

noreply@blogger.com (Colin) — Tue, 19 Feb 2008 00:28:00 +0000

There's always a lot of talk in C:SI about improving framerate. I've also heard a lot of comments about how after a certain framerate, the human eye can no longer see any difference and so improving framerate past this has no point. Usually the number stated is 24 or 30 fps, because those are the framerates of movie projectors and televisions (NTSC), respectively. While the reasoning makes sense to me, it definitely seems like I can tell a difference between 30 fps and higher rates. I decided to see what information I could dig up about this, and found this interesting article. The article explains how blurred images and other techniques are used to make 24-fps movies appears smooth, and so these are actually not the limit that we can detect. According to the article, the question is actually extremely hard to answer, but it's pretty clear that it's at least 100 fps, and probably much higher than that.

The article also touches on the aspect of monitor refresh rates. Basically, your monitor can only redraw the screen a certain number of times per second, and that's probably lower than the framerate your eye can detect. It also mentions that it might actually appear worse if you have more fps than your monitor refresh rate can support, because it has to sync the frames by repeating some.

Ping time is also something that is often stated as making a difference in duels. I have personally tried fighting with ping times of over 2000 ms, and that definitely makes a difference. But what about more normal variations? I usually get a "ping sim" of about 70-90 ms. That is the time it takes an empty message to travel from my computer to the Second Life server running the sim I'm in, and then get sent back. What does this mean for dueling? From my experience during times of extremely high pings, I know that the way SL works is that when I press a key to slash, my client does not immediately start displaying the slash animation. That message must first reach the server, then a message is sent to both people telling their clients to display the animation. What this means is that if both of us have equal ping times, we should both see my slash at exactly the same time.

Usually people have different ping times, though. I've heard people in Europe saying they usually have pings around 150 ms. If I were fighting them with my 70 ms ping, that would mean that they see the animations 80 ms after I do, including their own attacks. Is 80 ms significant, though? According to Wikipedia, the reaction time for humans is between 150 ms and 300 ms, so it doesn't seem like that would really make a difference. But then again, it doesn't matter how quickly a person reacts, it will still be delayed by 80 ms in this example. But...will that delay in their reaction matter since their opponent can only react at 150-300 ms? I'm confused.

OpenSim and realXtend

noreply@blogger.com (Colin) — Sun, 17 Feb 2008 22:10:00 +0000

This started out as a comment I was writing in response to Robby's post about realXtend joining OpenSim. It grew so large I decided it was probably a better idea to post it here.

It will be interesting to see how Linden Lab reacts to this. I'm sure most of the features realXtend will bring are ones that LL would love to have in their own server code. OpenSim is released under the BSD license, which is one of the least restrictive open source licenses out there. It looks like the license only requires that any code or binary distribution be unrestricted in terms of copying and redistribution, and carry the same license.

BSD License:

Redistribution and use in source and binary forms, with or without modification, are permitted provided that the following conditions are met:
* Redistributions of source code must retain the above copyright notice, this list of conditions and the following disclaimer.
* Redistributions in binary form must reproduce the above copyright notice, this list of conditions and the following disclaimer in the documentation and/or other materials provided with the distribution.
* Neither the name of the OpenSim Project nor the names of its contributors may be used to endorse or promote products derived from this software without specific prior written permission.

But here's the thing: LL doesn't distribute their server code or binaries; they run them on their own servers. I'm not a copyright lawyer or anything, so I'm probably wrong, but it seems like LL might be able to incorporate the OpenSim code into their own server code without really having to publicly release it. That seems a little fishy to me, but I know that the BSD license is often criticized as not being a true free software license, and maybe this is why.

From the Wikipedia article on the BSD license: "The BSD License allows proprietary commercial use, and for the software released under the license to be incorporated into proprietary commercial products. Works based on the material may even be released under a proprietary license (but still must maintain the license requirements). Some notable examples of this are the use of BSD networking code in Microsoft products, and the use of numerous FreeBSD components in Mac OS X."

I'm a strong supporter of open source software, but the problem with OpenSim is that while they are going to be adding all these exciting features, there's probably not going to be a grid running OpenSim anytime soon that has the resources to support 60,000 simultaneous logins. That's why I'm kind of hoping for LL to "steal" the code (it's OpenSim's fault anyway...everyone knows you're supposed to use the GNU Public License :P)

Mono Refresh

noreply@blogger.com (Colin) — Fri, 08 Feb 2008 00:16:00 +0000

They made another update to the Mono Beta today. With the fix of "[SVC-1331] Floating point fed to conditional causes error", LSL/Mono is now even closer to completing the "basic things any programming language should do" checklist. As posted in the bug report, this basic script would produce an error:

default
{
    state_entry()
    {
        if(1.0)
        {
        }
    }
}

See my previous post for more comments about this. Actually, the image probably won't load because the website hosting it is currently suffering from the Digg Effect. Edit: Nevermind, the pic should work now.

Dear Lindens

noreply@blogger.com (Colin) — Thu, 07 Feb 2008 10:57:00 +0000

Dear Lindens,

I have decided to evaluate your performance over the past few months.
Actually, that bike is working perfectly fine, they just need to change the sit target and adjust the link position of the front wheel.

Edit: I uploaded my own copy of the pic instead of linking to it, so it should load reliably now.

C:SI Stats Perl Script

noreply@blogger.com (Colin) — Wed, 06 Feb 2008 07:10:00 +0000

I wrote a Perl script that grabs avatar duel data from the C:SI website and calculates some useful information. It can be downloaded here. I know that most of you reading this probably have no idea what to do with a Perl script. If I had the resources, I would put it up on a web site so that everyone could make use of it. I invite the C:SI devs to take this script and use it on the website, or for Robby to do something with it on his blog (or anyone to put it up on the web, for that matter). It takes avatar names as command line arguments, and is especially useful if given multiple names (so that you can see the combined stats of your alts).

Example:

$ ./csiscores.pl Colin Kiernan Selene Corvale
Getting stats for Colin Kiernan...
Getting stats for Selene Corvale...

Colin Kiernan
 Total Wins Losses Ratio
Count 3323 1686 1637 1.0299 (102:100)
%total 93.13% 91.38% 95.01%

Selene Corvale
 Total Wins Losses Ratio
Count 245 159 86 1.8488 (184:100)
%total 6.87% 8.62% 4.99%

Overall
Total Wins Losses Ratio
3568 1845 1723 1.0708 (107:100)

Edit: Another thing you could do with this is list all the members in a clan and get the total clan score, how much each person contributed, etc. If you do that, I recommend promptly logging into SL and buying a few more swords to cover the bandwidth you've just used on the website ;)

Edit 2: I forgot to mention that it only takes the stats from the first page (30 sims). Since they are sorted in order of most duels, the sims omitted probably won't have that big an effect on the results.

Glasses

noreply@blogger.com (Colin) — Tue, 29 Jan 2008 07:55:00 +0000