LSL Plus: the Eclipse plugin for LSL

A while ago Tiessa wrote up about the programming environment for LSL.

I've found today a possibly nice addition: LSL Plus, which is an Eclipse plugin. Dubbed as an alpha state (and since I myself do not really use the Eclipse, I did not test it out :) But if you do - give it a shot and see how it works.

On the interesting side - it actually enhances the language with a few interesting features, and cross-compiles into the "canonical LSL" when publishing the scripts to SL.

Opensim: LSL infrastructure is there!

#opensim channel log:

(23:11:02) Tedd_: I got dynamic script engine loading, LSL script compile, script loading, touch_start event and llSay() output to console working a few minutes ago
(23:11:19) Tedd_: basically... LSL script support :)
(23:11:29) dalien: whoa!! :)
(23:11:37) dalien: committed ?
(23:11:45) nixnerd: wow Tedd :)
(23:12:03) Tedd_: only we are missing -all- commands, almost all events, one common script for all objects, and don't support a few things like states just yet
(23:12:08) dalien: well,
(23:12:11) Tedd_: but that will come, now it works...
(23:12:18) dalien: those are small chunks of work but many, right ?
(23:12:25) Tedd_: commited yeah
(23:12:29) dalien: cool.
(23:12:34) dalien: and how do you make the scripts there ?
(23:12:36) Tedd_: yup, around 350+ small chunks of work
(23:12:42) dalien: given that the default object flags do not allow editing ?
(23:13:05) Tedd_: right now you can not make script because we don't have inventory
(23:13:13) dalien: right.
(23:13:14) Tedd_: so we are still waiting for a few things...

As we can see - it is a bit early right now to jump on those 350 small chunks of work :)

But it is a very good news - thanks to great work of Tedd there's a foundation for LSL in opensim.

Meanwhile, you can read Tedd's blog for the gory details and if you have some friends who are "cynical, arrogant, and non-accountable coders" (c)Prok, they might be interested.

You asked for it: lsl follow avatar script

I noticed there were a few hits on my blog with "lsl follow avatar" search terms on google. Assuming that the people are looking for a "pet" script, I thought it would be a good idea to put a reference to it - especially since it is actually on lslwiki here, search for "follow (script)" inside the page, the script is just below.

While looking for it, I found that I can kill the "lsl basic" topic - it is all too well described by a series of the articles in Dr.Dobbs journal article on using the linden scripting language. Quite a nice tutorial.

When you need to shoot the birds... pick the right cannon!

Today's post will be about... engineering, surprisingly. And a little bit about knowing the requirements upfront.

This is a story that happened back around RL's New Year's Eve, on a skate rink near the Paradize Lost. Helena was there, having fun herself and entertaining the public, and during the casual small talk she mentioned she wanted to make a snowmen contest. Which obviously implies voting.

It was a very interesting proposition - I usually do not script just for "pure money" (well, I do only if the money/time spent ratio is sufficiently high), but rather mainly for the sake of making something new and something I have not done before. Voting system I have not done by then yet.

So - the first question - "how many people are you gonna have voting?" - "don't know" - "well, 1000, 10000 or 10000 ?" - "still do not know".

Ok, I say for myself - let's take 50000.

"How many participants?" - "Not sure" - "less than 100?" - "yes".

Ok, this is something to start with. In any case, the overall design was pretty clear:

• one prim per contestant to accept the votes, and display the results
  
• some kind of validation storage, which would store the keys of the avatars who has already voted, to avoid double-voting.
  
• the contestant prims would check out with the validation storage, whether the person has already voted, and if not - then store the vote, and increase the counter for that particular prim.
  
• ideally, i would somehow be able to remember who voted for whom, and have the results auditable.
  

So, according to the requirements, I need to store some 50000 key-key pairs somewhere... (considering that an LSL script does not even get that many *bytes* of memory, it had to be something modular).

So, the first module is a "single storage script". An atomic piece, which can hold something like 100 pairs. Now, let's put ten of these into a prim - we get a storage unit, which can hold a thousand. The search is not fantastically efficient, but still...

Now we link a bunch of these "child storage units" to a single "master prim" which does the high-level "memory management" and figures which ones are full, where to search, etc.

All right. I spend something like 3 full days (there were some days off) to build this monster, and then was just about to show it, when I got invited to an event somewhere, and there was a griefer attack there.

The net result of the exercise was that I had lost all my hair. It took me a while to find back the place where I bought it, and buy another copy, but this loss of hair has prevented me from losing much more hair - when I thought about the same thing messing up my "superstorage".

Then I said "no way".

And hence a much more simple and almost as robust system was born. Indeed, I decided to use an external server. Being a little bit of a paranoid, I do not run any scripts on web server. Not at all. No exceptions. And I did not want to install mysql/php/whatnot, just for this. Besides, the machine I use is very very weak - so a theoretical spike in the requests I would not be able to handle.

