Coming Soon: Skill Games!… yay?

When I first saw the headline “Coming Soon: Skill Gaming in Second Life!” I thought “Ooh – what neat new feature are they rolling out now?”

But no.  What is happening is that a whole lot of devices previously allowed as TOS-compliant “skill games” under the wagering policy are now going to be outlawed. The problem is that now if you want to operate a skill game, you need to apply to be a skill game (SG) operator (US$100+quarterly fee), switch or move to a SG sim (US$325/month to “own”), and buy and run only approved devices created by approved SG authors (US$100+quarterly fee).

I have a difficult time imagining that very many creators or operators will take linden up on the offer: margins are too thin and the added complexity and cost is likely to be too much for most.  I, for one, don’t see any chance that I’ll invest the money to be an approved creator – I don’t make anywhere near enough money from such games.

I suppose Linden is solving a real problem here… seems to me that they’re once again creating more problems for SL due to rather poorly considered policy changes.  We’ll see, I guess.

SL Pro!

On Thursday of last week, I had the pleasure of speaking at the 2010 SL Pro! Conference. My talk was on applying RL software development techniques to SL scripting (go HERE for my slides… Please read and comment!). But what I really want to talk about here is the process and experience of participating in this sort of real conference that takes place in a virtual venue.

The joy of suexec

So we were trying to set up a shim web script to connect a MySQL database full of data goodness to a set of LSL scripts. The python script when run from the command line in the development environment but failed utterly when the author tried deploying it to our hosted server. It turns out that there was a whole cascade of problems that may serve as a cautionary tale:

  • The database server didn’t allow connections from outside our campus, so we needed to deploy to an external machine at work instead of our public services to satisfy the need for LSL to reach the server and for the server to reach the database.
  • Check EOLs!  The script was developed on windows and then deployed to Linux – while python worked fine, ./ failed because the engine didn’t recognize the ^M as an EOL on the first line.  dos2unix fixed that. Renamed it foo.cgi and it should work
  • suexec is evil.  It intentionally obscures its settings and (probably unintentionally) emits error messages that are simply wrong.  Our webserver used the standard install, but we use .public_html as the user’s html directories instead of the more common public_html (note the dot!).  Suexec said that it couldn’t get to /home/user, whereas it really couldn’t get to /home/user/public_html.  The hack to get things working was to symlink the two together.

Presto! And suddenly things worked!  Of course, there were multiple edits of apache config along the way, restarts, searching for working user scripts, etc.

llListen/listen borked

Or rather, I suspect that the chat message queue is borked. It used to be that typing “/3” would deliver an empty string on channel 3 to whoever might be listening. No longer. Now such messages are silently dropped. Sigh. SVC-4783


I’ve been converting my sim security “cam” system from using http posts to google forms backed by a spreadsheet to a nice litlle php service writing to a mysql database. The next two interesting next steps to consider are: (1) since the detectors are LSL scripts using sensors, they have limited range and frequency… So I end up with lots of point observations of visitors without any continuity- not a problem, but sometimes I’d like to watch paths not points. So the question is should I keep this information in the database in some form or just regenerate it on the fly when I query. (2) pretty displays: tabular it trivial, but little maps and such would be cool… And not an area I know much about.

Talking with UW class tonight

The University of Washington extension has a certificate program in virtual worlds (see earlier post). Turns out that the teacher of several of the classes, Randy Hinrichs, has them using SYW as a textbook and has asked my to talk with his class tonight.

Update: I had a blast – lots of great questions and interaction.  I was scheduled for an hour and ended up talking for two.