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

[Nathan Vegdahl]

> 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

Ah, excellent!  Thanks a bunch.  I am too stupid to find obvious
things, it seems...

--Nathan

On Wed, Oct 28, 2009 at 12:15 PM, Joshua Leung <aligorith at gmail.com> wrote:
> 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.
>
> _______________________________________________
> Bf-animsys mailing list
> Bf-animsys at blender.org
> http://lists.blender.org/mailman/listinfo/bf-animsys
>
>