Talk:LlGetPrimitiveParams

Alphabetization

This page is listed under 'C' where it should be listed under 'G'. Unfortunately, the methodology to adjust this improper alphabetization is obfuscated by overly complex format structure.

Could someone with more experience let me know how to accomplish this otherwise minor change?

Thanks and Cheers! User:Lazarus Longstaff

It's a MediaWiki bug. I haven't yet found a bug in templates that causes the disordering of the category pages. A temporary fix is to edit and save any page that is out of order (which lends credence to the theory that it's a MediaWiki bug). The problem arises from editing the templates the pages are based on. Obviously the templates need to be improved from time to time as new concepts are added. -- Strife Onizuka 18:38, 18 April 2007 (PDT)

Don't take what I said about the templates to mean I agree that they are overly complex, I wrote the templates. Some aspects of the complexity are intentional, others were left over from previous revisions (lava flowed in). I've been meaning to write an article on the design and how to extend it. --Strife Onizuka 21:33, 18 April 2007 (PDT)

Umm - I just tested out the Strife's code fragment, and I'm trying to debug it as I have time. No workee. --Nobody Fugazi 09:32, 27 February 2008 (PST)

Your not the first person to say this recently, I've poked at the code and I can't find anything wrong with it. How are you using it? -- Strife Onizuka 03:01, 29 February 2008 (PST)

I fixed the examples. One didn't work because it obviously was not including the required LSL structure (a default state). The other one seemed to be a flawed/older version. I found a working one from Strife elsewhere and replaced the broken one. -- Miguael Liamano 12:59, 9 April 2013 (PDT)

PRIM_TYPE_SCULPT

Apparently it is not possible to use this feature to get the UUID of the sculpt map, even if they are your sculpts. This is a permissions issue that is not documented. Overbrain Unplugged 20:33, 14 October 2010 (UTC)

This probably works the same as llGetTexture. Do you have full perm to the object? -- Strife ^{(talk|contribs)} 00:16, 15 October 2010 (UTC)

PRIM_TYPE and Mesh

The documentation implies that llGetPrimitiveParams([PRIM_TYPE]), when run in a mesh, should return [7, NULL_KEY, 5]. In fact, in my testing, it seems to return [7, UUID, 5], where UUID appears to be the same for two copies of the same mesh but different for two different meshes (as I would expect if it is a key of the mesh model itself). This is very helpful - except I can't help but wonder if it is reliable. I'd be happy to update the doc to report the behavior I observe - but if that can't be relied on, it would be important to say so. Brattle Resident 07:09, 21 September 2014 (PDT)

I say change it. Here is where you need to make the change: Template:LSL_Constants/PrimitiveParams/sculpt_types

LL isn't good about telling us about changes in the spec. -- Strife ^{(talk|contribs)} 08:35, 21 September 2014 (PDT)

At present the return value depends on permissions. NULL_KEY is still returned on some mesh objects, analagous to how texture UUIDs are handled. --ObviousAltIsObvious Resident 09:28, 21 September 2014 (PDT)

Makes sense. -- Strife ^{(talk|contribs)} 21:53, 21 September 2014 (PDT)

Caveat duplication

I'LL be working on that this week some time. -- Strife ^{(talk|contribs)} 22:10, 21 September 2014 (PDT)

PRIM_POSITION, PRIM_POS_LOCAL, PRIM_ROTATION, PRIM_LOCAL_ROT

As worded, the main page erroneously indicates that both PRIM_POSITION and PRIM_LOCAL_POS return regional coordinates and that both PRIM_ROTATION and PRIM_LOCAL_ROT return global rotation. Unless someone speaks up with a counter by next week (by 2016-03-06), I'm going to correct the page. Nava (talk) 00:54, 28 February 2016 (PST)

I'm not sure where on the page you are seeing that. I'll fork the local and vs global parameter names so their hovertext can be configured individually.