LSL Wiki : KnownBugs

Known Bugs

LSL has several known bugs. When adding bugs to this list, please indicate the SL version number and the date it was observed. Bugs are often confused with annoyances, so before posting here try to see if the "bug" fits the criteria of an annoyance first.

Only the last jump to a label actually gets executed.

jump end;
llOwnerSay("hi");
jump end;
llOwnerSay("hi again");
jump end;
llOwnerSay("help i need somebody");
@end;

Still true in 1.10.3, 18-June-2006. --RobDemar
Second that, still true in 1.18.2.0 09-Semptember-2007 (A year later). --JaykobCarter
Still broken if script is compiled as LSL, but seems work in Mono. 19-July-2009. --AtteAderdeen

llGetFreeMemory returns historic free memory, not current

llGetFreeMemory is supposed to return the current free memory, however, it doesn't. It only ever returns the minimum free memory up until that point, even if the script has since freed it. Needless to say, this makes using it somewhat difficult.
Workaround: None.

llSetScale function blocked by llSetPos

For an unknown reason, if child prims in a link set call llSetScale after llSetPos is called in the root, the prims will not scale. This bug can be repeated more easily by calling llSetScale roughly at the same time llSetPos is called.

Must Interleave multiple textures and colors in the same llSetPrimitiveParams call (1.10.1)
If you create a list with different PRIM_TEXTUREs for each side, then a list with different PRIM_COLORs for each side, concatenate them and feed them to llSetPrimitiveParams, you will get the last defined PRIM_COLOR on all sides. The same goes for the other way round, where you will get the last PRIM_TEXTURE on all sides.
Workaround: Make sure you interleave (define both color and texture) for each side in the list.

Mouselook bank and steer don't work with decoupled camera until sim crossing

If a vehicle has the flags VEHICLE_FLAG_CAMERA_DECOUPLED and VEHICLE_FLAG_MOUSELOOK_STEER or VEHICLE_FLAG_MOUSELOOK_BANK, the camera won't actually be decoupled until the vehicle crosses a sim border. After that it works correctly.

Andrew Linden has acknowledged this problem in SL 1.4.5.

This has been fixed since, has it not?
Note: Sorta. If the vehicle is set decoupled and mouselook steering before crossing a sim border, you're gold. If you cross a sim border, then turn on mouselook steering and decouple the camera, you have to cross a sim border again to decouple the camera.

Scripts given with llGiveInventory has to be recompiled before they can run (1.10.1)
After giving scripts with llGiveInventory you can't start the script with the menu Tools|Set Scripts to running in selection. You have to Tools|Recompile scripts in selection first.

Physical objects such as vehicles lose their physical status after a sim crossing

This can happen because the the physics engine (Havok) may detect that a vehicle crossing a sim may arrive in an interpenetrated state, and unsets the object's physical status.

Workaround:
Have a timer that checks physical status:

llSetTimerEvent(2); // Somewhere appropriate to the script.

timer()
{
    if ( !llGetStatus(STATUS_PHYSICS) )
    {
        llSetPos(llGetPos+<0.0, 0.0, 1.0>);
        llSetStatus(STATUS_PHYSICS, TRUE);
    }
}

llGetScriptName does not work on duplicated scripts

If you have multiple copies of the same script in an object differentiated solely by name, llGetScriptName() will not reflect the different names.

Workaround: Edit the scripts so that each is unique. Differentiated by an unused global constant is sufficient.
Be careful with this. I was playing with this the other day and the problem I think is deeper than just llGetScriptName(), which I think is just one symptom of weird happenings when you drag a copy of the same script onto one object twice. Just a warning to be careful. :) -- Ama Omega
Hmm. I don't believe this is true anymore; it must have been fixed at some point. I use multiple copies of the same script in many places, and depend on llGetScriptName returning the name accurately (so I can parse the digit at the end). This has never failed. -- GaiusGoodliffe
The UUID of each script is the same when you use multiple copies, this still remains and may have been the cause of the original problem. But llGetScriptName() now returns the each name correctly. -- Harleen Gretzky

