FText: Expose multiline property in blueprint metadata

If you have an FText variable in C++, you can turn it into a multi-line field by adding the meta uproperty “multiline=true”. If you have an FText property in blueprints, you can’t add this same meta property to the variable details panel. Please add this in. My work around is to create a wrapper for the FText variable in C++.

I shall look into the code and add a checkbox for that. Ill post the PR when Im done :smiley:

Someone (projectgheist) already submitted a PR for this and it was accepted. This feature will be in 4.16 :slight_smile:

Cheers,
Michael Noland

[MENTION=2289]Michael Noland[/MENTION], what are the chances of metadata being exposed generally to blueprint variables/functions? I realize Epic want to keep things in blueprint as simple as possible, but it could be added in the advanced section. Having the ability to add arbitrary metadata tags to blueprint fields would be great for enabling more tightly integrated editor plugins. I’ve already wanted this for a couple of my plugins and have had to either give up on some functionality, or hack in a workaround by hijacking an existing blueprint-exposed flag for my own use.

1 Like

It’s not a priority right now but I don’t have any conceptual objections to allowing it. The way that individual ‘properties’ of BP variables are exposed is kind of creaky, with a bunch of custom Slate code for each line. The whole thing needs to be refactored to use a proxy UObject and regular details panel, which would make adding new features there much quicker.

Cheers,
Michael Noland

Out of interest, what were some of the use cases you had? Metadata is only present in the editor, so practical applications seem limited unless it’s for editor extensions or if you have a custom build/bake step that would transform the data into a more durable form.

Cheers,
Michael Noland

Capability of introducing custom metadata easily, like the GameplayTags we have now, would be heaven for plugin developers.

@Bruno, still looking for a concrete use case. You can already create a custom type and expose that to BPs, and scan for all instance of that type (or just use a FGameplayTag/FGameplayTagContainer property and scan for people who implement something in a namespaced tag region). Tagging specific properties with metadata is a bit more special case, and the specific kind of metadata (UMetaData) we’re talking about is editor only which further limits the utility.

Cheers,
Michael Noland

Yep, when I said plugins I meant either editor tools, or runtime plugins that also contain custom editor features.

I have one work in progress plugin for realtime plotting of property values during PIE. One possible use for this was to limit properties displayed in a dropdown list to only those marked with a custom ‘Volatile’ metatag, so that the dropdown wasn’t flooded with all sorts of properties that it didn’t make any sense to plot over time. That way users could add this tag to properties in blueprints that they wanted to be available for plotting.

At one point I was working on a project where I created a custom blueprint type (I mean deriving from UBlueprint) which had it’s own editor, incorporating a custom node graph alongside the regular blueprint tab. I wanted a way to allow the user to control which of their blueprint variables got exposed for use in my custom graph, which then resulted in some special binding information for only those properties being added to the generated class. I hijacked the ‘Expose on Spawn’ meta, but obviously that’s far from ideal.

Far from common use cases, granted, but I’ve no doubt I’ll eventually have more, and I’d have thought it would be fairly straightforward to implement. The addition of an editable array of metatag key-value pairs after the ‘Defined Property Flags’ section would be enough. I could look at a PR for that when I find some time, if it’s something you’d consider.

Of course a more structured interface would be nice, like you say some automated generation of details panel rows, but that would require some kind of meta-meta-data defining known meta tags and what form they take, which would be a much bigger task and is perhaps getting a bit too crazy.

Yeah those cases make sense.

Sorry, I wasn’t clear RE: refactoring it; I didn’t mean a custom registry for providing a nice user interface for custom metadata; doing the refactor would make it easier to expose metadata at all, as instead of adding a bunch of custom slate, it could either just be a reflected array of structs or a tmap, along with a couple of lines of code in a read/write function that copies the value to/from the persistent storage in the variables array.

Cheers,
Michael Noland