Ok so I checked around some more and it turns out it’s been like this for ages and it might be intended behaviour, it just seems badly designed and doesn’t have behaviour consistent with other primitives. At this point though, it might break too much in current projects for it to be worth changing it, since you can work around it easily. So this would be more of a design decision than a bug fix.
To see the issue, create a BP with a skeletal mesh, enable collisions, enable “Simulation Generates Hit Events”, and attach an event to the OnComponentHit event and add a breakpoint on it so you know it’s being called. Go to the skeletal meshes physics asset and turn on “Simulation Generates Hit Events” on a few of the individual bone bodies. Now play and make something hit those bodies so you know everything’s set up right and the event is firing.
Now go back to the skeletal mesh component on the BP and turn off “Simulation Generates Hit Events” and instead call SetNotifyRigidBodyCollision(true) on the skeletal mesh during begin play. Now play again and the hit events won’t fire. You would expect that SetNotifyRigidBodyCollision() would enable hit events the same as it does for static meshes, but it doesn’t.
What it’s really doing is overriding all the notify bools on the individual bone bodies (TArray Bodies member var) , rather than setting it for the skeletal mesh component itself (FBodyInstance *BodyInstance member var, which is the one you see in BP defaults).
Skeletal mesh component has other functions specifically for setting notify on bone bodies, it would be more useful and consistent to have SetNotifyRigidBodyCollision() affect BodyInstance only, and leave the individual bones alone. So the fix would be to change the code to this
void USkeletalMeshComponent::SetNotifyRigidBodyCollision(bool bNewNotifyRigidBodyCollision) { BodyInstance->SetInstanceNotifyRBCollision(bNewNotifyRigidBodyCollision); OnComponentCollisionSettingsChanged(); }