WarpPos -- llSetPos without the limits

I would try this myself if I had the time, but I don't, so I must ask... do we have a working Stargate system anywhere yet then? Surely that should be within reach now.

good idea, and yes, I think we even have the touch sit method now don't we? I don't know how you would make it look right but if you have a method great .

The client still seems to choke on long range teleports-- if we had a function like llForceSimConnection, which would cause the client to open up a connection to a sim-- similar to how the client connects to adjacent sims.

I still don't think we'll have teleports across the sim automated to a decent degree anytime soon.

I want to do a few tests to see what happens when you warp across a void sim space.

I'd rather keep pressing for llTeleportAgent instead of suggesting other ideas to distract roving Lindens.

That's a good point. Rapid movement is probably the worst possible solution to a lot of these things.

Aye, I have pretty much decided to go with using llMapDestination for any agent teleport farther than one adjacent sim away, because it just isn't reliable or quick enough with SitTarget/SetPos/WarPos.

Basically, I do SitTargets up to 519m distant, multiphase WarpPos for anything into one adjacent sim away, and then switch to llMapDestination for the rest with a detect at the end to see if I am still not at the destination once in the destination sim due to telehubs, and rez one more teleportal to get me the last bit of the way.

I think that is about the best that can be hoped for right now for agents. WarpPos still has its place as a long-distance teleport for objects, but not with agents sitting on them.

Oh, I also found a bug in my code posted above that I have since fixed:

  warpPos( vector destpos) {
    //R&D by Keknehv Psaltery, ~05/25/2006
    //with a little pokeing by Strife, and a bit more
    //some more munging by Talarus Luan

    // Keep us at ground level at the destination; assumes it is the same sim
    vector startpos = llGetPos();
    float groundheight = llGround(destpos - startpos);
    if (destpos.z < groundheight)
        destpos.z = groundheight;
    // Limit to max setpos height
    if (destpos.z > 768) 
        destpos.z = 768;
    // Compute the number of jumps necessary
    integer jumps = (integer)(llVecDist(destpos, startpos) / 10.0) + 1;
    // Try and avoid stack/heap collisions
    if (jumps > 100 )
        jumps = 100;    //  1km should be plenty
    integer count = 2;
    list rules = [ PRIM_POSITION, destpos ];  //The start for the rules list
    while (count < jumps) {
        rules = (rules=[]) + rules + rules;   //should tighten memory use.
        count = count << 1;
    }
    llSetPrimitiveParams(rules + llList2List( rules, (count - jumps) << 1, count);
} 

Heh, a good point. Perhaps something like "[Object Name], an object owned by [Owner Name], would like to teleport you to [Sim]:[Pos]. Would you like to teleport? [Yes/No]".

I'm curious as to why the Lindens seem to never implement many of the functions that we request, even the simple ones...

I've just had some very strange experiences with this..

I tried to use it in a "builder's cushion" (ie, an object that tracks behind the camera, so you can alt+view around an object without having to break to move your av, no matter how big the object is). Unfortunately it isn't quite fast enough to do that yet. But some very strange effects occured during the process. Parts of objects in the sim disappeared even though they were cached, and at one point, my AV was dropped on the floor and able to walk normally for a while, and then a second later was back sat on the object without my giving the sit command or anything similar..

In terms of sending accross void sims, it seems that objects will arrive without going off world if the final destination of the warppos is valid. However, when an avatar is sitting on the object, the avatar is automatically forced to stand up before entering a void sim, but the object continues moving.

There also seems to be a small descrepancy, some destininations within the destination sim will cause the object to go off world, while others the object will successfully travel.

Ill continue playing around with it
-Kokiri

I'm posting here because the original poster has updated it as recently as the scripting wiki.

I've been debugging my teleporter and found various bugs both here and on the wiki, including problems in plot_course() and several potential infinite loops. But the bug in the updated warpPos seems important enough to correct.

To see what's wrong, walk through an example where jumps = 13 or jumps = 15: warpPos won't reach its destination.

I propose fixing the last line of warpPos as follows:

warpPos(vector destpos)
{   //R&D by Keknehv Psaltery, 05/25/2006
    //with a little pokeing by Strife, and a bit more
    //some more munging by Talarus Luan
    //cleanup by Keknehv Psaltery
    //and another fix by Adrian Zobel
    // Compute the number of jumps necessary
    integer jumps = (integer)(llVecDist(destpos, llGetPos()) / 10.0) + 1;
    // Try and avoid stack/heap collisions
    if (jumps > 100) jumps = 100;//  1km should be plenty
    list rules = [ PRIM_POSITION, destpos ];// The start for the rules list
    integer count = 1;
    while ( ( count = count << 1 ) < jumps )
        rules = (rules=[]) + rules + rules;// should tighten memory use.
    llSetPrimitiveParams( rules + llList2List(rules, count - jumps, -1) );
}

I readed blog posts about that it was fixed, so maybe it doesn't work now

Very useful and still works=)

