This fixes an issue in which responders would get "stuck" at the end if
the last message had callbacks AND the responder was not attached to a
Python node.
Inspired by Unreal Blueprint's drag link+create list functionality. I
realize Blender has a few operators that do different parts of this job,
but they don't provide this well-polished functionality.
"Improve" is not quite the correct verbiage here because there were bugs
in the old code. The main issue is that any SceneObject with a
plPythonFileMod attached MUST have a CoordinateInterface attached,
otherwise the object would be invisible in game. Further, there were
some unreported oversights with regard to auto-generated modifiers that
have been fixed.
This isn't the best fix in the world. We don't really know what the user
did to cause the failure because of how abstract this code is. A proper
fix would be to ensure region modifiers can't get attached to non-mesh
objects. That won't fix already "broken" stuff in blend files without
being naughty/destructive, however.
Unfortunately, this does not prevent "DAG zero..." from appearing
period. Rather, it just overwrites any junk printed to the console
during the export. The ANSI version is rather limited compared to the
Windows version and completely untested...
Due to memory management issues, it is likely impossible to remove a
node in its own init() callback without crashing Blender. Now, we will
deactivate any output node operators if an output node is already
present in the tree.
Recall that PFMs are added as modules to the global modules dict.
Therefore, module names must be valid Python 2.x identifiers. This is
handled well for age names, but we've been neglecting to handle it for
PFM names. So, when Blender adds ".001" as a suffix to a duplicated
object, any attached PFMs will go down in a firey dust explosion.
Generally, with the unhelpful error message: "NULL result without
error in PyObject_Call".
This is like the Package Python operator in that the artist can now
export the loc data independent of the rest of the age. The difference
is that due to the extremely different loc formats from PotS+UAM to
MOUL, we can't easily allow the user to specify where the data will be
exported to. So, we only allow this operation in the context of a game.
Two problems were fixed here:
- Materials were always exported unconditionally, meaning that we were
wasting time processing the same data over and over. This could have
generated "interesting" data (eg multiple hsGMaterials and friends with
the same name) that Plasma would have barfed on.
- Lightmaps were being applied to the incorrect materials
See the comment for details. I've been seeing this crash since we
started doing fancy idprop stuff. Of course, my test blend has always
had bleeding edge junk and has crashed left, right, and center. For more
fun, follow the progress on D4196.
If a file's data is already available in Blender, it might be changed.
For example, an internal text datablock or a changed text file. We need
to use those overrides.
