Category Archives: Technical

Posts that deal with the technology behind Second Life, and my attempts to master it.

Have I Reached The Party To Whom I Am Speaking?

lily_tomlin_01Apparently, Linden Lab® is introducing a new feature for Second Life® users, called “AvaLine” (I’m not sure if there should be an ®, a ™, or what after that word, so sorry, LL), which will allow people to dial a phone number and be connected to your avatar in-world.  Tateru, over at, wonders what it’s useful for.  Quite frankly, so do I.

First of all, if you’re also a SL user and you need to get hold of another SL user that badly, the obvious way to do it is to fire up SL and make a voice call (or send an IM) that way.  Minimum hassle, no charges incurred.

Well, maybe you’re at work, or somewhere else where you don’t have the SL viewer handy.  You’re not out of options, though.  You can use another application, like Skype, to make a voice call.  You can send a message using another instant-messaging program, like Yahoo! IM, MSN, or GTalk.  You can send an E-mail.  You can even call the other person’s actual phone.  (That’s the way I’d get a hold of Lexx, for instance, if I really needed to talk to her quickly.  Likewise, she can call my cellphone, or send a text, if she needs me that quickly.)  Of course, this depends on the other person having made their outside-SL contact info available to you…which not everyone will have done, for whatever reason.

Ah! So maybe now we have a target market for AvaLine!  It would be SL Residents:

  1. Who want to be reachable by people outside of SL at any time;
  2. But, for whatever reason, don’t want to make any contact information available other than that linked to their SL avatar.

Aside from sounding slightly dodgy to me (and that’s just a matter of personal opinion), how big can this target market be?  In a world full of free Skype accounts, free IM accounts, free E-mail available through Yahoo, Microsoft, or Google, and low-cost cellphones with prepaid minutes–none of which have to have any public link to your RL identity–can AvaLine, which LL has admitted they intend to charge for eventually, find a niche?  And can you really do extensive business in SL without entrusting the people you work with, who might most have need to get hold of you urgently, with something more than an avatar name?

Also, of course, you have to use SL’s voice support to use AvaLine.  Which lets me, and most of the people I deal with, off right there, as we all tend to disable SL’s voice support and use Skype amongst ourselves.  It works well enough for us, as it has since before LL introduced the voice support in the first place, and it has the added advantage of staying operational and connected even if the SL viewer crashes, or if we decide, for instance, to exit SL and go to EVE Online.  (EVE also has built-in voice support…which we also don’t use, and for pretty much the same reasons.)  One could also use TeamSpeak or Ventrilo for the same purposes.

So AvaLine may be a great new “gosh-wow” feature for SL, but, really, it seems like a solution in search of a problem.  One wonders why LL is devoting resources to this instead of, you know, fixing the goddamn bugs.  (Not to beat a dead horse or anything…)



Filed under Business, Technical


Just two days after I posted my call to Linden Lab™ to cut the crap and make the Second Life™ Grid, you know, actually work, they’ve proven they can’t listen worth a damn:

Today we are very happy to share some exciting news with you: Linden Lab has acquired Xstreet SL and OnRez – the two leading Web-based marketplaces for buying and selling creations for Second Life. Over the past few months we’ve been working with the folks at Virtuatrade and the Electric Sheep Company to hammer out the details…

How much of those “last few months” spent in negotiating to take over two services that, unlike the Grid, actually work, could have been spent on, say, making the Grid actually work?

How much effort will integrating these two services into the overall SL environment suck away from making the Grid actually WORK?

And will these two services now quit, you know, actually working once they’re subsumed into LL’s already bursting-at-the-seams infrastructure, thus requiring even more effort to make them work again, effort that could have been devoted to making the Grid actually WORK?

(Are you starting to see a pattern here?  I hope so. 🙂 )

I’ll leave it to others to debate the business aspects of this acquisition.  I’m more interested in having a working environment in SL.

Linden Lab: Does the phrase “fiddling while Rome burns” do anything for you?

UPDATE: Okay…now maybe I can start to believe that LL is taking these problems seriously.  But I’ll refrain from sending the roses until I see some real results.

1 Comment

Filed under Bugs, Business, Downtime

Linden Lab: This has gone FAR ENOUGH. Fix SL *NOW*.

As I write this, Selena has just had to cancel our Sunday night event because Second Life™ is brokenAGAIN.

