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)