Issue with new stricter UHT and USTRUCTs
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:
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.
asked Jul 26 '17 at 02:19 PM in Bug Reports
In the source code is the following specifier that you can use instead of BlueprintType:
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.
answered Jul 26 '17 at 07:39 PM
Follow this question
Once you sign in you will be able to subscribe for any updates here