Possible to extend UProperty?

Development Programming & Scripting C++
, , ,
1

I’m thinking about making a plugin for sql lite and ue4. The way I would like it to work is it would be a code first solution where any class that inherits a special base class would automatically have tables generated for them.

However it might be necessary that properties need additional info associated with them for things like indexes or relationships.

So this led me to the thought it would be nice if I could some how plug that information in UProperty but I don’t know if that is possible. In c# it wouldn’t be difficult to add my own data annotations but in C++ I’m pretty sure the build tool is used to parse this data.

Any ideas? Is there anyway I can extend UProperty in a plugin? I thought about using categories but I think that would be rather hackish.

2

I haven’t look at how it works, but take a look at UnrealHeaderTool and ScriptGeneratorPlugin. UnrealHeaderTool parses the tools and looks at all the U macros (among other things), while ScriptGeneratorPlugin is a plugin that can be called by UHT.

3

Looks like field’s can have meta data associated with them, so I’m going to experiment going that route, I was able to compile this into UE4 Property:

Meta = ( DisplayName = “Cool” , Test = “Cat”, Dog = 3 )

And it looks like there are functions to grab this data.

4

This is the correct rout to go.
You can hang all the key/value pairs off the metadata section.

5

Unless something changed, meta properties are stripped in non-editor builds.

Adding new keywords should be possible but then you won’t be able to make plugin out of it, because it’s implemented rather deep inside the engine/UHT.

6

I might be able to still get away with this. I really only want the information for Creating the SQL tables. My idea currently is to create a DB asset, that when you import would run through all these properties and create the correct tables, and database. At that point, I might need this data at run time, and as long as it exists when the editor is open that might be enough.

7

For posterity, there’s documentation here on how to extend Unread Header Tool: Unreal Header Tool for Unreal Engine | Unreal Engine 5.3 Documentation

8

The issue was more about creating a new asset type than exposing a new property.

Also in the doc:

Adding new engine types, property types, or keywords should be approached cautiously, as adding any of these requires a large number of changes to the engine to properly implement.

It means:

  • Editor changes
  • Not a plugin

You should not do that unless you have a really good reason.
Valid reasons could be exposing common template types, the first that comes to my mind are TTuple and TPair, it could allow blueprint users to return many outputs without reexecute a pure node, means better performance. Cpp user’s would also benefit from UProperty with TTuple.
Other reasons:

  • Adding parameterized class constructors to support DI in ctor.
  • Expose cpp Template to UClasses.
    Those are much more complex case.

A recent example (5.3) TOptional has partially been implemented by epic.
Someone else also did Exposing templated properties to UPROPERTY