AnimBlueprint Talkback w/ C++ Code

  1. I think this bit of documentation will be helpful, but can you break this out into it’s own question and go into a bit more depth about what you’re wondering about?
    Cheers, Michael Noland

So I’m following up from an old question. With unrealscript, we had the ability for AnimTrees to “listen in” for a specific variable. If the value in this variable changed in any way, the corresponding blend node(s) within the tree having the same node name would be updated as well. Now I read the link provided, and it describes similar behavior with blueprints in some light detail.

However, can I accomplish similar functionality in C++? Can I create a variable that an animation blueprint will attempt to “read” within C++ code? I’m specifically asking about this as it pertains to code, not blueprints.

It’s not that I have it out for blueprints or anything like that :), it’s just that having worked on my projects in UDK over time, I have found kismet to be inflexible to certain issues like moving nodes and corresponding actors across streamed levels, and unrealscript having two lines of code replace several dozen kismet nodes needed to do the same thing, etc. With unrealscript, I could code an actor with custom behavior, and just simply place it in the level and/or migrate it across multiple streamed levels with no muss no fuss. And duplication wasn’t a problem either, because each copy of the custom actor possessed innate functionality. It was coding and behavior “that just worked”.

Whereas with kismet, I had to keep spelling it out each time, and getting these annoying prompts anytime I moved a kismet-connected actor to a different level/streamed level. So as you can imagine, my bias is heavily towards coding.

That said, my question pertains to how an animation blueprint would talk to C++. Do animation blueprints possess the innate ability to have “listeners” for specific variables defined in C++, or for C++ to fire a “notify” into Rocket animblueprints when a variable changes, and thus update the animblueprint that way?

Hi Markus,

If you want to ‘push’ data from C++ to your Vim, you would create a UVimInstance subclass in C++, and add any state variables you want to set. When you create a Vim, you select a parent class, and you’d pick that class instead of UVimInstance (if you have an existing Vim, you can Reparent the vim to target the new class).

Some actor will have a skeletal mesh component that references your vim; from there you can push whatever data you want by doing:

if (UMyVimInstance* MyVim = Cast(SkeletalMeshComponent->AnimInstance))
{
	MyVim->MySpeedProperty = MyVelocity.Length();
	etc...
}

You could also do the same thing with a weaker binding and no C++ subclass using UKismetSystemLibrary::SetFloatPropertyByName et al, assuming that the Vim contains some variables added in the blueprint.

If you want to ‘pull’ data ,you can use GetPawnOwner in the Vim’s event graph, and Cast it to your game-specific pawn, and access game-specific properties that way as well. In this case, you have a dependency between the vim and the code, but there is no ‘level to level’ dependency, and you shouldn’t run into the same sorts of issues you had with Kismet in UE3.

For either path, you don’t need to ‘notify’ the vim that things have changed, it is re-evaluated every frame.

Cheers,
Michael Noland