Most In world services are at reduced functionality at the moment. Please avoid L$ transactions or handling valuable (no-copy) assets until we post an ALL-CLEAR. Regettably, our ability to broadcast a warning in world is also disabled. Please let your friends know if you’re logged in. [emphasis mine]

When the system is so broken that the Lindens can’t even broadcast a message to tell people in-world how broken it is…well, something is rotten in the state of Denmark.  And it sure as hell ain’t Danish blue cheese.

Friday night, we had to cancel our event because the sim on which Solar Moonlight sits (Tyros) suddenly crashed on us, logging us out, fifteen minutes before the event was due to begin…and, upon logging back in, we were unable to TP there.  Thank God Lexxotica still seemed to be up and running, or who the hell knows what would have happened?

And this doesn’t just affect us; Prokofy Neva, one of the few people who tries to run a rental business in a reasonable manner, reports that he’s getting lots of people breaking leases:

I don’t know whether people refund because they can’t log on and get sick and suspicious of SL even when they *can* log on (or perhaps they get mad their friends can’t log on), or whether, more likely, they can log on, but they can’t get me to do something for them because *I* can’t log on.

Either way, bad for business.

Much as Prok’s critics might cheer his business troubles, anything that’s bad for his business is likely to be worse–perhaps fatally so–for other businesses.

Meanwhile, the Lindens issue self-congratulatory blog posts, promise “pie in the sky, by and by” with infrastructure improvements (that have yet to materialize), and continue to chase educators with a platform that can’t seem to even support its present level of use, let alone act as a mission-critical tool for education.  Anyone else have the words “fiddling while Rome burns” coming to mind?

It’s time for the Lindens to start bringing what Jim McCarthy, in his book Dynamics of Software Development, called “radical focus” on the problem of stability of the SL platform.  You can’t call for radical focus too many times over the course of a project, as McCarthy points out, but at this point the Lindens are overdue.  Come on, M Linden, now’s the time to show leadership.  If my own boss in RL can do it, you can do it.  LL’s ability to ship bug-free code has fallen from “average” down to “marginal at best,” and is continuing the spiral towards “complete fiduciary misconduct” at this point.  How much more do they think their paying customers can take?

“…I warned the distributor I’m a Hershey bar…The Hershey bar gets smaller and smaller to stay the same price.  But it can only get so small.  I can shrink myself only so small before I’m nothing, a man without quality or quantity.” – Mort Lesser, “Mouthpiece,” by Edward Wellen

UPDATE: FJ Linden has posted a big, semi-technical explanation of what’s been going on and how LL is moving to fix it.  All well and good, FJ, but, as we say in America, “Talk is cheap.”  If you want to convince me, and other dissatisfied Residents, that you mean business, here’s the way to go about it:

  • Your timeframe for the rollout of these fixes is WAY too long.  Think “days,” not “months.”
  • What about manpower to meet that timeframe?  Easy: Every Linden who can code should be working on stability fixes right now.  Every Linden who can’t code should be working on testing said stability fixes. It’s “crash priority” time.  You guys’ future is at stake.
  • Forget all those other side projects, like building more mainland sims, or replacing the browser engine in the client, or other such foolishness.  All other considerations must be secondary to stabilizing the Second Life Grid and making it so people can actually USE it. I remind you: Your future is at stake here.

In other words, LL:  It’s time to shit or get off the pot.  Go big, or go home.


Filed under Bugs, Downtime

DJ CoolJ Hits First Life

This past weekend, “DJ CoolJ” played his first gig in First Life, DJ’ing the wedding ceremony and reception for my RL brother, David, and his longtime companion, John.  (Yes, it was a same-sex marriage.  This happened in California, where such things are legal, at least for the moment.  Any flames about the morality or lack thereof of the proceedings will be sent to /dev/null, because (a) I don’t want to hear it, this is my brother we’re talking about here, and (b) it’s not all that relevant to my part of the story anyway.)

The story here started back in July, when I received this message from another of my brothers:


David and John are getting married in Sacramento on October 19.  They would like you to attend and to be their DJ at their reception.

Would you be willing to do this?

Oh, certainly, I was willing!  But all my DJ experience has been as a Second Life DJ, behind the controls of SAM; the question was, how would I translate that into the real world?