So I needed another way... Ok, here we go. Create a new virtual host just for this, and write a script to continuously monitor its logfile.

The voting attempts are done via requests "/vote/voter-key-here?for-whom-to-vote" - if there is something, then the person has already voted. If not - then the HTTP server returns "file not found" and the vote can be recorded.

Needless to say, that this opens a race condition for double-voting for more than candidate during the time window when the request has been already sent, but not yet processed by the script (which monitors the requests in the logfile, and creates the file in "/vote" directory accordingly. However since it was not a military-grade application I did assume this margin of error would be OK. But actually I think I still tackled that. :-)

The files "/candidate/candidate-key-here" would contain the counters for each of the contestants, which would equal to the number of voices - and since the script that processes the votes would be single-threaded - I get rid of the concurrency issue - since the results are incremented centraly.

I do have an auditable log of all the votes - it is simply a htaccess.log - so if something messes up or I find a bug in the script - I can always just re-run it, first wiping out the files with the counters. Any surge is ok - since even my dumb server can still serve static pages reasonably fast - and any other computations I do at the pace *I* determine.

The "tail-and-count-votes" script on the server side I decided to write in Ruby - it is a pretty high-level and readable language, took around 40 minutes.

The voting prims were easy - just cut out the fat from the previous version that is not needed anymore...

So the overall result was ready in under half a day, with no significant brain strain - it was very simple.



There are a few lessons I grabbed out of this:

• It is good to plan for scalability. But sometimes it helps to consider the "natural upper bounds" more carefully.
  
• The first most obvious solution (prototype?) is not the best, but it teaches you. Make sure you can do it fast, and then proceed to "the real thing".
  
• Don't be afraid to think outside the (LSL) box.
  

After some testing and a couple of bugs fixed, the voting system ran for a few weeks. The overall number of participants was probably around couple of hundred, and seems to have worked flawlessly, I did not get any single IM with complaints.

But maybe they were just merciful :-)

DeliHUD 2-week public beta starting NOW!

In one of the previous posts I've mentioned I was coding a bit...

The alpha tests seem to have gone reasonably well, so I am opening the beast to the public beta.

What is it: it is an in-world interface to del.icio.us, to retrieve and visit the SLURLs that you would pick up on blogs and other out-of-world sources.

Setup: create a notecard with two lines - first one being your del.icio.us username, the second being your del.icio.us password, then wear the hud, and drop the notecard onto it.

The SLURLs that you want to visit from in-world should have 2 tags: "slurl" and "visit". Then they will be picked up by the HUD and shown to you.
By clicking on the text shown in the HUD, you will be offered a TP to the destination, and after you have visited the place and possibly created a LM for it, you can click on the red square next to the text to remove the "visit" tag - after which it will no longer show in the list.

Where to pick it up ? I've put a vendor next to the primskirtbuilder area (see the banner on the right side of the blog), as I was a bit lazy to tweak the script, I've put the symbolic price of L$1 to still make it function.

The beta lasts till 25th of June, after which time all the beta copies will self-destruct - and either we might have another round of beta, or if the beta proves successful and bug-free, then I start distributing it.

Please put your comments about the behaviour/functionality/etc. into the comments to this post, so we avoid any duplicate reports.

If you got an IM from a stranger and desperately want to reply..

...but the search is down... you can use the IM relay that I quickly cooked today.

it's in the primskirtbuilder area, grab the copy and follow the instructions...

Note: not all names might work, only those that are in the w-hat database.

Bit more coding...

Zoe has mentioned something interesting (and thanks a lot to Vint for pointing me to it...)

The inworld beast is currently in early alpha cycles.

Talk to me

or, the best feature of the new release.

Ok, please put your geek glasses on and we start.

The best feature of this release. No, you guessed it wrong, not sculpted prims - I just barely figured out building a cube, so for me it is still too much of a rocket science. I'll wait for someone to teach me before I can do anything meaningful with it :)

llRegionSay - that's really the killer feature.

Why ?

Okay, let's take a look at what we have at our disposal to make the scripts talk to each other.

llSay - fast, works well, but... the range is limited by a 20m sphere.

llShout - same as before, but the radius is a bit bigger.

So, what if I want to have a bigger range ?

The answer is: It's a pain. The pain (a.k.a. shooting the canaries with a nuke) can be self-inflicted in two ways:

• llEmail, and juggling with a huge delay that this incurs
  
• llHTTPRequest, deal with a an interesting throttling mechanism, and set up your own server. And poll this server from all around. This just does not scale at all...
  

Both provide unlimited range, and both come with a huge price - throttling, rate-limiting, etc.

However, with the new llRegionSay everything is very simple - just use it where you'd use the normal llShout or llSay. I went up to 4km, and was still having the communication between the two test objects working just fine. The specs claim it will work anywhere within the sim :-)

