Idea: a new event in LSL, error, which would allow scripts to intercept and deal with error messages in a sane and consistent manner. Here’s an example:

default
{
    state_entry()
    {
        integer a = 1/0;
    }

    error( integer type, string message )
    {
        if( type == ERROR_MATH )
        {
            llOwnerSay( message + "You should have paid more attention in math class." );
        }
    }
}

The two parameters for the error event are the type, which is one of a selection of integer constants, and the message, which is a human-readable message describing what went wrong. In this case, the type is ERROR_MATH (indicating a math error), and the message would be something like “Error: Division by zero.”. The output from this script would be a message to the owner, “Error: Division by zero. You should have paid more attention in math class.”

Some more useful (and less insulting) ways of handling errors might be to reset the script, send an IM to an assistant shopkeep, clearing some buffers to free up memory, giving a custom message on chat, or some other appropriate behavior for that particular application. If the script doesn’t define the event block, errors are reported in the default way, as they are now (e.g. shouting the error on the debug channel).

To complement the new error event, would be a new function for triggering errors: llError( integer type, string message ). When called, it triggers an error of the given type, using the given message. If an error event block is defined, the error is given to that block to be handled; if there’s no block, it’s handled in the default manner for that event type.

A second new function would be llNoHandleError, which behaves like llError, except that it always performs the default handling, bypassing the error event block if it exists. This could also be used within the error event block to “pass through” event types that it’s not intended to handle.

So, scripters: give me some feedback on this. Should we make a JIRA for this, or is it actually a really stupid idea?

Scripters, being naturally clever folk, have instead relied on the fact that you can change an object’s name and description. So, just save the settings/data to the object’s description, and it’ll be there the next time the script runs! This was especially handy because the servers have previously allowed much longer descriptions to be saved than they were supposed to.

Of course, anyone who has been following the Linden Blog should now be aware that the name/description size limits will now be enforced. I won’t say much about that, except to note that this is another instance of “Very useful exploit-turned-essential-tool that occasionally caused problems, so the Lindens removed the tool rather than fixed the problems”. See also: Megaprims.

What I’m more interested in right now, is the excuses the Lindens give about why we’re not allowed to write to notecards. For example, Prospero Linden wrote:

Re: storing persistent data : the way the asset sever works, a UUID is a unique identifier to an asset. If you change anything, it has to be a new asset– because if somebody else, say, had the same notecard before it was changed, you don’t want your edits to go to this other person’s notecard. It can happen that different people with the same object in their inventory in fact just point to the same UUID in the asset server. If you were to be able to write to a notecard from the script, *every* write command would create a new asset, which would create a load of additional problems.

I call bullshit.

Assuming the technical description is accurate, it follows that every time you edit a notecard by hand, you must already be creating a new asset. Otherwise, as Prospero pointed out, giving a friend a notecard and then editing your own version of that notecard, would also change your friend’s version. (Which might be cool for collaborative efforts, but would otherwise be annoying.)

New notecard assets are already being created ’round the clock as Residents write to-do lists, notes for a friend whose IMs get capped, configurations for notecard-reading scripts, and so on. In the time it took me to write that last sentence, I would guess that at least 20 new notecard assets have been created in SL, not to mention scripts, clothing, and more.

Sure, the asset server has plenty of problems already, but why does Prospero think notecard-writing scripts would lead to additional ones?

Perhaps he’s worried about the sheer volume of notecard-writes that could occur. Scripts could, presumably, work a lot faster than Residents can. A griefer could perform a Denial-of-Service attack on the asset servers, by sending out self-replicating, notecard-writing objects that would create hundreds of new notecards every second! Egads!

Well here’s a thought: Put a delay on it.

You know why people don’t use SL scripts to send out massive amounts of spam email, despite the presence of an llEmail command? Because every call to llEmail pauses the script for 20 full seconds. Rather annoying if you have a legitimate reason to send emails from a script, but nonetheless an effective way of discouraging abuse.

Even a notecard-writing function with a 60 second delay would be infinitely more useful than having nothing.

And that’s all assuming Prospero (and other Lindens who have made similar statements) are right about how notecard-writing works. It seems like a rather silly system, of course, but it certainly wouldn’t be the first silly system to come out of Linden Lab. A more sensible system would, one might think, involve making a new asset only when one was required — that is, when a new or copied asset is created.

Such a natural and obvious solution would also eliminate any reason for the notecard-writing function to create a new asset every time it’s used. The prim with the script in it would already have a notecard; when that notecard was copied to the prim, a new asset would be created one time. All subsequent writes to that notecard would modify the same asset. If you wanted to copy the notecard out of the prim, that would create one more asset. It’s really quite simple!

On the other hand, it wouldn’t be as useful for testing if it’s actually possible to run out of these so-called “Universally Unique IDs”. ;)