Unable to control Motion Events during AnimGraph Transitions

Hi folks,

My team and I are making a game in which we have characters that use attacks and abilities. We have set up a number of actors, motions, and an animgraph to drive the logic for using these attacks.

Several of our motions have been given a TwoStringEvent called “effect”, which is fired when the attack logic should execute. This is the frame when the arrow is loosed, or the sword would pass through an opponent, etc.

Players often like to change their mind during an attack and use a different one. Some of you may know this as “animation cancelling”. Our animgraph will blend their character from their current motion “A” to the new one “B” over 0.3 seconds.

However, while blending:

the “effect” event from motion “A” will still fire!

This typically causes the logic for attack “B” to execute, without having the usual wind-up time. This issue is especially pronounced with attacks that have a large wind-up time.

We cannot give each motion a different “effect” event name to distinguish which one we listen for, as sometimes actions share a motion (attacking with ice arrows versus acid arrows).

It is not clear to us that there is a solution to this without modifying the emotionfx gem. Our plan would likely be to add an option to control whether an event can fire while the motion is being blended out.

This seems like a straightforward use case, so I would like to know if there is a known workaround. If not, I would like to know if there are plans to create one, or best advice on how to proceed.


An update: we seem to have resolved the issue! :sweat_smile:

We were using motion event filters properly, but two things caught us off guard:

  • The transitions we needed to configure were not the ones we expected. Bouncing through some 0.0s duration transitions in our graph caused the next transition that had a duration to be elsewhere in the graph, and it is transitions with a duration that determine the event filtering mode.
  • The hub node we were using for attacks needed to have all incoming and outgoing transitions set to ‘servant’ mode. Our attention was on internal transitions within the hub node, and those didn’t matter.

Hopefully this note can help someone else in the future!