@Dalai, corrected states -> state. The api dumping script didnt show array sizes which caused this confusion, added array sizes to the types and corrected in svn.
# IMHO this is just a problem we get from cramming so much functionality into one actuator. Actuator|EditObjectActuator.replace_physics_mesh # Ideally I think we should have a replace mesh actuator. Actuator|ReplaceMesh.use_physics RE: use_priority & use_force_distance use_force_distance is more confusing, since it sounds like this could be a physics force, perhaps it could be named to use_fixed_distance ? @Nathan, agree about the problem setting the current frame there are a few cases like this where the api doesn't behave in a useful way from a python standpoint. - Image.filename_raw # so changing the filename doesn't reload the newly set filename. - MeshFace.verts_raw # so we can set all 4 indices's on a new face. Id rather deal with these separately. Makes sense to choose one here. Ok to settle on vertex|vertices over vert|verts. (committed) In this case it makes sense because faces & edges isn't abbreviated but there are abbreviations we applied in a number of places. - coordinates -> coords, Otherwise variable names get too long IMHO. - duplicator -> dupli - sss & ao are used in a few places, for these I don't think its great to use the full names though we could for consistency since it is used in some places. RenderSettings.simplify_ao_sss would be... -> simplify_ambient_occlusion_and_subsurface_scattering Could you make a list of names you think should be using their un-abbreviated versions? For "co", used for vertex/grease pencil, keyframe's particles. Id really prefer to keep this abbreviation, its just very convenient since these end up being accessed a lot and a vertex doesn't have many other attributes. We can end up with lines like (v1.co.y - v2.co.x) + (v3.co * matrix).x ... etc @Alberto, curves have a direction so we could use handle_before/after, prev/next or similar, IIRC Brecht named this, even though its not fully correct in the case of 3D curves I don't have a strong opinion on this. On Tue, Aug 17, 2010 at 8:35 AM, Alberto Torres <[email protected]> wrote: > Keyframe.handle1 -> handle_left: float "Coordinates of the first handle" > Keyframe.handle1_type -> handle_left_type: enum "Handle types" > Keyframe.handle2 -> handle_right: float "Coordinates of the second handle" > Keyframe.handle2_type -> handle_right_type: enum "Handle types" > > This new name doesn't make sense (only for f-curves). What's the > problem with the old name? > _______________________________________________ > Bf-committers mailing list > [email protected] > http://lists.blender.org/mailman/listinfo/bf-committers > -- - Campbell _______________________________________________ Bf-committers mailing list [email protected] http://lists.blender.org/mailman/listinfo/bf-committers
