Talk:PRIM PHYSICS MATERIAL

Categorization

I expected to see this page under the Physics category, more so given that llSetPhysicsMaterial and llGetPhysicsMaterial are in it. The Physics/Material category sounds a bit over the top to me, at least while there are no other functions; it's a bit like creating an LSL Name category and put there llSetObjectName, llGetObjectName and PRIM_NAME. Is it acceptable to just use Category:LSL Physics instead of Category:LSL Physics/Material? --Pedro Oval 22:34, 23 January 2012 (PST)

Category:LSL Physics/Material (as it hasn't been created yet) is just an idea for a category, it can be changed to Physics instead. The reasoning behind having it in a subcategory is so that the material_bits flags don't flood the category. I forgot about this when I was putting together the function articles so I put them in physics/materials. Do you still think they should be in Physics? On this topic, does llGetPrimitiveParams return a materials_bit for PRIM_PHYSICS_MATERIAL? I wasn't sure when writing this article and the release notes make no mention of it. -- Strife ^{(talk|contribs)} 21:19, 24 January 2012 (PST)

I think the constants fit nicely in the Physics category. As for llGPP, no idea, as PRIM_PHYSICS_MATERIAL does not work for me at the time of this writing. My guess is that it won't be returned. I don't know if it will be required as part of the request, kind of like e.g. [PRIM_TEXTURE, face_num] works, to specify what data to return. --Pedro Oval 11:19, 26 January 2012 (PST)

Invalid constant

This constant doesn't actually exist in LSL. It was removed from beta code before release to agni, as it isn't needed for the function llSetPhysicsMaterial(). —The preceding unsigned comment was added by Ima Mechanique

Crap. I'll disable this. -- Strife ^{(talk|contribs)} 12:01, 14 March 2012 (PDT)