Talk:PosJump

From Second Life Wiki
Jump to navigation Jump to search

This Bug Fixed

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

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)

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)

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?

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