This isn’t really a bug as such, but I think there is a problem with the 4.17 change which gives the following UHT error:
Error: Cannot expose property to blueprints in a struct that is not a BlueprintType.
This prevents defining base USTRUCTs containing common properties that should be exposed to blueprint on instances of derived structs, without making the base struct itself BlueprintType.
I use this pattern often, where the base struct is just used to provide common properties (and sometimes C++ functionality) but is never intended to be instantiated itself. As far as I can see, with this change, I am now forced to have these structs cluttering the dropdown boxes and context menus within the blueprint editor, when I really don’t want anyone to ever use the type directly.
In the source code is the following specifier that you can use instead of BlueprintType:
/// Indicates that a BlueprintType struct should not be exposed to the end user
BlueprintInternalUseOnly
I haven’t tested it myself, but there are a number of structs in the engine which use this specifier on its own, so I’m assuming it implies BlueprintType, but you can test both using it on its own and using it with an explicit BlueprintType specifier to see which one gives you what you want.
Ideally there would just be an abstract specifier for structs, as that’s what I’d recommend for a UCLASS (most dropdown menus are set to filter abstract classes). But that’s more for semantic consistency - I’m pretty sure this will achieve what you want.