Indeed, now the crosstalk will increase, so it is important to properly filter and authenticate the messages, to ensure your script does not collide with anything else.

A canned cat...

..or, F = m * a

Why "A canned cat" ? If you do not know yet - you will know from the next post... Meantime...

Who said being caged is not fun ? Well, maybe depends by whom. :-) It's a pleasure to be caged by friends.
First, the most charming Vint tried on me the cage weapon that she had. What a great experience! Unfortunately the crashes of my SL client have ruined the nirvana bubble I was in, and it somehow disappeared.

Next was Wrath's turn. His caging gear was more peristent. A comfortable phone-booth-size box, semi-transparent (good, so I did not get too claustrophobic), which was very very kind to me and patiently waited until I login back after the crash. And it was corteously following me immediately after I try to sit on some other object that I had rezzed nearby.

Very handy thing. It is miniature - so you can stack many of these; It has a roof - so even with the new weather enhancements you can have a shelter from the rain; It follows you - so you always have it together with you.

There was one way to seemingly get rid of it which was taking my megalift script, and putting it into a sphere which surrounds both me and the cage. I tried that, however, due to limited height of the roof - it only made a lot of noise :-)

It seemed unescapable (or inescapable ? Well, impossible to escape - that's for sure). However, thinking of how gently it was following me, I found a way to part with it.

A short detour into the LSL. In order to follow the avatar, you need to know its position. Pretty much the only function to do that is llSensor and friends.

Now, we look at an interesting detail on the wiki: The limit of range is 96m. Values greater than 96m will be accepted but will be treated as 96m. (Vint: not sure where I took the value of 30m that I mentioned - must've been some other function). But at that point in time I had in mind 30m :)

So, rez a usual wooden .5x.5x.5 cube somewhere nearby. Stay in edit mode

Then:

1. Sit on it. The friendly phone booth follows.
   
2. Remember the coordinates currently shown.
   
3. Start changing one of the coordinates by small increments - due to my delusion I used 20 meter increments, but given the updated info above, a bigger value might suffice as well
   
4. The doggie-booth honestly keeps following you. All according to specs. Good job!
   
5. Once the distance from the original point is big enough (I moved away 200+ meters), set in the editor the original position that you have remembered.
   
6. The cage can not see you anymore, so now you arrive alone on your cube, safe and sound. Stand up and clean up your "saviour" cube.
   
7. Voila! :-)
   

We could not find back the cage. Wrath said he commanded it to deactivate, and never heard from it. I suspect that it simply got too upset from my evil trick of leaving it alone in the open space, with noone to admire its faithfulness, and it evaporated because of infinite sadness that only the loneliness in the middle of the black sky full of stars can cause.

Rotations and other irritations..

Ok, appears the solution to the rotation problem is simple. So simple that the only excuse for not finding it right away might be the tiredness.

Here's the code to rotate the prim around a fixed local point on it, expressed as an offset from its center in prim's local coordinates. There are far too many excess variables, I kept them just for the sake of clarity, indeed in the real implementation this would be way shorter. The below code rotates the prim 45 degrees around the Y-axis in local coordinates, around the point in the center of its Z-coordinate top.

// how much to rotate per iteration (in degrees).
integer rotateAngle = 45;

// current rotation of the prim.
rotation rot = llGetRot();

// "size" of the prim.
vector scale = llGetScale(); 

// offset of the rotation point in prim's local coordinates.
// (center of the top in this case). 
vector offset = <0, 0, scale.z/2>;

// "delta" rotation expressed as a vector in radians.
vector euler = <0, -1*rotateAngle*DEG_TO_RAD, 0>; 

// "delta" rotation expressed as a rotation.
rotation deltarot = llEuler2Rot(euler); 

// new rotation for the prim after applying the "delta" rotation.
rotation newrot = deltarot * rot; 

// current offset of the rotation point vs. the prim center.
// now expressed in global coordinates.
vector vvv =  offset * rot;    

// new offset of the rotation point vs. the prim center. 
// expressed in global coordinates.    
vector vvv2 = offset * newrot; 

// current position of the prim.        
vector currentPos = llGetPos();

// current rotation point, not needed except for visualization.
//vector rotPoint = llGetPos() + vvv; 

// new position for the prim.
// it is different from the current position. 
// by the difference of the rotation points offsets.
vector newPos = currentPos + (vvv - vvv2); 

// visualize the rotation point if needed.       
//llRezObject("ball", rotPoint, ZERO_VECTOR, ZERO_ROTATION, 0);         
        
// set the new position and rotation for the prim.
llSetPos(newPos); 
llSetRot(newrot); 

p.s. very nice, ths template seems to mess up the formatting.. If you copypaste - either do it from "view source" or manually fix the comment lines - i end each of them with a dot. (I know, I should've fixed the template for the blog instead, but i am lazy :)