When a responder node is linked to a Python file node's
ptAttribNamedResponder socket, it will now export with the same name as
the node itself. In that way, the responder can be addressed in the
attribute's value mapping in the Python script itself.
If a sound message was being sent to a random sound modifier, the
responder tree might crash on export. This fixes that particular problem
and adds a mitigation to the responder code itself. Remember kids that,
in Python `None and True` is `None`...
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.
This fixes an issue in which responders would get "stuck" at the end if
the last message had callbacks AND the responder was not attached to a
Python node.
Inspired by Unreal Blueprint's drag link+create list functionality. I
realize Blender has a few operators that do different parts of this job,
but they don't provide this well-polished functionality.
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
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.
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.
Adds a framework for dealing with deprecated logic nodes. First
implementation is for Responder Commands, which hooks the messages
directly onto the Responder States. Note that the old socket definitions
are left alone because the upgrader will need that data.
This commit removes the ability for Responder State nodes to specify
Responder Command nodes. Now, Responder State nodes reference Message
nodes directly. Messages that support sending callbacks can now
reference other messages as linked outputs.
Note that old node trees are currently broken and will need to be
reworked by hand. TODO is to automatically upgrade those old command
based node trees. Also, LOGICWIZ code using command nodes needs to be
updated.
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.
Also, this fixes a bug with auto-expanding input sockets. It turns out
Blender was renaming them behind the scenes. We now ensure that we ignore
this renaming -- fixes many potential gotchas.
This has some simple attribute nodes for example purposes. Unfortunately,
this is so far UI only. More node types need to be added, then we can
begin working on exporting.
ResponderCommands can now reenable clickables by making a connection. This
will only work for the client who clicked on the clickable however. It's
still a useful feature regardless.
Also fixes some bugs when adding commands onto a command with no wait of
its own that waited on another command.
