Difference between revisions of "Talk:WarpPos"
(Heads up, the "Script run-time error: Stack-Heap Collision" is baack happening again in the lw function warpPos) |
|||
Line 1: | Line 1: | ||
== Undocumented? == | |||
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) | ||
== | == 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) | |||
-- [[User:Ppaatt Lynagh|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. -- [[User:Deanfred Brandeis|Deanfred Brandeis]] | 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. -- [[User:Deanfred Brandeis|Deanfred Brandeis]] |
Revision as of 21:25, 31 December 2008
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