INI Files and Associative Arrays in LSL on OpenSim

I have a dirty little secret. As much as I love building and tinkering and just plain messing around in-world, something I haven’t done nearly enough is script with LSL. It isn’t because I can’t. Although I relegated programming to a hobby years ago now, I once wrote software for a living. Picking up the basics of LSL really isn’t a challenge. The problem is that I just don’t like it. It’s… very awkward. It’s fine for a small, simple script, but once you try to do anything really large it gets unwieldy to the point where I just want to bang my head on the desk. I have a whole laundry list of things I wish LSL did better, but this post isn’t really about that. Instead it’s about one way I make my life a bit easier. Or about killing two birds with one stone.

Basically what I’ve done is created a bunch of functions that allow a scripter to create, access, and store data in the INI file format. I chose the INI format  for it’s simplicity; it’s basically just a sort of set of associative arrays with section and key/value pairs. This means that these functions aren’t just useful as a configuration tool, but also can act be used to store and manipulate data (of the simpler persuasion) more readily.

So why did I do this?

Lists suck. They suck a whole lot. I’d give my left arm for a real old fashioned array in LSL. LSL’s list implementation just does not fit well in a statically typed language, and you have to call on an army of helper functions to do nearly anything with them. Trying to store complex data in them is a hassle, particularly in this day and age when pretty much every scripting language you can shake a stick at has better data structures built-in. You’re limited to just 72 elements (at least over in SL), and you can’t nest lists within lists. It’s just weirdly primitive, and kludgy. The less said about strided lists the better. Maybe I’m spoiled, but we should be waaay past the point where this sort of labor is foisted on a scripter.

Another itch vanilla LSL does not scratch is a decent way to persist data. For  rather short snippets you can do hackish things like store data in a prim’s description and hope the user never changes it. Or you can just store your data in a script’s variables and pray it never gets reset. Anything more robust than that really requires you to invest in an external architecture that allows you to store and retrieve data from an external server via HTTP. This strikes me as somehow hostile to scripters, honestly. It’s a lot of extra effort for something that really feels like it should be built-in.

So that’s where INI formatted notecards come in. An INI file itself is pretty user friendly as these things go. It’s a venerable format that goes back at least as far as the first releases of Windows. Even a novice can wrap their head around it. It’s the default format in which OpenSimulator itself stores its configuration, making it instantly familiar to anyone who has maintained a simulator. Other software like PHP and MySQL also use INI style configuration files. The functions I created allow a scripter to create, replace, remove, look-up, and persist this data in the INI format.

Happily, OpenSim provides a way to store data that feels a lot more native. Thanks to the osMakeNotecard function, you can dump either a string or a whole list into a notecard, and then read it back later using either LSL’s normal dataserver stuff, or with OpenSim’s other notecard functions osGetNotecard, osGetNotecardLine, and osGetNumberOfNotecardLines. These functions really rock, but the trouble with them is that they all have a Very High threat level, which means they’re unlikely to be enabled in most regions for most users.  I think I can see why osGetNotecard has a High threat level, and I don’t use it in my functions. But the other two kinda confuse me. They have a VeryHigh threat level, even though they seem like they should be much safer to use. Maybe it’s because they lack the delays many LSL functions have. At any rate, because of this issue, I was forced to make sure I had a version of my functions that could operate without OSSL functions if necessary. The bummer with that version is that it can’t persist data to a notecard. It can only read it and manipulate it, and requires a seperate state to read the data.

If you’re a scripter who thinks they may find this sort of thing useful, or know a scripter who might, you can find both versions of my INI functions listed on my scripts page. Here are direct links to the OSSL version and the vanilla LSL version. I tried to provide some decent documentation for them. They’re BSD licensed, so feel free to use them however you please.

Advertisements

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s