It would be nice to mark FMovementProperties (and by inheritance, FNavAgentProperties) as Blueprintable. I can pull a FNavAgentProperties out of a movement component with Get Movement Capabilities, but without a break node, I can’t actually get information about, e.g., navigation agent radius/height in the blueprint.
Given that all the uproperties of those structs are marked BlueprintReadWrite, my assumption is that not making the struct itself blueprintable was just an oversight.
It’s actually the other way around - it’s more like FMovementProperties.bCanCrouch, and others, should not be BlueprintReadWrite. But I’ll look into it. It seems there’s no harm in making FMovementProperties a BlueprintType but FNavAgentProperties is a different story since one would expect that changes to FNavAgentProperties properties would automatically update agent’s navigation properties, which would not be the case currently.
Cheers,
–mieszko
In that case, wouldn’t it make sense to still mark the struct Blueprintable, but also mark the problematic FNavAgentProperties fields as EditAnywhere,BlueprintReadOnly? That wouldn’t allow the in-blueprint construction or modification of a FNavAgentProperties to pass to Set Movement Capabilities, but that already isn’t possible, so no big loss.
That would indeed make sense 
I’ve already filed it and you should see it in 4.9.