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”.
I don’t understand why it should be very difficult to support. UHT writes support for new UTYPEDEF() and devs will just mark their typedefs with UTYPEDEF() like they are used to with other things.