Talk:LlGetLinkPrimitiveParams

Caveat: the rotation value returned is the link's global rotation

Seein' as how this function is about child prims, I'd suggest an additional caveat about the rotation value it returns being the child's global rotation - like the one about the position value - as this is slightly counter-intuitive. I am, as ever, kinda nervous about adding this unilaterally and would appreciate confirmation before doing so. Pete Olihenge 00:22, 4 April 2010 (UTC)

Good point. I'm surprised there isn't one already, i'll investigate (later, have to get ready for work). -- Strife ^{(talk|contribs)} 18:06, 6 April 2010 (UTC)

I'd do it myself right now, but editing stuff buried in templates is less than straightforward, it seems. Any clues as to how it's done would be appreciated - either before or after the fact. Cheers, Strife. Pete Olihenge 18:18, 6 April 2010 (UTC)

I've put a caveat on PRIM_ROTATION. Most flag specific information is on the individual flag pages; via transclusion it propagates to the PrimitiveParams articles. This way when you want to edit info about a flag you just go to that pages and edit. -- Strife ^{(talk|contribs)} 02:02, 8 April 2010 (UTC)

Many thanks, Strife. I'm just one of the many users of this wiki that owes you a huge debt of gratitude for all the work you've put into making it the invaluable resource that it is. Pete Olihenge 16:17, 8 April 2010 (UTC)

It was my pleasure. I'm sorry that the design is so complex, I wish it were possible to make it more intuitive but due to wiki limitations, intuitive comes at a very high price: non-unified style and information desynchronization; which leads to user confusion and reduced readability. That said, I am working on the problem, I have plans for an editor that makes editing information easier. -- Strife ^{20:16, 18 July 2010 (UTC) (talk|contribs)} 18:51, 8 April 2010 (UTC)

Why does this return global position and rotation? Since it is clearly intended for linked prims, why does it not return the local position and rotation? It makes absolutely no sense. -- Garbo Szondi 01:17, 19 July 2010

It has to do with the history of PrimitiveParms functions. The functions were added to LSL over a 6 year period: 1# llSetPrimitiveParams, #2 llGetPrimitiveParams, #3 llSetLinkPrimitiveParams, #4 llGetLinkPrimitiveParams, #5 llSetLinkPrimitiveParamsFast. So to answer your question as to why: There are two reasons, #1 PRIM_POSITION and PRIM_ROTATION were supposed to work like llSetPos and llSetRot and likewise llGetPos and llGetRot; #2 the flags are designed so they work exactly the same for link and non-link functions. The old flags are poorly designed but lava-flowed; the solution is to introduce new flags. -- Strife ^{(talk|contribs)} 02:41, 21 July 2010 (UTC)

Is this supported in older viewers?

Using Second Life 1.23.5 (136262) Oct 14 2009 12:08:26 (Second Life Release)

It doesnt error and nothing is returned. Lana Straulino 09:40, 7 May 2010 (UTC)

If you go to the Scripting forum at http://blogs.secondlife.com/community/forums/scripting and post the code you're using you'll probably get some useful feedback. It does sound more like a problem with your code rather than a bug in the function itself. Pete Olihenge 10:23, 7 May 2010 (UTC)

It still compiles fine, even though it doesn't show up in the drop-down function list and isn't recognized by the editor. Sayrah Parx 16:32, 20 June 2010 (UTC)

Duplicate notes and see-also

The Notes section is coming out duplicated, and there's also a duplicate llGetLinkNumber entry in See Also. That's caused by this edition which introduces a template needed for the parameters to look right, but apparently that same template is introduced later indirectly through {{LSL Constants/PrimitiveParams|get|link}}, causing the duplication. Does anyone know how to fix that? --Pedro Oval 05:56, 23 May 2012 (PDT)

I'll look into it. -- Strife ^{(talk|contribs)} 08:43, 25 May 2012 (PDT)