How to properly pass custom fragment data to StateTree and bypass the MetaHuman animation clamp in UE 5.8?

Hey everyone,

I’m working on a traffic light/intersection AI system using Mass Entity and MetaHuman Crowds in UE 5.8. I’ve hit two major architectural roadblocks regarding how data is passed and how animations are handled, and I’m looking for the “intended” way to solve this.

1. The FMassFragment Linker Error To make the entities stop at a red light, I tried creating a custom FMassFragment to hold the traffic light state so I could evaluate it in the State Tree UI. However, since StructUtils is deprecated in 5.8, FMassFragment isn’t exported with __declspec(dllimport) for Blueprint reflection. Adding USTRUCT(BlueprintType) directly results in an LNK2019: unresolved external symbol Z_Construct_UScriptStruct_FMassFragment error. This completely kills the workflow of exposing custom fragment data to the State Tree editor.

2. The Hardcoded Animation Clamp While looking into the animation side, I realized UMetaHumanMassSimpleAnimationProcessor forces ISM animations into a 0 or 1 index based purely on velocity:

C++

AnimData.SequenceIndex = FMath::Clamp(AnimData.SequenceIndex, 0, 1);

Because of this clamp, if I try to bake a 3rd animation (e.g., a “waiting at crosswalk” idle at Index 2) into a single MetaHuman Collection and set it via a State Tree Task, the processor relentlessly overwrites it back to 0 or 1 every frame.

Current Workaround: Right now, my hack is splitting behaviors into multiple MetaHuman Collections. Since each collection has its own bake set, index 0 means a completely different idle animation depending on the collection, bypassing the clamp issue.

My Question: Given the 5.8 StructUtils deprecation and the hardcoded ISM animation clamp, what is the cleanest architecture for this? Should I just write a custom animation processor that drops the clamp and reads pure C++ fragments (abandoning the StateTree UI reflection), or is there a better way to route environmental data into StateTree for MetaHumans?

Would appreciate any insights!

A few things to address here. StructUtils plugin is deprecated because the types were moved into the engine under CoreUObject. You should still be able to use them without including the plugin.

Similarly, I believe all of the Mass code has been moved into MassCore which is in the engine. You should only need to include MassCore in your {Project}.Build.cs dependencies list. It should then be accessible even though it isn’t marked for export with an API macro like you may expect. I don’t remember the true extent of what got moved in time for 5.8, but I know there was a big push to get that all completed for the release.

Finally, the cleanest version of this would be to have your own custom animation processor that removes the reliance on StateTree editor. You could copy over most of the logic from the other processor(s). Just remember to change the project settings to have the base implementation not auto-register with processing phases. If you forget that step, it will likely fight over who is controlling the animations and may become quite a headache to debug since one is stomping the other but the ordering may not always be the same between runs.

I am coming at this from the Mass side, so I am not fully aware of all the work the MetaHuman team is doing to improve their Crowds plugin and other tech.

-James