You dug up this old thread to say that O: Lol. On that point, dito

This is a fantastic script and I'm finding it great for teleporting within a sim. However, I want to adapt it to send an object to anywhere within a sim so that I can teleport into it later on.

If I put in a co-ordinate such as <166, 147, 34> (as an example), sit on it and teleport, I arrive at the correct location. If I send the object first it ends up at a location such as <196,160,214> - nowhere near the place it should be.

Can anyone tell me if I'm missing something either really simple or just not possible?

I've tried all of the warpos functions here but all with the same result.

If someone could give me some advice on how to overcome this problem it would be most appreciated!

Many thanks!

This is a fantastic script and I'm finding it great for teleporting within a sim. However, I want to adapt it to send an object to anywhere within a sim so that I can teleport into it later on.

If I put in a co-ordinate such as <166, 147, 34> (as an example), sit on it and teleport, I arrive at the correct location. If I send the object first it ends up at a location such as <196,160,214> - nowhere near the place it should be.

Can anyone tell me if I'm missing something either really simple or just not possible?

I've tried all of the warpos functions here but all with the same result.

If someone could give me some advice on how to overcome this problem it would be most appreciated!

Many thanks!

Hmmm... I use warpPos all the time to push objects around without "passengers," so I know it works--and can't think just what could go wrong. Perhaps it would help to see the code surrounding the warpPos function call? Or maybe just insert an llOwnerSay() of the coordinates you're passing to it, to make Real Sure they're what you think they are?

just because I felt like digging up history... there are about 7 different stargate/ring transport style sytems in use, 3 of them with extensive networks, oddly none of the ones I've seen use warppos except one of the ring sets... most use sit target (rings) and llmapdestination (stargates)

I'm using a script from this thread (see below) with one of the updated warpos functions in it - the one I use is almost identical to this only that I put a listen in to parse a command on channel 90 to accept custom vectors):

vector home;

warpPos( vector destpos) {
//R&D by Keknehv Psaltery, ~05/25/2006
//with a little pokeing by Strife, and a bit more
//some tinkering by Talarus Luan as well

// Keep us at ground level at the destination; assumes it is the same sim
vector startpos = llGetPos();
float groundheight = llGround(destpos - startpos);
if (destpos.z < groundheight)
destpos.z = groundheight;
// Limit to max setpos height
if (destpos.z > 768)
destpos.z = 768;
// Compute the number of jumps necessary
integer jumps = (integer)(llVecDist(destpos, startpos) / 10.0) + 1;
// Try and avoid stack/heap collisions
if (jumps > 100 )
jumps = 100; // 1km should be plenty
integer count = 2;
list rules = [ PRIM_POSITION, destpos ]; //The start for the rules list
while (count < jumps) {
rules = (rules=[]) + rules + rules; // Should tighten memory use.
count = count << 1;
}
llSetPrimitiveParams(rules + llDeleteSubList( rules, 0, ((count - jumps) << 1) - 1));
} 

