Don't click here unless you want to be banned.

LSL Wiki : Annoyances

HomePage :: PageIndex :: RecentChanges :: RecentlyCommented :: UserSettings :: You are

Annoyances & Gotchas

Annoyances aren't technically bugs, but are often confused with them. Annoyances can result in unexpected script behavior, but are the result of intentional design decisions on the part of the SL developers.

IconSerpentine see your user page for answer on recursion.

There is no way to rotate an avatar using a script.

llPointAt and llStopPointAt have been deprecated since mid-beta without replacements. As of now, there exists no way to rotate an avatar using a script; llApplyRotationalImpulse, llRotLookAt, and llLookAt called from within an attachment do nothing, and llPushObject has no effect on an avatar's rotation.

Comparing lists for equivalence using the == operator solely compares list's lengths.

When two lists are compared with ==, like this:
["A"] == ["B"]
The operation returns TRUE if both list's lengths are equal, reguardless of the list's contents.
Hence, the above returns TRUE.
You must use a UserDefinedFunction to compare two lists for equivelance.
integer listsEqual(list src, list test) {
    return (llGetListLength(src) == llGetListLength(test)
        && (llListFindList(src, test) == 0 || src == []));

llGiveMoney returns no message if the owner has insufficient funds.

If the script attempts to pay out more money than the owner has available, the user will see an error message, but the script itself will not get any kind of response. As KellyLinden explains: "It is not possible for llGiveMoney to return a meaningful value, the data is simply not available when and where it would be needed to make that happen."

Persistence of some scripted behaviours

Like position, rotation, size, colour, and texture, particles and sit targets are properties of prims, not scripts. Thus, if a script sets a particle system or sit target on a prim, then that script is deleted from the object's inventory, the particles or sit target remain. (The astute reader will note that the ability to have sit targets and particles without a script could be considered more a possible hack than an annoyance.)

Sensors only return 16 closest objects

If more than 16 objects are sensed, the result may seem unreliable.

Teleporting changes key of attachments

This isn't technically a bug, but it CAN be annoying for scripts that communicate with the outside.
Your best bet might be to use a redirect script in a stationary object somewhere, then have your attachments communicate with it using email or XML-RPC. It's not an especially good use of resources, but if using email for communications, your delay shouldn't be that much longer.
However, you should bear in mind that this is useful for detecting when a user has teleported.

"No longer true under 1.9 though iirc logging out and back in still does - RodrickHarrington"

llSetPos and llSetPrimitiveParams changes object's position by, at most, 10 meters

// keep moving until there--careful, gets stuck when obstructed by land
while (llVecDist(llGetPos(), dest) > 0.001) llSetPos( dest );

See the WarpPos library function that takes advantage of the fact that llSetPrimitiveParams only checks for the 10m distance for each item in the list

Calling state foo; while in state foo does nothing

This is a bit kludgy, but create a "mini-state" that simply switches back to the state you want to reflect into.

Instead of:
state foo {
    touch_start(integer n) {
        state foo;
state foo {
    touch_start(integer n) {
        state back2Foo;
state back2Foo { state_entry() { state foo; } }

Second Life revolves around radians.
Sadly us degree lovers suffer.
Script Example
float length = 10;

    listen(integer channel,string name, key id,string message)
        if((integer)message < 4) return;
        integer sides = (integer)message;
        float ang = (360/(float)sides)/2;
        float base = 90-ang;
        float apoth = llTan(base*DEG_TO_RAD)*(length/2);

Integer division rounds immediately.

If you execute a statement like this:
float myVal = 1 / 8;
myVal will be set to a value of 0. This can lead to very confusing results with operations that use both float and integer values (like the one below).
float foo = 2 * PI * (1 / 8);
foo will equal 0, because 1 / 8, when rounded, equals 0. Division with two integers results in a rounded result.

Workaround: Make sure to add ".0" to your numeric literals, explicitly making them floats:
foo = 2.0 * PI * (1.0 / 8.0);
This statement correctly evaluates (1.0 / 8.0) as a decimal value, so foo will equal approximately 0.7854.

Getting the "Link failed -- pieces too far apart" message.

See PiecesTooFarApart to get more detailed information on this error.

Unlinking physical objects causes them to fall (or explode) out of place

If physical objects are unlinked, the individual prims will fall to the ground (or explode away from each other). While linked, they will maintain their position. The first time you see this by accident, it can be quite annoying. But it can be a very cool result. If you really need to do this, turn your link set phantom before turning it physical, and simulate an "exploding" effect using llApplyImpulse.

Note: Please refrain from doing this in non-sandbox sims. The SecondLife physics engine (Havok) is not good at handling interpenetrating physical objects. In other words, this CAN cause a lot of lag! :)
And don't do it just to piss people off either... Use it when you want an effect, or it has a practical purpose... - Malarthi Behemoth

llLookAt and llApplyRotationalImpulse not working on attachments

From a scripted object attached to an avatar:
- llApplyRotationalImpulse() does nothing.
- llLookAt() screws up the avatar until the next teleport. The avatar will "sink" halfway below the ground/prim-based platform until that time.
This is because avatars are like prims that cannot rotate about the X or Y axis (see llSetStatus, STATUS_ROTATE_Y and STATUS_ROTATE_X). The second symptom is related to the damped-motion-attachment bug.

llRezObject gives no error message if it fails because the position passed to it is greater than 10m away from the position of the object the script is in.

llParticleSystem has maximum velocity x,y,z values of 100, which can change the direction of the vector, i.e. if you set a particle velocity of <150.0, 0.0, 200.0> , the real velocity will be <100.0, 0.0, 100.0>.
To keep this effect from changing the direction of the vector, do something like vec=min(100. , llVecMag(vec)) * llVecNorm(vec); (where min is something like float min(float a,float b) {if (a<b) return a; return b;}), which 'truncates' the vector to manitude 100.

Vehicle Scripts run from Transcendental Memory

Vehicle scripts can be replaced or changed without taking effect. They compile successfull and are being saved. Anyway the vehicle gets it�s old driving Script from some 'transcendental script memory'...

Because of the way LSL parser works (more details:, conditions in LSL are evaluated left to right, instead of right to left as in most programming languages. Check example on condition page.

In a short-circuited language if the left-hand side of a logical AND (&&) is FALSE the right-hand side is never tested since the entire test would always return a FALSE output no matter what the value of the right-hand side. Since LSL is not short circuited, both the left and the right-hand sides are tested all the time. More info and workaround on if-else page.

There are 2 comments on this page. [Display comments/form]