Linden Scripting Language

Now that I'm a mighty wizard I am in a position to be able to demonstrate a couple of simple scripts for you to try.

There's nothing complicated about these scripts and they are very basic. They are both in the same vein, a landmark giver and a notecard giver. There are I'm sure more efficient and superior ways of doing this, but I'm just giving you some examples of simple scripts.

The notecard giver will give an avatar a notecard when touched. The first thing to do is to create an object, then go to the content tab and click new script. This creates a new script which defaults to the hello avatar script. Delete everything and then copy and paste the following code into the script.

default
{
touch_start(integer total_number)
{
llGiveInventory(llDetectedKey(0),llGetInventoryName(INVENTORY_NOTECARD, 0));
}
}

Click save and hopefully you get the completed message rather than a syntax error. Now place a notecard into the contents tab and voila, you're good to go. Right click your item, click touch and you should be offered the notecard.

The landmark giver is pretty much identical but you change INVENTORY_NOTECARD to INVENTORY_LANDMARK

So we have:

default
{
touch_start(integer total_number)
{
llGiveInventory(llDetectedKey(0),llGetInventoryName(INVENTORY_LANDMARK, 0));
}
}

Points to note, the code in brackets that says INVENTORY_LANDMARK, 0 tells the object to give you the first landmark (or notecard if you're using the notecard script) in the object. That's what the 0 indicates. If for some reason you wanted two notecards or landmarks in the object and you wanted the object to hand out the second one instead of the first, you'd change the 0 to a 1. { Read more }

Three times this month someone has turned round to me and said "I thought you were a girl". I don't know what to make of this!

Scrims, a word fashioned by someone on the scripters mailing list could very well be something you need to pay attention to as Linden Lab address the issue of how resources are shared on a sim. The basic concept = The more you pay, the more you get.

The plan, which is very much in its infancy so there's no need to go running to the hills, is to limit the script resources available on a parcel basis in a similar fashion to how objects are restricted by prim limits.

Well if you pay more tier, you get more resources, it sounds fair enough in theory, but there are some big but's on this. The stable door has been open for quite a while on this issue and the horse has very much bolted, so this issue needs to be handled very very carefully.

What worries me about the scripters list is that scripters talk like, well, scripters. However sometimes you need to think like your average resident, the person who buys the scripted object, takes it home and finds it won't rez because it takes them over their resource limit. How do you explain to them that they can't use that object? With prims it's easy, clearly labelled, people can work that out, but with scripts, it's not quite that straight forward.

The issues are of course well documented, that 16M parcel using a shed load of resources on a sim leaving the vast majority of the rest of the sim struggling for fair usage. It's not as if this issue doesn't need to be addressed, but it needs to be addressed with residents, not just scripters, in mind.

In terms of scripters, education, education, education. Coerce, encourage and advertise less intensive scripts. Make it good practice in every single tutorial to try and use scripts that are less resource hungry. { Read more }

This is a modification of the existing Visitor List script that some people may be using - I don't know who wrote the original, but I do know it has been making the rounds. All I have done is made the Listen a timed event, and added some functionality that allows the URL of the visitor's web profile to be reported.

I'm not 100% happy with the way it works yet, but it could be useful for some people to adapt themselves. It has survived beta testing so far, but it does need some usability work in my opinion.

To use it, copy and paste it into a script in an object. To get the list, touch it (it presently says nothing when touched), then use channel 137 ('/137') to 'say list', 'reset list' and/or 'help'.

Released under GNU GENERAL PUBLIC LICENSE Version 2 (June 1991): { Read more }

The Second Life Herald's Primjackers Trash LL's Digital Rights Management caught my eye. The title was supposed to, of course, but I've seen prim copying scripts work more than once and have never truly seen them as a threat. All they actually do is copy prims by infesting themselves in a modifiable object and copying the dimensions and relative locations of the prims - then rezzing the copies of the prims a distance away.

Lets dispel a myth. It works only on modifiable objects. Therefore, it does not break the de facto DRM of Second Life, the permissions system. People can - and have - done the same thing manually for years. And to modify something that is modifiable, guess what? You have to own it.

That, you see, is not rocket science. In fact, I'd been considering the same thing in the context of backing up builds offline and transferring them between grids - for my own builds.

Take a look at the video.

{ Read more }

I rarely simply point to another blog and say, "Look at this" - but if you're interested in LSL and/or making your own Checkers within Second Life, this post will be worth your while:

Building Second Life Checkers Game.

If you missed the official announcement, Mono Beta Launch. Unlike a lot of people, I'm not a big fan of [w:Mono (software)|Mono] - but still, I count the news as good for the now. I'll explain why it is good for the less technical folks out there.

The rumor mill - people who attend the Linden meetings and pass all those unofficial announcements around (that probably get borked somewhere) - has said that scripts should run with a 70x factor increase. In layman's terms, this means scripts in general should be able to execute faster - though I don't expect all scripts to do so because of reliance on timer events or other functions that cause scripts to wait. Still, this performance boost should mean a lot of things running faster. This is one part of getting the grid more usable for people, and in general I consider it good news. I've expressed interest in more concurrent applications on the LSL list, but most people don't really care too much about that... now.

From what made it through the rumor mill filters, it also seems that in the undisclosed date of 'the future' people may be able to code in the C# language. That isn't too bad either.

The comments on the official blog post, as usual, are a little... frustrated. But if Linden Lab can pull off Mono and the new Havok engine, there should be tangible differences on the grid for the average person. And that is coming from someone critical of Linden Lab - not some happy clappy person.

I don't have time to go play on the Beta grid, but I do encourage interested people (especially non-technical folk, I think!) to go check it out, as outlined in the official post. While I am a critic - I do want to see this work, despite my own misgivings at a technical level.

It may be. In fact, I was sort of surprised to find that my profile was on the web here. Since a lot of people may not know that this is so, I wrote a quick and dirty script that you can use to check out your own profile.

So, where is yours? Here's a simple script you can copy and paste into an object. When you save it, just touch the object and check your history for the link. Click it. Presto, your profile on the web.

default
{
    state_entry()
    {

    }

    touch_start(integer total_number)
    {
        llSay(0, "Your profile is at: http://world.secondlife.com/resident/"+(string)llDetectedKey(0));
    }
}

This demonstrates that any object you touch has the potential to display your profile information on the internet. It does this by using your avatar's unique ID - the avatar key.

Be careful where you put your fingers.