llResetOtherScript doesn't work on crashed scripts

Resetting a script that has encountered a runtime error (such as one that has experienced a stack/heap collision) with llResetOtherScript does nothing.

Functions that cause damped motion called inside attachments screw up the avatar
If a function that causes damped motion is called within an attachment, the avatar will "sink" to about knee-level below the ground/prim-based platform until the avatar teleports, relogs, or sits on an object. In this sunken state, the avatar looks as if its legs are broken.

Workaround: Sit on a prim and stand up. The avatar's legs should be fixed -- at least temporarily.

The timer reported by llGetTime resets on sim crossings

The timer used by llGetTime() is reset on sim crossings/object reinstantiations.

Workaround: Don't rely on llGetTime for objects that cross sims. Use llGetWallclock and llGetDate to determine the time. Also note that llGetDate returns a UTC date and llGetWallclock returns PST seconds since midnight. (e.g.: Dateline is at 1600 PST!) Note, however, this timer is not as precise as llGetTime.

This isnt a bug, since internally, when crossing a simulator border, avatars and objects are quickly derezzed on the departing side, and rerezzed on the destination side.
No, what you are describing is the likely cause of the bug. While there is an explanation for why it exists, it is still a bug. This behavior has been bug-reported, and accepted as a bug. The on_rez event is not invoked during sim-crossings, which would indicate that that your explanation is not consistent with the intended behaviour of llGetTime. Moreover, this bug was introduced by a revision of SL. This behavior is not consistent with previous versions.
According to the llGetTime page this value is server-specific and therefore per definition cannot be relied on for monotonous results in the first place. Isn't this a case of RTFM rather than of a bug?:)

sensor events received after llSensorRemove contain wrong llDetected* data.

When a very fast sensor interval is defined using llSensorRepeat, and llSensorRemove is called, it seems that sensor events that have been queued fail to dequeue. I've not experienced more then one erronious sensor event execution at a time though. When the erronious sensor event is executed, values from the llDetected* functions no longer make sense. I believe they are set to their "zero" values.

Example of the error-inducing code:

vector objectPos;
default {
    state_entry() {
        llSensorRepeat("SomeObject", NULL_KEY, ACTIVE|PASSIVE, 96, TWO_PI, 0.1);
    }
    sensor(integer detectedNumber) {
        vector objectPos = llDetectedPos(0);
    }
    changed(integer change) {
        if (change & CHANGED_LINK) {
            if (llAvatarOnSitTarget() == NULL_KEY) {
                llSensorRemove();
            }
        }
    }
}

Workaround:
Create a global variable set to TRUE when llSensor or llSensorRepeat is called, and FALSE when llSensorRemove is called. Then, check that the global is TRUE when inside the sensor event.

integer isSensorEnabled = FALSE;
vector objectPos;

// Convenience functions to assist in managing the sensor global variable:
LLSensor(string name, key id, integer type, float range, float arc) {
    isSensorEnabled = TRUE;
    llSensor(name, id, type, range, arc);
}

LLSensorRepeat(string name, key id, integer type, float range, float arc, float interval) {
    isSensorEnabled = TRUE;
    llSensorRepeat(name, id, type, range, arc, interval);
}

LLSensorRemove() {
    isSensorEnabled = FALSE;
    llSensorRemove();
}

default {
    state_entry() {
        LLSensorRepeat("SomeObject", NULL_KEY, ACTIVE|PASSIVE, 96, TWO_PI, 0.1);
    }
    sensor(integer detectedNumber) {
        // Kill the function if sensors aren't abled (event is eronnious).
        if (!isSensorEnabled) return;
        
        vector objectPos = llDetectedPos(0);
    }
    changed(integer change) {
        if (change & CHANGED_LINK) {
            if (llAvatarOnSitTarget() == NULL_KEY) {
                LLSensorRemove();
            }
        }
    }
}

Objects set phantom using llVolumeDetect fall through the ground.

Unlike objects set phantom using llSetStatus(STATUS_PHANTOM, TRUE), object set to phantom using llVolumeDetect(TRUE) will fall through the ground.

Workaround: Make sure prims using llVolumeDetect are never physical or use llSetBuoyancy to set the buoyancy of the object.

llList2Vector and llList2Rot return zero-values instead of typecasting when retrieving a list element that is not already a vector or rotation.

list myList = ["<1, 2, 3>", "<4, 5, 6, 7>"];
llList2Vector(myList, 0); // Returns ZERO_VECTOR (<0, 0, 0>)
llList2Rot(myList, 1); // Returns ZERO_ROTATION (<0, 0, 0, 1>)

This behavior is not consistant with the behavior of llList2String, llList2Float, and llList2Integer, which properly typecast the requested element when it is not the type they return.

Workaround:
Extract all list elements as strings, then manually typecast to the desired type.

// Instead of using:
llList2Rot(myList, 1);
// Use:
(rotation) llList2String(myList, 1);

I whenever scripting always use (turning var) llList2String(myList, 1); I've got myself into this habbit just for that reason, Thanks for posting it!. -KageshenKirax

Compiler loses ability to type-check return values in function's conditional statements.

Conditional statements within functions throw off the compiler's ability to discern if the value passed back from the function is valid or not. Things like this compile:

string myFunction() {
    if (TRUE) {
        return;
    }
    return "HelloWorld";
}

The virtual machine will return a null (zero) value to the caller when it encounters the return;. In this particular case, since strings and lists are allocated within the script's heap, rather then its stack, and myFunction returns a string, it will raise a bounds check error.

Stuff like this makes the state-change-within-functon hack possible. :)

If one phrase (variable name, value, etc.) in a script is longer than 16384 characters, compilation will crash the client.

Lindens have other things to do with their time than to fix this esoteric bug...
It's still a bug, it should be fixed, even if it has low priority. -Malarthi Behemoth
Fixing it would require a) allocating more memory for the tokenizer or b) rewriting the tokenizer. -BW
LL has Mono in the works, so re-writing the tokenizer's already happening, try to keep your token smaller than a script heap and you should live till then. - Ice
Dooh! Once they fix this 'bug' - shall I raise a new one that a variable name longer then 1Gb causes the client to crash? - BS

llMoveToTarget on sitting avatar splits avatar and agent
Using llMoveToTarget on an avatar that is sitting on the ground will cause them to be "split in two", with the avatar at one spot, and the agent at the other.

Could anyone explain this in detail for me please? - Christophe003 Carter
Look up Agent and Avatar in lslwiki ... they have different functions (the Avatar is the visible 'skin', the Agent has the name tag attached to it) doing the above makes Agent follow the camera while the visible Avatar sits on the ground. This might be no longer possible in Havok 4 BS

Rapid key presses or clicks can be missed by the client and interepretted as a single key or click event.

Quick sequences of two keys can also be indicated incorrectly (key missed), though it's not as frequent. This behavior was witnessed with v1.8.1 on Jan 23, 2006.

This script can be used to demonstrate the issue:

// control bug // ready jack // 23 jan 2006 // v0.2

// There seems to be and issue detecting quick taps and double clicks.
// This script is an attempt to demonstrate and narrow down the issue.
            
default {
    state_entry() {
        llRequestPermissions(llGetOwner(), PERMISSION_TAKE_CONTROLS);
    }
    
    touch(integer count) {
        llRequestPermissions(llGetOwner(), PERMISSION_TAKE_CONTROLS);
    }

    run_time_permissions(integer perms) {
        integer desired_controls = CONTROL_FWD | CONTROL_LBUTTON | CONTROL_UP;
                
        if (perms & PERMISSION_TAKE_CONTROLS) {
            llTakeControls(desired_controls, 1, 0);
        }
    }

    control(key id, integer down, integer new) {
        integer pressed = down & new;
        integer held = down & ~new;
        integer released = ~down & new;
        
        llOwnerSay((string) pressed + "." 
                + (string) held + "." 
                + (string) released);

        if (pressed & CONTROL_LBUTTON) llOwnerSay("click");
        if (pressed & CONTROL_UP) llOwnerSay("up");
        if (pressed & CONTROL_FWD) llOwnerSay("forward");
    }
}

We'd like to always see output for two presses of the forward button like this:

control example: 1.0.0
control example: forward
control example: 0.0.1
control example: 1.0.0
control example: forward
control example: 0.1.0
control example: 0.1.0
control example: 0.0.1

Unfortunately often as not when pressing quickly we'll see something like this:

control example: 1.0.0
control example: forward
control example: 0.1.0
control example: 0.1.0
control example: 0.1.0
control example: 0.1.0
control example: 0.0.1

Notice that it tends to have more held events. Seems that the client is simply missing the intervening release and press.

The same situation goes for mouse clicks.

For action oriented development this is a pretty lame situation. Seems like not screwing up user input would be a high priority for any software period. If a lousy application like MS Word can get double clicks right, SL should be able to. So I work hard on a project and the whole effort suffers because users get frustrated that the moves they try work inconsistently. At first I thought is was my logic, but after further exploration I find that the raw data coming into the control() function is bad. And users don't know any better so their gut instinct about the project is that it's poorly done and the whole effort is put in a bad light.

Physics for scripts in attachments are disabled after re-compile or adding the script from inventory.

Not sure when this started. I'd guess 1.8 range is reasonable to assume. But if you have an attachment that does dynamic operations involving physics the call will execute but nothing will happen. This state occurs for newly added scripts or scripts that are compiled in place. The condition can be corrected by re-attaching the scripted object.

Affected functions identified so far:

llMoveToTarget
llSetBuoyancy
llSetForce
llApplyImpulse

And possibly any other kinetic function.

Also, it seems that kinetic functions inside non-root prims in attachments are non-functional regardless. Not sure if this is new but I don't remember it being like that. Only tested briefly, so confirmation would be appreciated.

You can also workaround this problem by sitting on an object and then standing back up after recompilation.

False release/press events generated for CONTROL_LEFT and CONTROL_RIGHT. Found in 1.8.3 on Feb, 23 2006.

When capturing the CONTROL_LEFT and CONTROL_RIGHT controls extra false release and press events are generated when holding those keys down. This occurs in normal and mouselook modes. The other controls behave correctly.

The following script may be used to demonstrate the bug:

// control left right bug // ready jack // 23 feb 2006 // v0.2

default {
    state_entry() {
        llRequestPermissions(llGetOwner(), PERMISSION_TAKE_CONTROLS); 
    }
    
    run_time_permissions(integer perm) {
        if (perm & PERMISSION_TAKE_CONTROLS) {
            llTakeControls(CONTROL_ROT_LEFT | CONTROL_LEFT, TRUE, TRUE);
        }
    }
    
    control(key id, integer down, integer new) {
        if (down & new & CONTROL_ROT_LEFT) llOwnerSay("rot_left press");
        if (down & new & CONTROL_LEFT) llOwnerSay("left press");
        if (~down & new & CONTROL_ROT_LEFT) llOwnerSay("rot_left release");
        if (~down & new & CONTROL_LEFT) llOwnerSay("left release");
    }
}

For the unaffected controls doing a short press and hold will generate output like this:

Object: rot_left press
Object: rot_left release

The press appears when the key is pressed and the release appears when you release the key as expected.

A single press-hold-release strafing left or right will usually generate extra events like so:

Object: left press
Object: left release
Object: left press
Object: left release

The first two appear almost immediately and then it pauses on the second press while you hold the key and then the release is generated.

Needless to say this is extremely annoying for any sort of precision tap vs. hold detection :-(

This should be fixed as of 1.17.1 or so. See Jira issue VWR-287 --Ryozu Kojima

Stopping rotation with llTargetOmega(..., 0, ...) doesn't work reliably

When rotating an object with llTargetOmega(<0,0,1>, PI, 1) or similar, it is not reliably possible to stop it again by setting the rotation speed to 0. Setting it to a number very close to 0, e.g. 0.00000001 does work however.

Annoyances