UHT Improvements

General Feedback & Requests
, , ,
1

Hello,

I wanted to request some features that might make for a more robust UHT/UBT. I’ve been having a heck of a time trying to navigate all the complicated rules surrounding getting it to work with the data structures I make.

Suggestions:

  • typedefs support
    A deep scan through all the headers and includes for a typedef keyword, maybe? Typing out the full name of structs, or in the case of TArray, PARAMETERIZED structs – repeatedly – is kind of debilitating on the spirit and the hands (carpal tunnel)

OR – if a deep scan is too resource intensive, maybe a letter in front of the TYPE… like TDMyTypeDef – so that UHT is alerted to this being a typedef and will go searching for it. Thus resource use from the tool is expended ONLY when it’s necessary.

I saw this feature requested in another thread, but it’s been sitting there languishing for the better part of 6 years now. UHT is in desperate need of this upgrade… so adding my +1 to it.

  • MACRO Support
    Another one of those simplification things. It’s frustrating typing out verbose UPROPERTY or UFUNCTIONS or copy/pasting from some other variable every single time I want to expose something to reflections.

I had hoped that by using something like GAME_STRUCT() or GAME_ENUM() macros, I could simplify all the verbiage involved in setting up even the most rudimentary data structures in unreal code, and not having to repeatedly type out all this stuff in UMacros.

I know it would be so much easier and beneficial to type out something like GAME_ENUM(MyEnum) instead of “UENUM(etc, etc, etc) enum class MyEnum : uint8” so that an enum type is generated that reflection would support. (My understanding is that anything other than uint8 is not supported?)

  • TObjectPtr Support
    To this day, I am still perplexed at why this is not implemented yet. There has been such an aggressive push into using TObjectPtr instead of raw pointers everywhere else in C++ code. Why isn’t this design philosophy at least consistently applied in its own tool, if it’s essential to memory management and garbage collection? If raw pointers are needed for some reason, couldn’t it just analyze the TObjectPtr keyword and swap it out for a raw pointer in the code at runtime? Just throwing stuff out there…

  • Consistent Pointer Support
    Where and when raw pointers can be used in this tool are inconsistent. UHT throws errors if STRUCTS have raw pointers, but not classes. Why? They are the same data structure, just with a different keyword, right? (Except members by default in structs are public, not private?)

  • Struct Function Support
    And in this same vein, struct functions should be able to enjoy the same UHT support that class functions do. I am not sure why UHT doesn’t treat them the same?

Thank you for your time :slight_smile: