"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.
Path of the Shell did not like my fancy metaprogramming tricks for
defining an AgeSDL Python class that contained characters that are
illegal in Python identifiers. So, now, we revert to just using a
standard class declaration.
That means that we need to strip out any illegal identifiers from the
age name first. A legal Python 2.x identifier is constrained to the
ASCII alphanumeric characters and the underscore with the stipulation
that the first character cannot be a number. To illustrate this to the
artist, we alert the age name property field if an illegal character is
found in the age name. We also alert on the underscore, which is now
used as a very very special replacement character. In the case of an
illegal character, an error message is shown in the UI with the correct
AgeSDL name.
Of course, I hope no one really uses those illegal characters and this
is just more fulmination on my part...
