• 25Mar

    The problem: runtime error handling in LSL is… well, it’s practically nonexistant. If something goes wrong, the script will usually shout some message to the world and then die. The obvious problem there is that you have to then manually restart the script and lose all data! Also, for the security-concious, it can potentially reveal implementation details of your script.

    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:

            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?


  • 07Feb

    Tired of *click-whirrrr*-ing your way through Second Life?


    Help is here! Vote for VWR-2448 TO-DAY!

    This message brought to you by the Ad Council for the Egregious Use of Bolding.


  • 01Feb

    Scripters (myself included) have long bemoaned the lack of any way to write text to a notecard. You can read text from a notecard (although it’s a PITA due to LL’s non-blocking dataserver lookup; and it’s also apparently not possible with notecards that have any embedded inventory items like landmarks), but there’s no way to write to it. That means you can’t save script settings or data to a notecard so that they persist between script resets.

    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.

    Continue reading »


  • 10Jul

    Ever wanted to make an androgynous/intersexed/nonsexed avatar? Perhaps a robot, or an alien, or just a plain old tomboyish girl or slightish guy?

    There’s no good reason why the Male/Female avatar control has to be an either-or affair. It’s the same base mesh in both cases, so we could morph between the two shapes in the same way that all the other avatar sliders morph between two (or more) variations.

    The one technical issue that would need to be resolved is certain “sex-specific” sliders: the breast size, gravity, and cleavage sliders for women, and the discreetly-labeled “package size” for men. The simplest solution would be to hide/show them based on which half of the “gender spectrum” the avatar is on. A better solution, i.e. one which offers more choice to the user, would be to always show all the sliders, regardless of the sex of the avatar. (Plus, I bet the newbies would get a kick out of making brawny men with thick beards and voluptuous breasts, as their first adventure on Orientation Island.)

    The best solution, of course, would be to forego having male and female base shapes at all, and instead define a selection of qualities of the body which contribute to someone appearing masculine or feminine. (Of course, there would be “Man” and “Woman” presets, for users who don’t want to spend a week getting their avatar just right.) But it’s too late for that, unless we were to scrap the current generation of avatars and start over—a worthwhile but substantial endeavor; the type of endeavor that people are given jobs and paid salaries to do.

  • 08Jul

    What I want to do:

    Bind the rotation channel of an object to a sinusoidal wave function for smooth, client-side swinging/rocking motion.

    Some cool stuff you could make with driven rotation:

    • A swinging hammock.
    • A rocking chair for granny.
    • A weeble that wobbles but never falls down.
    • A chintzy Felix the Cat clock with pendulum tail and moving eyes.
    • A Gothic church bell that swings convincingly.
    • A tree branch that seems to move in the breeze.
    • A boat that seems to gently rock and sway in the water.
    • A bird that flaps its wings convincingly.

    Other cool stuff you could do with generalized algorithm-driven attributes:

    • A prim that “breathes” in and out (slowly grows/shrinks).
    • A prim that moves in a circle, ellipse, figure-8, etc.
    • A torus that pulses and grows over time.
    • A carousel that goes ’round and ’round, while the horsies go up and down.
    • A flexi clump of seaweed that waves side-to-side hypnotically.
    • A glowstick that smoothly changes color in time to music.
    • A flower bud that slowly opens and becomes vivdly colored to greet the sun.


    • Motion is client-side only; collision detection won’t work in the expected way. This is already the case with rotation set on a nonphysical object using llTargetOmega.
    • Server-side bindings could exist in the future. They would be updated relatively infrequently (only a few times per second), while client-side interpolation keeps it looking smooth.


    llDriveAttribute( [attribute, algorithm, parameter1, ..., parameterN, ...] )

    This interface is future-proof: new attributes, algorithms, and parameters could be added later, without breaking existing content.
    Note that multiple parameter sets can be chained together for one function call, similar to llSetPrimParameters or llParticleSystem.

    Implementation notes:

    • Select from a set of pre-defined algorithms which take parameters for tweaking. Proposed initial set:
      • SIN_WAVE: Sinusoidal wave. Parameters: duration, amplitude, value offset, period, phase shift.
      • TRI_WAVE: Triangle wave. Parameters: ibid.
      • SAW_WAVE: Sawtooth wave. Parameters: ibid.
      • LINEAR: Constant change. Parameters: duration, slope, value offset
    • Regarding “duration” parameter: Motion stops after this many seconds. Can be non-integer (float). Can be FOREVER (-1.0). Can be STOP_NOW (0.0).
    • Parameters are sent to the client with the time that it started. This allows all viewers to remain in sync, even viewers who arrive after it has started. All algorithms are parametric (based on real-time); the algorithm can be evaluated at any point in time, without needing to evaluate earlier points in time to ‘catch up’.
    • A one-time synchronization between the sim clock and the client clock would be necessary to properly know how much to adjust the current time when evaluating the algorithms.
  • 05Jul

    I can has Communicate? So I was reading Torley’s post about bug reporting, following the links and having a grand old time, when I noticed something I’ve never seen before

    Hey, what’s this?! I quetly thought to myself (and shouted aloud, startling my cat).

    After some preliminary investigation (i.e. looking at the picture), I deduced that this is none other than Uiwindowus communicatus, commonly known as the Communicate Window, in its only known natural habitat: the First Look client.

    Many of you probably know that Linux users won’t be chatting it up with voice any time soon. I don’t mind that so much, but I sure hope we get our pengi flippers on this sexay Communicate window! I lurve me some new UI floaters!


  • 28Apr

    Tateru Nino: You know what the edit window needs? A prim alignment function.
    Tateru Nino: Select a bunch of prims, select align on [X|Y|Z] axis, and let them snap together.


Recent Comments

  • The feet and hand control bones can be used for inverse kine...
  • thanks! It's woahking! However I have a problem...someho...
  • it is very nice.i can easly understood for animation work.th...
  • I just want to thank you very much!...
  • Sorry, the exporter only works with Blender 2.49 and earlier...