Talk:PosJump

This Bug Fixed

Heads up. The PosJump page now explains this bug was fixed in simulators since 1.26. --- Ppaatt Lynagh

Indeed, the PosJump page history shows User:Soft Linden said this in the "19:31, 24 December 2008" revision. -- Ppaatt Lynagh 05:47, 6 February 2009 (UTC)

This is pretty much guaranteed to be removed, at today's office hours "[17:18] User:Andrew Linden: as I recall posJump is dead, warPos is not dead" -- Gregory Maurer 02:32, 13 February 2009 (UTC)

The Discovery

According to my investigation, it is possible to do "PosJump" if the result of X^2+Y^2 overflows the limit of float. To give an actual example, vector infinity = <1.304382E+19, 1.304382E+19, 0.0>; can "PosJump". -Fake Fitzgerald 4:48, 20 September 2008 (PDT)

The Future

Given, the standard client lets me sit on an object and then edit that object to move my avatar and the object wherever.

Given, Lsl should be able to do whatever the standard client can do.

Therefore, there should be a documented interface to move the object wherever, or the standard client should stop being able to do this, one or the other. It is then reasonable and good for the community to hope, even to ask by Jira, that the Linden lab folk document some interface.

Q1. All correct?

Disagree. Lots of things that can be done with the viewer would be dangerous to do with LSL. Examples include deleting inventory, IMing other people as the resident, and creating scripts with programmatically generated script content. --Soft Linden 03:45, 25 December 2008 (UTC)

Persuasive & new to me, thank you. -- Ppaatt Lynagh 05:31, 6 February 2009 (UTC)

Q2. If yes, then what interface should we nominate for support?

I'm thinking we can't reasonably ask for support of the interface shown here, where we arbitrarily chose a value that barely overflowed X^2+Y^2 and we arbitrarily zeroed the Z component. Right?

Changing behaviors with a magic value would make less sense than a specific function that does what's desired here. I'd take the discussion to sldev to try and get an understanding of why movement is limited, and to argue for special cases where farther movement should be supported. For example, it would be pretty reasonable to push for a special function that moves farther distances when an avatar is seated on the object if that's desired. --Soft Linden 03:45, 25 December 2008 (UTC)

Re discussion, 2009.02.03 Andrew Linden office hours has also now discussed this, SVC-2998 is now mentioned below, and I'll google sldev, thank you. Ppaatt Lynagh 05:31, 6 February 2009 (UTC)

Re what's desired, the content I hope to create include (a) to wear something that bookmarks where I've been and teleports me to return and (b) to rez a sky box from the ground and put my avi there. I'm getting by with rezzing a box on the ground and calling WarpPos. -- Ppaatt Lynagh 05:31, 6 February 2009 (UTC)

Q3. Should the Infinity we nominate for support be at X = Y = Z = maxFloat?

<lsl> lwSetFarPos(vector there) // http://wiki.secondlife.com/wiki/PosJump http://wiki.secondlife.com/wiki/warpPos https://wiki.secondlife.com/wiki/LSL_llSetPrimitiveParams https://wiki.secondlife.com/wiki/LSL_llSetPos {

   float maxFloat = 3.402823466E+38;
   vector nowhere = <maxFloat, maxFloat, maxFloat>;
   llSetPrimitiveParams([PRIM_POSITION, nowhere, PRIM_POSITION, there, PRIM_POSITION, here, PRIM_POSITION, there]);

} </lsl>

Here we see that the actual interfaces that once did work as explained in this Lsl Wiki run out in advance of what Linden Lab has committed to support long term.

Q4. Should we therefore have some convention to point the reader of the script back into this Wiki for info on how the support or lack of support for those interfaces evolve?

How about lw rather than ll for functions? And something else for constants, such as one here corresponding to C MAX_FLT or Java Float.MAX_VALUE: <lsl> float LW_MAX_FLOAT = 3.402823466E+38; </lsl>

And we could ask the people who coded the LSL /LSL tags of this wiki to learn these lw LW like they know ll, to link LSL examples back into this wiki at those spots?

Q5. Or have we already formed some other convention like lwSetFarPos and LW_MAX_FLOAT?

Q6. I'm new new new. I arrived long ago, but I'm only barely scraping time out of my life for fun like this, so I haven't yet experienced much time in world . Am I making any sense?

Ouch I didn't know the discussion had continued here, since I haven't yet figured out how to turn on WatchThisPage wherever I've talked myself. Eventually someone here IMed me in-world, so now I'm back.

Thanks in advance, --- Ppaatt Lynagh 19:27, 24 December 2008 (UTC)

LW might be confused with SL's previous name "Linden World" -- Strife ^{(talk|contribs)} 17:17, 25 December 2008 (UTC)

What prefix would work better than lw to gather all the functions suggested in this wiki together? -- Ppaatt Lynagh 05:31, 6 February 2009 (UTC)

How about we name this wwSetFarPos, by figuring this Wiki of SecondLife.com is the main World Wide Web place where such things come into being? -- Ppaatt Lynagh 05:31, 6 February 2009 (UTC)

Given that PosJump is being fixed, and it having been a much, much more resource friendly beast than warpPos ever was, I'd like to point you in the direction of http://jira.secondlife.com/browse/SVC-2998, which is a llWarpPos() suggestion which addresses all concerns that were the cause for the 10M llSetPos Limit. There is virtually no reason not to implement this. Chalice Yao 17:58, 3 February 2009 (UTC)

link fast! :D

I changed it to llSetLinkPrimitiveParamsFast, i hope that's alright. --TigroSpottystripes Katsu 12:29, 16 May 2010 (UTC)

Aparently the root prim of a single prim linkset isn't considered the root prim :/ --TigroSpottystripes Katsu 12:55, 16 May 2010 (UTC)

Use !!llGetLinkNumber(). -- Strife ^{(talk|contribs)} 20:25, 16 May 2010 (UTC)

Won't that be a problem if the script isn't in the root prim? --TigroSpottystripes Katsu 14:42, 18 May 2010 (UTC)

Why not just use -4 (LINK_THIS) Strife? That works whatever the object config. (Unless it is dropped into a child?)

And Tigro...I am pretty certain that the double not (!!) was indeed supposed to be there. -- Fred Gandt ^{(talk|contribs)} 14:57, 18 May 2010 (UTC)

Really? What was that supposed to do? Should i undo the removal? --TigroSpottystripes Katsu 15:16, 18 May 2010 (UTC)

It always returns 1 if in a link_set and/or 0 if in a lone prim. So, The link_number applied to llSetLinkPrimitiveParamsFast will always be the correct link number (whether in a link_set or not and whether in the root or not). BTW Strife... I just answered my own question didn't I? *rolls eyes* -- Fred Gandt ^{(talk|contribs)} 15:56, 18 May 2010 (UTC)

Yep you did. It really all depends if you want to move the entire object or just the prim in question. You only need PosJump/WarpJump for moving the root since the 10m limit only applies to root prims that aren't attached. -- Strife ^{(talk|contribs)} 20:33, 18 May 2010 (UTC)

P.S. If !!llGetLinkNumber() is unsightly try 0 != llGetLinkNumber() or 0 < llGetLinkNumber() instead; they all return the same thing.

(Probably) obsolete

... now that we have llSetRegionPos, this function should be considered obsolete.

— Gwyneth Llewelyn (talk) 13:14, 3 October 2022 (PDT)