default
{
state_entry()
{
llListen( 2, "", llGetOwner(), "" );
}

listen( integer chan, string name, key id, string msg )
{
if ( msg == "home" )
{
home = llGetPos();
return;
} else if ( msg == "gohome" )
{
warpPos( home );
return;
}
list parsed = llParseString2List( llToLower(msg), [" ",",","<",">"], [] );
if ( llGetListLength( parsed ) < 3 )
return;
warpPos ( < llList2Float( parsed, 0 ),
llList2Float( parsed, 1 ),
llList2Float( parsed, 2 ) > );
}
}

All I want it to do is to accept vectors via chat and to end up at the correct ones and then wait for either a command or timer to fire and rez an object then self die - which it does. It works perfectly if you sit on it, but if you send the object there first, it ends up elsewhere.

I even tried it with Khalek's script (again on this thread) and sitting on the object went fine - sending it remotely and having it talk back to me ended up with it being in the sky (rather than the land) and nowhere near where it should be.

Qie Niango - do you have any code which you use that I could adapt to see if it works for me?

Any help would be appreciated!

gah, please use php tags to preserve formatting... even if you don't see the result, many of the helpful regulars here do (through the available firefox add-on linked in my signature) and it makes reading and tracing so much easier... opening another program to format the code isn't hard, but it slows down reading and some (like me today) will just skip it... faster responses if you include the formatting and tags

Oh.
Wow.

I haven't seen those plugins before - omg. An amazing difference! Thanks for the links - life will be soooo much easier now! I've edited my post to include the php tags so apologies for that!

Now, if I could only get this script working with sole objects - I've been trying various teleporters using warpos and it just hates arriving at a destination without an avatar sitting on it...!

I can--I'll wake up my lazy alt at some point and see what he can find that's not too obscure. FWIW, I never got 'round to updating any of my scripts from the very first version, the one at the top of the first post in this thread, but kinda doubt it matters: I tried your script as-is and haven't gotten it to fail, with or without sitting on the prim, so... not sure how to be most helpful at this point. (Unfortunately, today the asset server seems intent on hiding the script from me as soon as the containing prim warps beyond visual range. Dunno what's happening there--never saw quite this behavior before.)

Thanks for that - it would be most appreciated as this is driving me nuts! Could it be that properties with ban lists etc could be causing the problem?

Asset server does seem flaky today, lots of bits not appearing in my inventory or saving etc.

I look forward to trying your code - lets see if I can break that too!

Very definitely: this is one of the big problems with warpPos teleporters, especially near ground-level--except that it should (I'd think) behave no better and possibly worse with an avatar attached. That is, if the parcel is set no-object-entry, then I'd expect it to block traversal with or without passenger, and if there's a ban-list, I'd expect it to be even fussier about it if a banned passenger were aboard. And if the parcel were no-script... hmmm... seems bad, with or without a passenger.

I've never fiddled with this enough around restrictive parcels to know for sure, but I suspect it can get through the corner of such a parcel as long as it doesn't "set foot" there with one of the PRIM_POSITION coordinates in the list--if so, that could make testing kinda confusing.

Ah, I see - what puzzled me the most was that avatar sitting on it did get through whilst un-avatared versions couldn't (well 50/50 chance). Doesn't happen with all teleports but the fact that the place I was trying it out on was practically next door to me made me stumped.

avatars sitting on prims get to ignore things like no object entry flags...

from descriptions about script behavior and set prim params you'd think it was an instantaneous move, with no interveneing space (same with rotations), but it seems to behave more like 'critically damped to new position in < ~.01sec (faster than minimum event time) and the server just doesn't bother reporting it's inbetween position becase it's too fast to register to things like colisions... all speculation but that's how it seems to behave for land flags