The default definition of `pre_export()` (for documentation purposes)
was hiding the real default implementation of `pre_export()`, causing
any modifiers relying on said default implementation to export nothing.
It looks like simply attaching a lamp to a group already has fairly
major implications for how it's exported. If you're adding a lamp into
a group, then you are basically saying, "I only want to affect these
specific objects.", so marking them as movable (meaning, "apply me
to all objects") doesn't really make sense in that context.
If we've unleashed Satan on a material, he will perform his dark magick
on the material colors. Therefore, we need to prefix the satanic
materials with something other than "RTLit_" lest the plain old runtime
lit materials be infected by the prince of darkness.
The dumb string lookup probably worked most of the time, but with recent
changes that can cause layers and materials to be renamed to things not
matching the pattern exactly, it's better to explicitly lookup the keys.
This will prevent Dynamic Text Maps from seemingly "breaking" for no
reason just because the lighting strategy changes.
I'm probably late to the party, but I have found that PotS can't handle more than 8 RT lamps on one material. This might vary by target engine, though, so no failure pronouncement is made.
In a previous changeset, the Advanced Logic modifier was changed to
defer exporting logic until the very end of the export process. This
means that many nodes are designed with the assumption that all
non-logic PRP objects are fully exported by the time they are exported.
LogicWiz modifiers, however, violated this assumption by exporting
during the main export() phase.
So, this adds a new `pre_export()` phase for all modifiers that lets
them generate logic trees and even entirely new Plasma Objects safely.
Futher, old LogicWiz modifiers have been tweaked to not leak junked
objects if the export fails in the middle of those modifiers.
This will allow us to automate releases with the Blender 2.79
"experimenntal nightly" codebase. This is great because the newer
Blender uses Python 3.7 (instead of 3.5). This pulls from my fork of
Blender, which has a number of build improvements added on top.
