So, the previous hypothesis was absolutely WRONG. The real issue was the
appending of .001s and such when you have a material on many objects. Each
object-material pair has its own light group now because object Plasma
modifiers can change the rules a bit.
w00t for fixage
Doobes has reported that _LIGHTMAPGEN groups can be intermittently left
attached to some lamps. This is similar to a UnicodeDecodeError we were
having before in which a cached Blender object pointer became trashed
somehow. I think in this case our cached copy of the light group is no
longer equal to what is found in bpy.data.groups, so the removal fails...
Or something along those lines.
So, we now find the group again from the list and erase that. As a final
sanity test, on blend file save, we nuke all _LIGHTMAPGEN groups.
Added the Render > Lighting modifier that lets one specify whether or not
we should forcibly use RT lights. This allows us to change the light
baking rules to allow the baking of nonanimated Plasma lights when this
setting is disabled. The modifier also has text explaining what the
lighting results should look like.
OK, this commit does a lot, and it was hard to separate the changes, so
mega-commit.
- We now export stencils in such a way that Plasma layers can be affected
by multiple stencils, theoretically matching the Blender behavior
- We don't try to animate stencils or even offer animation options. This
is nonsense.
- In our zealousness to skip over illegal texture slots, there was a bug
introduced in which we queried texture fcurve paths illegally,
potentially causing animations to be exported incorrectly. This has been
fixed.
- There was a potential issue with the animation command node's material
option in which the message could be sent to the wrong page. This has
been corrected by making the Object field mandatory for all animation
types.
This makes things incredibly more complex because Blender stores those
animations on the ObData ID instead of the Object ID data block. Dang. So,
the animation modifier's detection code had to be pretty much scrapped.
The newer code is a little hacky in places. Hopefully we can address this
soon-ish.
These rules made sense in 0.01 when we promoted modifier names. However,
these have been disallowed for over a year now. These restrictions are
sneaky and serve no purpose now.
I fail to understand why Blender thinks this is legit, but oh well...
Also, as a bonus, we no longer clobber values in the GoodNeighbor tracker.
I wonder how many bugs this will fix?
This changeset ensures that if a dependant modifier's dependency is
deleted that the aforementioned modifier is deleted as well. Since this is
something of a large change, we ask for the user to confirm the operation
before actually doing so.
It tried to bake some stupid stuff before, eg objects with no materials.
The bug was related to items being removed from a list during a loop. This
has been corrected by looping backwards by index.
Responder commands now wait until the current command finishes, even if
the command is the last in the chain. Previously, the final command would
reenable the logic modifier when the penultimate command finished.
