Difference between revisions of "Talk:WarpPos"

From Second Life Wiki
Jump to navigation Jump to search
m (Cross-reference the →‎Buggy!: and →‎Why Not Simplify: threads of this talk page)
Line 2: Line 2:


Is this going to be changed in the future? [[User:TxMasterG Ping|TxMasterG Ping]] 18:50, 30 March 2007 (PDT)
Is this going to be changed in the future? [[User:TxMasterG Ping|TxMasterG Ping]] 18:50, 30 March 2007 (PDT)
== Untested? ==
For moving about a sandbox, this works fine, and that's all I wanted from it ... but I see 2006-05 quote suggesting we could learn more with more test ... and I notice that sitting on an object that moves this way into random positions does seem to confuse the client and/or the server. In prticular, moving to off-world positions leaves the client thinking the agent is still on the object, but then errors start cropping up, things like can't save the edited script because the object is somehow lost to the server while yet existing in the client ...


== Script run-time error: Stack-Heap Collision ==
== Script run-time error: Stack-Heap Collision ==

Revision as of 22:46, 31 December 2008

Undocumented?

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

Untested?

For moving about a sandbox, this works fine, and that's all I wanted from it ... but I see 2006-05 quote suggesting we could learn more with more test ... and I notice that sitting on an object that moves this way into random positions does seem to confuse the client and/or the server. In prticular, moving to off-world positions leaves the client thinking the agent is still on the object, but then errors start cropping up, things like can't save the edited script because the object is somehow lost to the server while yet existing in the client ...

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.