Okay, back in Second Life! And/or OpenSim.
A purely Scripting-geekery post today, on a really niche topic.
When you get one of those blue dropdowns (or pop-ups, or drop-ins, depending on your viewer) with a number (up to twelve!) of buttons in them (when you touch a danceball for instance and it asks you what dance you want to do), the piece of LSL (Liden Scripting Language) that shows you that thing with those buttons is a built-in function called “llDialog“.
(All of the built-in functions start with “ll” which presumably stands for “Linden Lab”, but which has made many beginning LSL scripters, including Yers Truly, wonder how an identifier can start with eleven at all.)
One of the arguments to llDialog is, naturally enough, a list of the strings to put on the buttons. And the order in which the strings are copied from the list onto the buttons is… perhaps counterintuitive. For instance, if the list looks like:
[ "one", "two", "three", "four" ]
then the dialog as displayed will look like:
which might not be the first thing one would have guessed.
It basically starts at the bottom, filling rows upward as it goes, until it runs out of strings.
I have sometimes fiddled around to make things come out how I want them to manually, and more often have ignored the problem entirely and just not cared that the buttons were in a stupid order.
But for some reason today I got tired of it and decided to fix it; so here:
list arrange(list l) {
list outl = [];
integer n = llGetListLength(l);
do {
if (n<3) return outl + l;
n = n - 3;
outl = outl + llList2List(l, -3, -1);
if (n==0) return outl;
l = llList2List(l, 0, -4);
} while (TRUE);
return []; // UNREACHABLE
}
This will take a list in an order, and return a list in a different order such that if you pass the new list to llDialog, the labels on the buttons will be in the order that one might expect, left to right and up to down. As in for instance:
llDialog(avatar_id, prompt, arrange(button_list), channel);
It basically just divides the input list into pieces of size three, and then reverses them, with complications in case the input list isn’t equally divisible by three. And because if you ask LSL to copy the first through fourth-to-last (inclusive) elements of a three-element list, it silently copies the entire list rather than (as one might have expected) copying nothing. And because it doesn’t realize that a “do while(TRUE)” will never exit and without the unreachable line you get an error saying that not all code paths return a value. And because llGetListLength is said to be computationally expensive. And because LSL does let you use negative indices (roughly) on lists!
This works in both Second Life and OpenSim, because the scripting languages are extremely compatible for obvious reasons.
Many, many, implementations of this same algorithm no doubt exist all over the place :) but this is mine, for the moment and for what it’s worth!
Filed under: Other worlds, scripting, Second Life | Tagged: geekery, llDialog, lsl, OpenSim, scripting, Second Life, secondlife | 2 Comments »
Dale Innis's Weblog 