Week 2 UW Scripts
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.
Musing on the texture cache… This is largelyÂ in reference to VWR-9509, from a comment I was going to add but ended up using below.
Babbage just said “As of 10 minutes ago, Mono scripts now rez in 100 us instead of 15 ms on my development sim. I will try to get the fix deployed as soon as possible.” This is a really really good thing, as this bug is likely one of the major culprits to why SL has seemed so darn jerky and laggy since shortly after Mono was deployed (29 August 2008).Â The problem has been tracked at http://jira.secondlife.com/browse/SVC-3895 if you are interested in the gory details.
I had an interesting little email chat with an SL content creator the other day on how to make tall avatars for Na’vi, the indigenous people in the movie Avatar. They are described as being around 3 meters tall. When you accommodate SL’s height inflation (due to an unusually tall set of defaults), I’d want something in the range of 11-14 SL feet. This is well outside the range available using appearance sliders. Worse yet, the usual techniques for making Macros (giant avatars) requires using prims to hide the avatar distortions caused by the animations needed.
I’ve been reading the texture cache code for the last week or so, and I see something that I don’t quite understand – looks like a bug to me, but I’m no expert on this code so I’m not comfortable enough to generate a jira entry:
On Friday, I had the occasion (read emergency as a result of miscommunication) to make two 5 minute machinema demos of existing content.Â The good news is that the build was done, the avatar(s) outfitted, and a rough script was already in place.Â Oh, and they didn’t need audio.
End-to-end took about 2.5 hours.Â The absolutely critical non-standard bits were Camtasia (for capture, edit, and production) and a 3DConnexion SpaceNavigator to run the flycam.Â I needed a bit more free space on disk, too, so I copied raw footage off disk when I wasn’t working on it.
Lessons: you can’t have too detailed a script! rendering takes more time and you’ll need more disk space than you might think.
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 foo.py worked fine, ./foo.py failed because the engine didn’t recognize the ^M as an EOL on the first line.Â dos2unix foo.py 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.
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