MoBuPy #6

Hey, were you wondering just how much Python sucks in Motion Builder?
Try this, in either Python, or Idle:

>>> import time
>>> time.strftime("%D %T", time.localtime())
Now try the same thing in Motion Builders Python window,
but do it without anything
important (or time consuming) loaded...for me,
it blows up (Unknown software exception
(0xc00000d) occurred in the application at location 0x78148b5

Thank g_d they have an easily scrolled and searchable
output window -- oh wait, they don't...

...well, at least time.ctime() works...

MoBuPy #5

LoadBegin takes 2 arguments: a filename, and a 'merge' boolean;
Strangely enough: setting merge to False doesn't wipe out story information
(like existing character tracks), but setting merge to True does.

Oh MoBu, why dost thou screw with me?

To recap:

mgr = FBFbxManager()
lbv = mgr.LoadBegin(filename, False) # Really merge, don't trash existing data
set anim/elem states if any
lv = mgr.Load()
ev = mgr.LoadEnd()

If any of lbv, lv, or ev is False, this didn't load...

MoBuPy #4

1) ProcessNamespaceHierarchy doesn't work as far as anyone on the web can determine;
2) This means that if you want to do what it does, you have to do your own recursive
descent of the models, rig models, and effectors AFTER you get them by index and
individually ProcessObjectNamespace them

MoBuPy #3

Since sys.exit(any) causes all of MotionBuilder to shut down,
is there any quit method that gets you back to
the Python Console top level?

One can always just 'raise RuntimeError', but it's pretty ugly...

Also, FBMessageBoxGetUserValue always treats the
second button as the abort case,
so if a user updates the value of the text,
it reverts to the originally
supplied (default) text before it returns.

This is anti-helpful.

MoBuPy #2

Well, Python in Motion Builder is a joy to work with.
And No, I don't really mean that.
Say you have a library, let's call it 'mobu'
(which you've written to hide some of the
C++ knowledge/complexity resulting from the swig interface)
that lives in someplace a little off the
beaten path (ie: not in the default PYTHONPATH),
so normally, our client app would
have the following:

import sys
mobu_home = 'z:\net\libdir'
sys.path.append(mobu_home)

import mobu

. . .

Well, this has two unfortunate side effects:
1) every time you drag this client script in,
sys.path will have mobu_home appended to
the end of your sys.path -- go ahead,
bring up the python window, print sys.path after
each time you drag this in...
it's fun to watch it grow endlessly...

2) It doesn't necessarily get the latest (current)
version of the library (I do cross platform
work -- I edit/test (when I can) on a linux
system on the network, and then run apps on
a windows system that has nfs mounted the
target directory where the library lives).
I don't think this is a Windows or NFS problem,
because the following workaround appears
to alleviate the problem(s):


import sys
mobu_home = 'z:\net\libdir'
# Only extend sys.path if we have to...
if mobu_home not in sys.path: sys.path.append(mobu_home)

import mobu
reload(mobu)
# This has to happen every time, otherwise the Python instance in mobu thinks the copy it
# loaded last time is still current
# The good news is that the 'if' above should speed things up in the course of a long session