SAM outputs an MP3 stream, intended for receipt by a Shoutcast server.  The simplest thing to do was to use another computer to translate the MP3 stream to audio.  I had a suitable machine on hand, which had been a gift from David, in fact: an OLPC XO-1, which runs Linux.  I installed the program mpg123 on it, which could decode MP3 and send the resulting audio to the machine’s audio output device (speakers or headphone jack), and wrote a short Python script to “wrap” around it and mimic the protocol implemented by a Shoutcast server.  The resulting arrangement had a slight delay in the audio output, but worked, slick as you please.

In the interim, of course, I had fallen in love with “Selena” and brought her to live with me in Denver, so, naturally, she got to come too.  (In fact, I think she realized this when she knew she was coming to live with me; one of the things she said over our IMs was “OMG I get to come to your brother’s wedding!”)  So we turned it into another road trip, not unlike the one I made to bring her to Denver, carrying, as part of our cargo, my computer, her flat-panel monitor, the XO-1, and a whole slew of cables and connectors to put it all together, including a wireless router, as the XO-1 uses wireless networking.  Once there, the XO-1 would be plugged into a (rented) “pro” DJ mixer/power amplifier rig and a pair of massive Peavey speakers, boosting its output to fill the room.

We pulled it off; there were a few glitches, but the happy couple was pleased with the performance, as were the other guests, including my parents.  I plyed my routine much as I would in Second Life, and I did see some weirdness that made me think I had logged back into the Grid (try: four groomsmen doing a synchronized dance routine, pantsless, to the tune of “I’m Too Sexy”).  I put out a “penguin tip jar” (a jar with a stuffed Tux next to it, and an appropriate labeling placard), and netted $38 in tips; by Linden Dollar standards, that was a smash hit gig.

Would I ever consider doing this again?  Well, if I did, I’d want to have a proper Windows laptop to load SAM and my music library onto, to avoid lugging around that heavy tower system.  But I’m pleased that it worked as well as it did.

Leave a comment

Filed under Audio, First Life, Music

A Scripted Bagatelle

This evening, Lexx handed me a small object made by a fellow named Petr Brandenburg, that alternately flashed yellow and cyan. She couldn’t read the script inside it, so she didn’t know how it worked. She asked if I could figure it out.

Within a few minutes, I had handed her this:

// Neon Flasher Script
// Erbo Evans - 3/23/2008

// List of colors to cycle through, specified as  tuples.
list colors = [<0.0,1.0,1.0>, <1.0,1.0,0.0>];
float delay = 0.5;  // how long to wait between color changes
integer index;  // counter used to keep track of color state

    { // initialize the color index and display the first color
        index = 0;

        // set up the timer to flash colors
    } // end state_entry

    { // advance to next color and display it
        if (++index>=llGetListLength(colors))
            index = 0;  // wrap around back to beginning if we run off the end
    } // end timer
} // end state default

Simple enough to understand. The script itself is basically a timer-driven state machine, using a table (the colors list) to specify the colors to be displayed on the prim (which uses a blank texture on all faces to better show the effect).

As an exercise, I asked her, “How would you extend the script to flash more than two colors?” Because of the way I wrote the code, it’s very easy (just extend the colors list). However, she stared at it and felt her brain begin to melt. I think it was mostly due to the fact that she was running on only four hours sleep, though. 🙂

1 Comment

Filed under Scripthackery

How Not To Run An Event

Recently, I was asked to DJ an event at another club, which I agreed to do and for which I was paid my standard rate. However, when I got to the site of the gig, I found that certain things hadn’t fallen into place…

  • The club’s stream information had just been changed, which apparently they do on a monthly basis. (I do approve of this as a security measure, as it keeps rogue DJs from hijacking the stream.) I had received the correct login information, and it worked…but the club’s stream changer had not yet been updated with the new stream URL.
  • Only one person had access to modify the settings notecard for the stream changer…and he was unavailable.
  • I thought that perhaps the URL could just be set on the parcel manually, via the land settings dialog. Unfortunately, the club’s land had not been group-deeded, so only one person (the land owner) had the ability to change the parcel media settings…and he was unavailable as well.
  • What’s more, the event had not been publicized (via a listing in SL Events or such), so it was likely that there would be little turnout, even if the stream issues could be resolved.

In the end, the event was postponed to a later date, and I agreed to come back at that date. But this particular event had required a lot of prep time on my part, so naturally I was somewhat miffed.

