Difference between revisions of "Talk:LlGetPrimitiveParams"
Line 20: | Line 20: | ||
:This probably works the same as [[llGetTexture]]. Do you have full perm to the object? -- '''[[User:Strife_Onizuka|Strife]]''' <sup><small>([[User talk:Strife_Onizuka|talk]]|[[Special:Contributions/Strife_Onizuka|contribs]])</small></sup> 00:16, 15 October 2010 (UTC) | :This probably works the same as [[llGetTexture]]. Do you have full perm to the object? -- '''[[User:Strife_Onizuka|Strife]]''' <sup><small>([[User talk:Strife_Onizuka|talk]]|[[Special:Contributions/Strife_Onizuka|contribs]])</small></sup> 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. [[User:Brattle Resident|Brattle Resident]] 07:09, 21 September 2014 (PDT) |
Revision as of 06:09, 21 September 2014
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)