Talk:WarpPos

Undocumented?

Is this going to be changed in the future? TxMasterG Ping 18:50, 30 March 2007 (PDT)

Script run-time error: Stack-Heap Collision

I do now see "Script run-time error": "Stack-Heap Collision" when I try to jump too far, for example:

<lsl> default {

   state_entry()
   {
       llOwnerSay("state_entry");
       vector here = llGetPos();
       warpPos(<here.x, here.y,  200>);
       warpPos(<here.x, here.y, 3000>); // Script run-time error: Stack-Heap Collision
       warpPos(<here.x, here.y,  200>);
   }

} </lsl>

My Server: Second Life Server 1.24.10.106829

My Client: Second Life 1.21.6 (99587) Oct 14 2008 17:42:25 (Second Life Release)

-- Ppaatt Lynagh 05:25, 1 January 2009 (UTC)

Buggy!

Wow, this thing has one huge bug, which will lead to a stack-heap collision even over a small distance. Appending the "rules" list to itself for the number of jumps is wrong. You need a prototype list to append to the actual rules list. -- Deanfred Brandeis

I think you have LSL confused with a real programing language, LSL operations are pass by value, you aren't appending it to itself you are appending a copy of it to itself. The only stack-heap collision issues arise from not having enough memory available to build the list. The method used here is the most efficient. Strife Onizuka 11:19, 9 April 2007 (PDT)

What about calling the warppos function again using (0.5 * (target + llGetPos())) as new target if the number of jumps is too high ? " if (jumps > 100 ) warppos(0.5 * (destpos + llGetPos())); " That would recursively divide the distance in digestible chunks between large list allocations. I'm not able to test it just yet, will keep you informed.--Jesrad Seraph 03:04, 20 April 2007 (PDT)

The code no longer appears to be the most efficient when compiled as Mono. When compiled as Mono, I no longer see any memory advantage at all to using the code: rules = (rules=[]) + rules + rules; in comparison to the code: rules+=rules; However I seem to be able to get += to double lists in under 60% of the time in my tests. I'm not suggesting changing the code in the article at the moment (because the advantage of the current code to people *not* compiling in Mono is pretty critical, and the benefit to people compiling under Mono isn't exactly huge.) --Tatiana Niven 16:00, 29 August 2008 (AEST) :P

Why Not Simplify

Here's a variation that works better at my desk:

<lsl> list lwCopies(list copy, integer count) {

   if(count <= 0)
   {
       return [];
   }
   else
   {
       list copies = copy;
       integer length = 1;
       while(length < count)
       {
           copies = (copies + copies);
           length *= 2; // Overflows when count large
       }
       return llList2List(copies, 0, (llGetListLength(copy) * count) - 1 );
   }

}

lwSetCloserPos(vector there) {

   list command = [PRIM_POSITION, there];
   float distance = llVecDist(llGetPos(), there);
   if(1000.0 < distance) { distance = 1000.0; } // Script run-time error/ Stack-Heap Collision if too far away
   llSetPrimitiveParams(lwCopies(command, 1 + (integer)(distance / 10.0)));

}

lwSetFarPos(vector there) {

   float distance = llVecDist(llGetPos(), there);
   integer tries = (1 + (integer)(distance / 1000.0));
   while(tries--)
   {
       lwSetCloserPos(there);
   }

}

default {

   state_entry()
   {
       llOwnerSay("state_entry");
       vector here = llGetPos();
       lwSetFarPos(<here.x, here.y, 3000>);
       lwSetFarPos(<here.x, here.y,  200>);
   }

} </lsl>

I'd love to hear what kinds of tests run better with the less simple code posted in the page?

-- Ppaatt Lynagh 05:39, 1 January 2009 (UTC)

Wrapping lwSetFarPos around lwSetCloserPos may well be exactly what Jesrad Seraph meant to suggest above ... and Tatiana Niven might have opinions on the best form of { copies = (copies + copies); } ... -- Ppaatt Lynagh 05:58, 1 January 2009 (UTC)

See Also

People interested in this exploit may also find posJump to be of interest. A much more efficient method of tricking an object into jumping to some arbitrary position.