AnimationMontage preview window is breaking the AnimNotifies during runtime in PIE

Development Character & Animation
, ,
1

Repro steps is part of the issue description.

2

Steps to Reproduce
I have a simple animation montage for attack and it contains multiple notify states. These notify states are created as a C++ class derived from AnimNotifieState. In the implementation I’m printing a message in NotifyBegin and NotifyEnd. Also there is a condition so the animation preview does not print these messages.

Then I:

  • start PIE
  • perform the attack animations
  • the console shows both exactly 2 messages: one “OnNotifyBegin” and one “OnNotifeEnd”
  • I close the PIE and open the animation montage in the editor
  • play the animation in the editor window (animation must be playing so the issue occurs)
  • start PIE again
  • perform the attack animation
  • the shows that the notify is either not received or received twice.
    • sometimes it shows only one “OnNotifyBegin”,
    • or it shows one “OnNotifyBegin” and two “OnNotifeEnd”

We did not tamper with animation instance runtime in c++ in any way so its should be reproducible on vanilla engine.

What might be causing this issue?

I would not mind if the preview would be automatically paused during PIE. But this way it’s really uncomfortable that one must bear in mind to pause/close the animation window.

3

Hi, when you run into this behaviour, is the animation editor still open or has it been minimized/backgrounded?

If the animation editor is minimized or the tab has been backgrounded, the animation editor preview scene shouldn’t be ticked, so you shouldn’t see the montage being updated, generating notifies, etc. But if the animation editor is still open and visible somewhere, the preview scene will still be ticked, so you would get duplicate notifies similar to how you describe (although I would expect two sets of begin and end notifies in that case).

4

Hi Euan,

Thank for your reply.

This happends when the animation (montage) editor is open, the window is not minimalized and also the animation must be playing.

I would expect the same behavior as you. Both notifies from the game world and the preview world would come. But that is not what I have observed - even worse that the game world notify might be missing resulting into broken gameplay. I would suspect that the handling of the notifies is not thread safe.

Sorry for late reply, the issue is still relevant.

5

Could you attach screenshots to show what the notify blueprint events look like, and the code for the custom notify class?

A common problem with notifies is that they aren’t instanced. So there is only ever one object for a notify, even when the notify is triggered from different places. That causes problems if you try to store state within the notify. That might be what’s happening here; if there’s any state data within the custom notify, and that’s being used as part of the validation you mentioned for when to print the messages, you would run into problems.

6

That’s a new information for me. Also you were right.

I assumed that only the skeleton from the game world would be part of an actor with specific component. That was used to determine which one of the skeleton is the preview one. In the OnBegin method I have cached the pointer to this component. That means that if the preview world notify would come after game world notify, the value would be cached. Since I’ve used the existence of this component as a check for preview world, both notifies would be processed this way.

I will fix that by adding this condition

[Image Removed]Is this the best solution? The drawback is that you have to write this condition in basically all the game logic notifies.

Thank you for you assistance Euan.

7

Yeah, that makes sense as to why you were having issues previously. Your solution makes sense, that way you don’t have to cache any state. The other option (which I would recommend for more complex logic) is to have the logic and state live somewhere else (on an actor, component, etc) and just have the notify trigger that logic. But I think for this specific case your approach is good.

We have plans to support instancing of notifies via an opt-in system at some point in the future with UAF. It hasn’t been supported previously due to the overhead, since each notify is its own uobject, but instancing has been requested regularly enough that we want to do something to allow it.

8

I see. If I would do it via some delegates, the preview animation would not be registred and the preview world would not fire my logic as well.

Oh, you plan to do it in the future, great news.

Thank you for your time once a again a will close this issue.