The commentary about PointerProps and update callbacks appears to be
incorrect. Maybe it was broken in a beta release of Blender 2.79? Works
fine in Blender 2.79b.
Translation of the rules posted by Sirius @ https://forum.guildofwriters.org/viewtopic.php?p=73757#p73757
PotS is in worldspace when the mass is non-zero. Plasma likely detects
nonzero mass as "this object can move" and expects localspace. MOUL on
the other hand uses localspace if the object has a CI, otherwise
worldspace.
This allows for objects to print decals at runtime, like the baskets in
Eder Gira. Also, the same functionality can be hijacked for coincident
objects to exist as decals. This is basically a shortcut for adding hack
Z-flags to the base layer of a decal material.
This allows blend textures to be used for mesh transparency without
having to fiddle around too much. It was also a stab at fixing some
regressions in the MOUL engine around decals, but that bit failed,
sadly.
The soft volumes were previously in aproximately the correct location
but the exported normals were not unit vectors. This seems to have made
the resulting soft volumes not function as intended.
Explanation: The JPEG format in plMipmap does not have to be an actual
JPEG image, it can also hold an RLE bitmap. libHSPlasma currently does
not attempt to compress any images held as uncompressed data and marked
JPEG, rather, it exports them as RLE maps. Maybe a bit odd, but it
works. I guess.
This improves the panel layout and fixes the issue in which
`plShadowMaster` exported with `maxSize` == 0, causing crappy shadows
in PotS and generally no shadows in MOUL.
Previously, Korman exported cameras without the "Maintain LOS" flag
applied, allowing cameras to swing through geometry. In the token of
better defaults and easier to understand objects, all the tracking
options have been audited for clarity and their exporting to the correct
camera type.
Previously, reusing node trees required careful thought and
specification of specific nodes in the advanced logic modifier. This
tedious requirement has been removed in favor of ensuring that the nodes
themselves take into account whether or not they should generate and
attach plasma objects.
"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.
Version 2 of the python file node is now backed by a `bpy.types.Text`
datablock in the case of a file whose attributes are updated from a
backing file.
Implements the boilerplate code for compiling Python code in arbitrary
python versions and packing the marshalled data into Cyan's Python.pak
format. Since this is a lot of bp, a separate operator has been added
to both test the resulting mayhem and provide age creators an easy way
to export only their needed Python.
The only python that is packed currently is the age sdl hook file, if
any. In order for that part to happen, Python File nodes need to be
upgraded from having a string path to actually using the new text_id
field.
Age output files are now handled in all aspects by a singleton manager.
This allows us to track all generated files and external dependency
files and ensure they are correctly copied over to the target game... Or
not, in the case of an age/prp export from the File > Export menu.
Currently only SFX files are handled as an external dependency. TODO are
python and SDL files.
Further, because we have an output file manager, we can bundle all the
files into a zip archive for releasing the age in one step. Wow such
amazing. ^_^
Plasma game installs are a per-user config item and should not be stored
in a blend file. Considering that we will be adding more per-user
configs, namely Python 2.[2|3|7] install directories, it seems like a
good move to go ahead and move the games over.
The lightmap modifier is now a more general "Bake Lighting" modifier
that can control how vertex colors are baked as well. The default vertex
color baking behavior is unaffected. It is now identical to adding a
Bake Lighting modifier, changing it to bake vertex colors without
specifying a pass.
What was previously marked as transition cuts would really only cut goal
and POA tracking. Transition cutting requires the addition of a
transition ovveride. The engine supports cutting transitions on
plCameraMsg receipt by the virtual camera. The option looked sloppy on
regions (and should probably be controlled in the transitions), but it
has been added to camera message nodes for more control.
Tey're probably just a disaster waiting to happen. If you want a circle
camera, that's sufficiently advanced to require a new camera object.
Auto cameras are just a dumb helper.