There are some lessons to take away from this experience. First, always have a backup plan in place for your business operations. First Life does take precedence, but if the absence of one or two critical people can throw your business into disarray, you need a better backup plan. In the case of Lexxistential Deviances, if Lexx is not present, I can perform her functions, as can Lilli. The businesses I’ve been involved in have a long history of having backup plans, to the extent that, when Danielle’s home in RL was burned in a fire, I was able to keep the Gin Rummy open despite her extended absence.

Second, group-deeding business land is good. If your land is group-deeded, you have a lot more options in controlling who can do what to the land, thanks to the group role and permission capabilities we’ve had for some time now. In our case, we allow people designated as “DJ” to change the parcel media settings, as, obviously, they may need to do that to broadcast. We do use a stream changer of our own, an Erbosoft Distributed Music Changer (of course!), and it does have a “manual override” mode where you can feed an arbitrary URL in via a chat command, if you have the right access; still, it’s good to have a backup capability (which relates back to my first point).

Third, have procedures in place for publicizing events. In our case, we determine the events for a weekly block (Friday through Monday) in advance, complete with staff assignments for each event, which Lexx distributes to the staff group via a notecard attachment to a Group Notice. Then I take her notecard and write the descriptions for the events, which I post to SL Events. Just before event time, our host for the evening grabs a copy of the event text and uses that to create a Group Notice for the VIP group.

N.B.: I am deliberately not identifying the club involved in the little snafu above, because I believe they can do better and I don’t want to embarrass them, just help them and others to keep from making those mistakes. Any comments which identify the club in question, even very generally, will be deleted with extreme prejudice.


Filed under Audio, Business

Notecard Writing: A Modest Proposal

Jacek laments the lack of ability of scripts to write to notecards, thus depriving them of a potentially-useful mechanism for saving persistent data across script resets. (Other scripters have used the object name or description to store such persistent data, but the fact that LL is now enforcing strict limits on the length of those fields limits the usability of this technique.) We are told that this is because each edit to a notecard creates a new asset in the asset server, and it would possibly overwhelm the server, as if it wasn’t overwhelmed enough already.

Well, how does it handle people editing notecards normally? I’m guessing that, when you bring up a notecard window in the client, you don’t actually create a “new” asset until you press the Save button. Is there any reason why we couldn’t have script APIs that work the same way? Say, when you open a notecard for writing, buffer the data in memory, and only actually save that data, creating the new asset, when the notecard is closed?

Here’s an example of how these APIs might look. (Warning! These are not real APIs! I’m only showing you what I think they might look like.)

integer llNoteStreamOpen(string name, integer mode);

Opens a notecard for writing. name specifies the name or key of the notecard to be written to, which must be an existing notecard in the inventory of the object holding the current script. mode must be one of NOTESTREAM_OPEN_OVERWRITE (to overwrite the existing data in the notecard) or NOTESTREAM_OPEN_APPEND (to append to the existing data in the notecard). The return value is a “handle” used to interact with this notecard stream, or -1 on error.

Scripts may only have a maximum of N notecard streams open at one time (where N is a small number, perhaps as low as 1). Attempts to open additional streams beyond that result in an error.

integer llNoteStreamWrite(integer handle, string data);

Writes data to the notecard stream. Data written is buffered and is not actually saved to the notecard until the stream is closed. handle specifies the handle of the notecard stream to write to. data specifies the string data to be written. The return value is the number of characters written to the notecard stream, or -1 on error.

key llNoteStreamClose(integer handle, integer disposition);

Closes a notecard stream. handle specifies the stream to be closed. disposition must be either NOTESTREAM_SAVE (to save the changes to the notecard) or NOTESTREAM_DISCARD (to discard the changes to the notecard). Returns the UUID of the notecard that was modified (the new UUID if changes were saved, the original UUID if changes were discarded); returns NULL_KEY on error.

When a script is reset, any notecard stream handles it holds open are closed as if llNoteStreamClose(handle,NOTESTREAM_DISCARD) were called on them.

I don’t know how feasible this all would be to implement. Perhaps we’d need an upper limit on the buffer size for the notecard stream, which would limit its usability for some purposes, but not for others. Perhaps any or all of these functions would need script execution delays built into them. Perhaps the streams should be automatically closed/discarded when the script changes states, much the same way timer handles get reset, instead of when the whole script is reset.


1 Comment

Filed under Scripthackery, Technical