• 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.


  • 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.

  • 10Jul
    Feature Ideas, Gripes, Interface Comments Off

    Do. Not. WANT.

    After hearing accounts from people who have been able to do more than just look at a screenshot, I’ve realized that I was wrong: the Communicate window is not sexay. It’s an abomination, a Frankenstein’s Creature of communication methods!

    Ok, ok, maybe that’s being a bit dramatic, but it seems that the reality of it isn’t up to par with the glowing possibilities in my ever-optimistic imagination!

    “Do. Not. WANT.” was too good to pass up, but my view is more accurately represented by the following lollisms: “Your Communicate XML. Please to show me it.” and “OH HAI I’z just fixin ur UIz.”

    (I just hope they don’t make it too hard for us to revert to the old UI. Toggle buttonz plz kthxbai.)


  • 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!


  • 25Jun

    “Edit Linked Parts” Menu Item (new in!)

    You might notice a new entry in the Tools menu for SL Edit Linked Parts!

    That’s right, the feature I added back in March and submitted to the JIRA has now made its way into the official client release! The menu item works just like the checkbox in the Build/Edit floater, allowing you to switch between editing whole linked sets of prims, or editing the individual members.

    Not good enough? You want more?

    Well then how about I tell you guys how you can add your very own keyboard shortcut… in just 3 easy steps?

    1. Open the Second Life/skins/xui/en-us/menu_viewer.xml file in your favorite text or XML editor.
    2. Go down to line 695 (or do a search for “Edit Linked Parts”) where it says shortcut="", and type in your shortcut between the quotation marks! For example, to bind it to Shift-L, you’d type in shift|L!
    3. (Re)start Second Life, and enjoy!

    A word about the format for shortcuts: Put the modifier keys first, separated by the pipe character, | (Shift-Backslash, above the Enter key). The standard order for modifiers is control|alt|shift, but I’m not sure the order matters too much. For Macs, “control” means the Command key.


  • 22May

    I am definitely looking forward to this.

    I hope weather is next! I wants to build snow chibis in SL while flurries fall down on my head. Please don’t rain* on my parade, Linden Lab!

    *obligatory weather pun
  • 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.

  • 27Apr
    Building, Feature Ideas Comments Off

    The sexiest SL feature of 2007 award goes to… sculpted prims. The lion’s share of the glory for this one apparently goes to Qarl Linden. Will Torus have to give up its tiara and “Most Versatile Prim Type” sash? Only time will tell.

« Previous Entries   

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...