There’s not really any logical reason why this shouldn’t work, and surely it should be fairly trivial to allow UHT to check if a typedef is a supported type for reflection?
It isn’t easy to do this unfortunately and I doubt they Epic will add this ever. #define will never be added to UHT as it is way to complex due to you being able to include #define instead #define.
I’m curious, what approach did you end up taking @TheJamsh? I’m doing some periodic calculations necessary for the Vision system in an RTS game, so I opted for Bit field operations. I wanted to use replication though, and that’s when I hit the wall of typedef uint32 PlayersMask not supported by UHT.
Should I do something similar to your alternative?
struct FPlayersMask
Is there a better approach suggested? I’m concerned about the performance cost of introducing a whole struct where I really want speed (hence the Bitwise operations in the first place)
This was years ago so I’m not sure, but now I just use structs for this kind of thing and wrap with USTRUCT(), then create operator overloads if I need to.
A struct doesn’t cost anything more than the sum of it’s types in terms of memory and replication cost etc. If anything you can benefit from using a USTRUCT() because you can write your own network serialization code via NetSerialize() etc.
Well…
Today I needed exactly a typdef to not break my plugin support on UE5.0. Sadly the Epic developers decided to change the Blueprint Struct type name from “FSequencerBindingProxy” to “FMovieSceneBindingProxy”.