auto stand up

ok what im trying to do is get my avatar to stand up right after he sits without me haveing to hit the stand up button, the reason for this is im using the sit command to teleport my avatar to the top of my tower, this is the code i have so far

default
{
    state_entry()
    {
        llSitTarget(<-5,0,11.7>,<0,0,0,1>);
        llSetSitText("Teleport");
    }

} 

i would like to know what i would have to add to this script to make him stand up after the teleport

from /15/d8/37156/1.html

    changed(integer change) 
    { // something changed
        if (change & CHANGED_LINK) 
        { // and it was a link change
            llSleep(0.5); // llUnSit works better with this delay
            if (llAvatarOnSitTarget() != NULL_KEY) { // somebody is sitting on me
                llUnSit(llAvatarOnSitTarget()); // unsit him
            }
        }
    }

Which is nicely commented so I don't think theres much more to say.

cool thanks man i will try that out later, thanks for the help

Also don't forget for llUnsit to work the object needs to be owned by the owner of the land (so if its group owned land the object has to be deeded to the group). If its not then unsit results in a 'floating'/flying at the destination and movement will create a system message of 'cancelled sit' usually.

Also llSitTarget does have a limit on range (it used to be around 300m as I recall and not sure if its been increased since then). If its range isn't far enough or you need to cross a sim border then you'd want an elevator instead (setting a sit target that's past a sim border or I believe higher than 768m Z position causes unusual behavior as the coordinates get flakey and I think it normally tries to just place the sit target at the sim border).

From http://secondlife.com/badgeo/wakka.php?wakka=llUnSit


And since the code I provided earlier only deals with agents listed using llAvatarOnSitTarget() then we need not concern ourselves with the land's ownership.

Spot on with the 300m limit.

    changed(integer change) 
    { // something changed
        if (change & CHANGED_LINK) 
        { // and it was a link change
            //llSleep(0.5); // This isn't needed any more.
            if (llAvatarOnSitTarget() != NULL_KEY) { // somebody is sitting on me
                llUnSit(llAvatarOnSitTarget()); // unsit him
            }
        }
    }

The script doesn't need the llSleep anymore.

is the llsleep the amount of time before your avatar stands up after he sits down?

oh and thanks for the script it works really well

The llSleep will yes, make the av stay sat for a while before unsitting.

There's a fair amount of hearsay evidence that these things work better with a 0.1-0.5s delay in them, presumably to let the sim catch up to your new position so you don't fall through the floor. I've never tested it, I must admit, it was "everyone knows" when I started scripting, so I just continued the practise, and I'm rarely idle enough for long enough to want to test it!

I remember the sit-hack teleport was one of the first scripts I played with. If I recall correctly taking out the llSleep had the effect (though it may not any longer) of throwing your avatar in the direction of the sit target if sufficiently far enough away, I used to adjust the time for longer distances (a teleport which only gets you half way and throws you the rest isn't much use in some cases though could be useful for others). I have yet to test if it is still required as Angela says.

I know the wiki says or (and even italicizes it) but I've noticed at least lately that if the teleporter using the llUnsit() function isn't group owned (for group owned land) then the unsit doesn't work properly and often results in a flying state or tossing the person up from the sit target, and when you move it gives a 'cancelled sit' message. This was happening with teleporters I had up in two different sims on group land. Once I deeded the teleporters to the group that owned the land this odd behavior stopped and the AV using the teleporter instead just ended up standing at the destination rather than flying and no more cancelled sit messages. This behavior never seemed to happen in the past so I suspect it comes from some recent permissions change made in the background that wasn't documented.

I have multiple sit-hack teleporters working on group owned land that have a short sleep before unsitting, and never have a problem with them being not deeded to the group. Every time I've tried without the sleep, I've ended up flying or otherwise not at my desination.