[Bf-animsys] Durian Requests Page - In response to 'Scripting' Section issues

[Joshua Leung]

Hi,

On Thu, Oct 29, 2009 at 12:05 AM, Nathan Vegdahl <nathanvegdahl at gmail.com>wrote:

> I'm sending this to Campbell too, since he's not on the animsys mailing
> list.
>
> > 1) Unfortunately, this is hard to guarantee, since the types exposed via
> the
> > Python API directly correspond to the actual state of the data
> internally.
>
>     Fair enough.
>    In that case, could we instead get an api function or operator
> that sets the current mode:  bpy.ops.set_mode("POSE_MODE")
>    Or something like that?  That way scripts can easily guarantee
> that they are in the mode they need to be in.  Trying to toggle all
> the modes to get things where you need them to be is kind of nasty
> from a scripting standpoint.
>    (Incidentally, this would also open up more possibilities for the
> UI too, if people want to set hotkeys for setting modes rather than
> toggling.  And it's also more robust from a macro standpoint.)
>

I'm sure that there should be an operator that does this...

Quickly checking, this should be:
bpy.ops.object.mode_set(mode='OBJECT', toggle=False)   <--- set the mode
value as appropriate



>  > 2) Personally, I hate functions throwing exceptions. If making them read
> > only solves the problem, then great. Or perhaps just hiding all the
> invalid
> > types in certain modes will do will be sufficient. I have a feeling that
> > hiding the data may be the most effective way...
>
>     Well, the important point is just that things shouldn't fail
> silently.  They should fail loudly and annoyingly.  Whether we do this
> by making things read-only or through hiding the properties isn't so
> important.  But failure should always throw an exception.  Otherwise
> how is a script supposed to know that it failed at what it was trying
> to do?
>
> Fine, I guess that's a valid argument. I see what you're getting at now


> > 6) Any reason not to just read it from the EditBones?
>
>
>    Convenience.  But it's not critical by any means.  Feel free to
> ignore this one. :-)
>    I can accomplish the same stuff through the bone's matrix.
>
Seeing Campbell's "fix" for getChildren, I guess this could be added quite
simply too as a utility function...


>
> > 7) The tags in the names were really to make it "clearer" where in the
> > evaluation pipeline those values were used. Maybe we could drop them :)
>
>    Well, it's just that the ones that are actually called "head" and
> "tail" don't seem to do anything, or at the very least aren't what I
> expected from the names.  Intuitively I expected "head" and "tail" to
> actually be what "armature_head" and "armature_tail" are (in fact, I
> think I even complained to Campbell about them not working).
>   So it actually ends up making it less clear, IMO, because it's not
> what the user expects (though maybe I'm not so representative of a
> typical user in this case).
>
>   (Ultimately I think the real issue is just that armatures are way
> more complex than they ought to be, even from just a normal user
> standpoint.  IMO bones should be objects, and armatures shouldn't
> exist.  But that's a discussion for another year...)
>
> --Nathan V
>
> Ahh... I'd have to check again. It's been a while since I had a look at the
low-level details.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.blender.org/pipermail/bf-animsys/attachments/20091029/37d4d25a/attachment.html>