LSL Wiki Mirror : Hacks

Hacks

Hacks are usually undocumented features, surprising unexpected consequences, or unintended uses of features of LSL and Second Life. Given the crazy-glue-and-duct-tape nature of hacks, there is no guarantee that a hack that works today will work tomorrow, or will work in exactly the same way.

This page is not a guide to hacking the client, an act which is against the TOS.

Agent Key Determination

With sensor, collision, and touch events, the object type being dealt with can be detected with llDetectedType. This is not so with listen events. To determine whether the key returned by a listen is an agent or not, it must be determined whether the object with that key owns itself.

Example

integer isAgent(key id)
{
    return (llGetAgentSize(id) != ZERO_VECTOR);
}

Example

default
{
    state_entry()
    {
        llListen(0,"",NULL_KEY,"");
    }

    listen(integer channel, string name, key id, string msg)
    {
        if(isAgent(id))
        {
            llSetColor(<0,1,0>,ALL_SIDES); //Prim turns green if an Agent speaks
        } else
        {
            llSetColor(<1,0,0>,ALL_SIDES); //Prim turns red if a scripted object speaks
        }
    }
}

Very useful in an intercom system, so you don't relay spammy vendor ads too!

Note: this will not work across sim borders as llGetAgentSize only works on keys of agents in the current sim. Using llGetOwnerKey on a key not in the simulator will return the key passed to it. If you use it to check if a key is an agent it will falsely identify invalid keys (if using it on a key returned from a listen and the chat originated from a neighboring sim, the key will be invalid). -BW

Short-Distance (In-Sim) faked "Teleportation"

If using a large offset vector with llSitTarget, and then llUnSit when detecting the changed event, an effective short-range (up to 300m as of 1.3.0) teleporter can be made that works when a resident chooses to "Sit" on the object. (Note that this is not the same as actually teleporting; it just looks that way to the user.)

2-String Linked Message Transmission

Because a key is really just a fancy string, a second string can be substituted instead of the key and llMessageLinked can send it without typecasting.

However, because there's no limit to the length a string can be, it's primarily useful as a way to organize data by reducing the amount of work the recieving script must do to parse input. Also, having two strings already seperated is marginally more efficient then having one string and later parsing it into two.

Note: as keys cannot be directly typecast to or from floats, integers, rotations, or vectors, if the intended second message is one of these types, first cast it to a string, then to the type of choice. The inverse is true when recieving the message.

Example

integer num = 1;
string str = "hello";
string str2 = "goodbye";

llMessageLinked(LINK_SET, num, str, (key)str2);

Permanent Small-Memory Information Storage

Besides using a script's memory as permanent storage (and just never resetting it), a script can store short strings in the object name (using llSetObjectName/llGetObjectName) and description (llSetObjectDesc/llGetObjectDesc) of each prim. If the object is not going to change it's name, use child prims in a link set for that. Floats can also be stored in other object properties such as texture rotation, offset, alpha, scale, etc. Basically anything that has a get/set combination. To store integers, you can simply convert them to floats and back by scaling them down to fit into the usual 0 - 1.0 range.

llSetTexture can also store strings using the typecast (but the object will always have to have full permissions to read back the data), as well as llSetAlpha for floats, llSetColor for vectors. Combined, a lot of information can be stored permanently.

Note: The llSetTexture hack no longer works attempting to specify a texture that is not a valid texture key or not the name of a texture in the objects inventory will return an error "Couldn't find texture (your string)"

In-Function State Change

Usually, the compiler gives an error when the state tries to change from within a function. There is a workaround to this though: put the state change within a conditional statement's brackets.

Example

changeState()
{
    state foo; 
}    
// Doesn't compile.

changeState()
{
    if(1 == 1)
    {
        state foo;
    }
}
// Compiles.

See this page for more details.

llSetPos > 10m per call

llSetPrimitiveParams executes its rules as it comes across them, so if a list has multiple PRIM_POSITIONs in it, each one will be executed. This allows the 10m limit on llSetPos to be avoided.

See WarpPos for more details and code.

Detect Which Grid Script is running on

If you use an external system to keep track of sales on your vendor, you don't want People on Beta Grid messing up your tidy book keeping, by simply buying something from you. Here is a simple but slow routine to identify which Grid a script is running on (if you know a faster way than llGetSimulatorHostname, please correct me)

Example

integer idGrid()
{
    list Grids = ["agni","teen","dmz","colo","siva","durga","aditi"];
    string server = llGetSimulatorHostname();
    list serverParsed = llParseString2List(server,["."],[]);
    string grid = llList2String(serverParsed, llGetListLength(serverParsed) - 3);

    return llListFindList(Grids, [grid]);

}

Example

default
{
    touch_start(integer total_number)
    {
        integer grid = idGrid();
        
        if(grid == 0)
        {
            llSay(0, "You are on the Main Grid");
        }else
        if(grid == 1)
        {
            llSay(0, "You are on the Teen Grid");
        }else
        if(grid == 2)
        {
            llSay(0, "You are on the Linden Only Grid");
        }else
        if(grid >= 3)
        {
            llSay(0, "You are on the Beta Grid");
        }else
        {
            llSay(0, "Where the fuck are you?");
        }
    }
}

Local Application Launching via llLoadURL

llLoadURL functionality can be altered to allow for user initiated interactions between the SecondLife Client and applications running on the same computer workstation.

On Windows machines, the HKEY_CLASSES_ROOT\HTTP\shell\open\command can be modified to a batch or command line processing application, resulting in llLoadURL calls executing the specified application. This has the unfortunate side effect of breaking any other standard uses of llLoadURL in world.

Alternatively, changes could be made to a machines host file or the machine's local IP address could be specified in a URL and a webserver run on the local machine.

Discussion of usage: http://forums.secondlife.com/showthread.php?t=110251

LSL Style Guide | Lag