Pull request #114 was causing messages that could wait but had no child
messages to always have waits generated for them. This was causing some
responder states to never be marked completed. This ensures only
messages that need to be waited on have waits generated for them.
Messages that must be waited on include:
- the last waitable message if the responder is attatched to a PFM
- the last waitable message if it's the last message in the state
- any waitable message that has a child message
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.
In order for a python script to be notified that a responder attribute
has finished executing, we have to have a callback notify message in the
responder state. Cyan seems to require the artist to do this by hand,
but that seems like such a common operation that we'll add a callback at
the end of every state of any responder linked to a Python node. Cyan's
approach is somewhat more flexible in that you can call back at any
point in the responder, but that seems a bit excessive.
Given that the Plasma World (read: age) is defined per scene, it seems
appropriate to limit the export to the current scene. Other scenes could
potentially have other age definitions...
This introduces the ability to version nodes. Responders have been
bumped to version 2. The difference is that v2 responder nodes maintain
a list (hopefully) all responder states on the responder itself. Each
state has its own socket and displays its index for usage in python
scripts. For better predictability, any states that are only linked to
another state's gotostate socket will be exported at the end of the
state list.
Arbitrary data from a material's layer flags were able to creep into a
DSpan's criteria, causing geometry that should go into the same span to
spawn a new DSpan with an identical name. Only one of the DSpan objects
would be exported, and Uru would either show crazy stuff or crash as a
result.
On the surface, this allows lightmaps to be exported as PNGs. However,
it also includes a light refactor of image exporting to facilitate
requesting export formats and the targeting of plImageLibMod. This
should better enable #96.
Due to our disabling of texture baking when lightmapping, Blender would
not be able to cast light through transparent materials. Now, we revert
back to something resembling the manual method of lightmapping from the
bad old days of PyPRP.
Do note that because we attempt to batch object baking as much as
possible, I have disabled baking lightmaps to transparent objects.
This is because the transparent objects would need its textures disabled
for it to be baked to, but with the textures disabled, the renderer
would be unable to correctly determine the object's transparency. D'oh!
It would be possible, I suppose, to move them into their own batch, but
that makes the state machine a bit more complex. It would be better to
wait for someone to need that functionality, I think.
