Ananké Media Systems

After the 1st February blues

2 February 2008 at 2:16 pm Anna Tretiak Leave a comment

Now that the SL glitch that broke the PhotoStage’s scripts has been solved, we can spend some time explaining exactly what happened.

Linden Lab announced an update of the server code on 31st January. This was applied as a rolling restart, which caused no apparent problems other than the sims going offline for a few minutes as it is usual. However, the server update changed something that was not documented, announced or advertised. Before the update, the Description field of any prim could contain many characters, including (why not, one could ask) the character called a pipe “|”. This character is often used by scripters and programmers as a delimiter, i.e. used to separate blocks of text or values from each other. The Description field of prims is also used frequently as a common place where data can be shared by multiple scripts running in a single prim. Finally, I must point out something that is pretty evident, but apparently needs pointing out (you will see why in a minute): when you put some text into the Description field of a prim, you expect it to stay there, unchanged, until you (or somebody else) changes it. This is just common sense.

After the update, things changed. You can still put a pipe character into the Description field of any prim, but that character is automatically and silently converted to a question mark “?”. Imagine that your script puts the text “hello|there” in the Description of a prim; next time you look at it, it will show “hello?there”. As you can imagine, having characters changed by SL under the hood, silently, and without your permission, is not a good thing. Your script relies on finding some text there and, instead, it finds something else. As a consequence, what used to work before doesn’t work now.

I am going into rant mode now.

Change happens, and I think it is okay to make changes to the way scripts work. But when a change is going to break your scripts and make them stop working, you absolutely need to let people know in advance. It is a shame that this change was documented by Linden Lab after the fact rather than days or weeks in advance. If Linden Lab had announced this change in advance, scripters would have cursed, probably, but we would have had time to modify our code to make it work under the new server update.

AMS products make extensive use of the pipe character in the description field of objects to exchange data between scripts and, as a consequence of the server updates, all of them stopped working overnight. We got lots of customer calls, and spent lots of hours trying to find a defect that was not in our scripts. Shame.

What is even more shameful is that, under the new server update, no error is thrown when a pipe character is used in an object’s Description field. Any decent engineer knows that a silent failure is the worst kind of failure, since it is extremely hard to track down and you don’t notice the problem until some arbitrarily long time has passed. The new server code that Linden Lab deployed during the rolling restart of 31st January allows the LSL function llSetObjectDesc() to take pipe characters, but, as I explain above, they are written to the prim’s Description field as question marks. No error, no notice. This is just pathetic, and something that would guarantee very bad marks to any of my first-year programming students. Shame shame shame.

I often find SL wondrous, and become astonished at how well things in SL work. However, engineering practices such as what Linden Lab has done with this server update are simply unacceptable coming from professional software developers. This incident has made Linden Lab appear like a bunch of amateurish kids toying around, oblivious to the consequences that their actions may entail.

Okay, finishing rant mode now.

Entry filed under: Issues, Opinion, Technical. Tags: failure, LSL, pipe character.