Editor search does not include variable default values

On our team we’ve run into some problems, particularly around refactoring gameplay tags or finding all usage of gameplay tags where any values baked into the editor are not included in search. This hurts discoverability for any kind of data configuration. Imagine for instance a map of gameplay tags to widget blueprints that a widget uses to determine which subcontent to instantiate at run time and to display in conjunction with a selected state, represented by that gameplay tag.

If you try to search for the gameplay tag, you will find blueprint instances of it, but you won’t find the references saved into variables. Would this be possible to support?

Thanks!

Steps to Reproduce

  • Create a blueprint (actor, widget, etc)
  • Add a GameplayTag variable to it
  • Compile the blueprint
  • Set a recognizable default value into the new variable
  • Search in the blueprint for that value or across all files
  • observe: the value does not appear in the search results

Hey there! I implemented searchability of Gameplay Tag default values recently. It was requested in the past and we created UE-275088 for it.

The fix CL is 42591695 on //UE5/Main and will roll out in UE 5.7, but since it’s small you can attempt to backport it into 5.4. Here’s the matching GitHub commit: c5669287b0872870713209292e13dd743a1bbc31.

After pulling that fix, any loaded blueprints their default values for GameplayTags (and also, any default value in a struct) will be searchable. Once resaved, their struct values are also searchable even when the asset hasn’t been loaded yet in the editor session.

Correction: resaving assets shouldn’t be necessary. The default values of GameplayTags were already being ‘indexed’ (stored as metadata), just not found as search results. So if you pull that CL things should work, though I’m curious to hear your results.

Hmm, since you mentioned maps I did some more testing but it seems one case is still uncovered:

  • GameplayTag variable: searchable
  • GameplayTagContainer variable: searchable
  • Map with GameplayTag as key type: fails
  • Map with GameplayTag as value type: searchable

I’ll investigate and see if we can fix that as well for UE 5.7. If I find a solution in the short term I’ll update you here. The other cases mentioned above works, so I hope that helps you a bit already.

Created UE-317269 for public tracking purposes but I’ll give you an update in the coming days here as well.

Thanks! I’d love to have a solution that can be backported to 5.4 for our team, especially if it can handle the map key case. Appreciate it.

Would you be interested in short-term experimental fixes too, like a P4 shelf, or prefer to wait until it’s merged into //UE5/Main?

I’m asking because I have a solution near ready, but code review may take a while.

I expect 2-3 weeks to merge it in, but I’ll give an update if it’s going to take longer.

Hey there, I underestimated the distraction I would experience from Unreal Fest Stockholm. I expect to merge the fix in early next week. I can’t share a shelf in the meantime since the WIP work is on a private stream.

Be aware that the fix makes TMap keys searchable for blueprint defined variables, but not natively defined ones. Native defined variables aren’t indexed for searching which is an unfortunate limitation of Find-in-blueprint search, but indexing default values of even more variables would increase file sizes substantially. That was the reasoning in the past not to index those.

In the meantime, UE-317269 shows the latest state. However, I also plan to give an update here.

We’re doing final tweaks on the TMap key searchability. Will keep you posted.

Good day, the fix is merged in at CL 47253201. This will make keys in blueprint defined maps searchable.

Edit: Now also as GitHub commit 629a6a400de18e5a9f7c0a62a44e76020658e443.

About this: “the child widget has a map of gameplay tag to widget class as an instance editable property.”

Is this a native property, so defined in C++? Currently Find-in-Blueprints won’t search those. Internally, this was a choice out of necessity because the size of Find-in-Blueprints metadata would significantly increase.

The following callstack is what gathers that on asset save, but for blueprint only:

	UnrealEditor-Kismet.dll!BlueprintSearchMetaDataHelpers:SaveVariableDescriptionToJson()
>	UnrealEditor-Kismet.dll!BlueprintSearchMetaDataHelpers::GatherBlueprintSearchMetadata<TCondensedJsonPrintPolicy<wchar_t>>(const TSharedRef<BlueprintSearchMetaDataHelpers::TFindInBlueprintJsonStringWriter<TCondensedJsonPrintPolicy<wchar_t>>,1> & InWriter, const UBlueprint * Blueprint) Line 1298	C++
 	UnrealEditor-Kismet.dll!BlueprintSearchMetaDataHelpers::GatherBlueprintSearchMetadata<BlueprintSearchMetaDataHelpers::FFindInBlueprintJsonWriter>(const UBlueprint * Blueprint, int FiBDataVersion) Line 1394	C++
 	UnrealEditor-Kismet.dll!FFindInBlueprintSearchManager::AddOrUpdateBlueprintSearchMetadata(UBlueprint * InBlueprint, EAddOrUpdateBlueprintSearchMetadataFlags InFlags, EFiBVersion InVersion) Line 2741	C++
 	UnrealEditor-Engine.dll!UBlueprint::PreSave(FObjectPreSaveContext ObjectSaveContext) Line 416	C++
 	UnrealEditor-CoreUObject.dll!UE::SavePackageUtilities::CallPreSave(UObject * Object, FObjectSaveContextData & ObjectSaveContext) Line 663	C++

Hey there, apologies for your last question being unanswered. I forgot to ask someone to watch over this thread while I was out of office.

I’ve logged the feature request internally. We don’t publish those on the public issue tracker so don’t have a way to let you follow progress or discussion on it, unfortunately. I can confirm implementing this would be very low priority, because we’re uncertain of whether we would want to keep using the current Find-in-Blueprint solution in the long term.

If the code review would take months, then I’d love something sooner, but we can afford to wait days or a few weeks.

Has this been approved? If not, I’m in a good spot to look at a shelf. Thanks.

I’ve now manually adopted both of these CLs (42591695, 47253201) into our 5.4 version of the engine and tested against our use case, and I don’t see the results in the search dialog when using Ctrl+Shift+F. I’ve triple checked my work and had another engineer look at it. Any chance there’s another change required for this to work, or something I can specifically debug to check that it’s working?

To speak a bit to the specific setup:

* A widget subclassed from our own subclass of common activatable widget

* Contains a child widget subclassed from our own subclass of common user widget

* the child widget has a map of gameplay tag to widget class as an instance editable property.

* the container widget populates the map on the instance of the child widget.

The map itself is defined in blueprints.

Classes:

  • CommonActivatableWidget
    • CustomActivatableWidget (C++)
      • WrapperWidget (BP)
  • CommonUserWidget
    • CustomUserWidget (C++)
      • NestedWidget(BP)
        • Map<GameplayTag, WidgetClass>

Widget Hierarchy:

  • WrapperWidget
    • NestedWidget

And in the editor, we edit WrapperWidget and populate the NestedWidget’s map property with a bunch of tags and classes.

I see.. I’ll have to turn this into yet another bug report / feature request. I focused on Map keys not being searched which I addressed in the fix for UE-317269, but beyond that: values in Widget components of Widget Blueprints are currently not searched via Find-in-Blueprints. They are instance values on subobjects.

[Image Removed]I’ve checked and the current metadata (what’s cached in assets as searchable data) contains nothing about those internal widgets. Not for the above map (MyMap), nor for regular variable types (MyString). Changing Find-in-Blueprints metadata is quite a painful ordeal, requiring all assets to be resaved to be certain of having the latest metadata. Therefore, I don’t think we’ll get to this feature request anytime soon since implementing it would trigger a “XXXX # of blueprint assets have out of date metadata, resave them?” warning on all user projects.

In the short-term, it’s better to use a combination of Find-in-Blueprints and ‘Search for References’ in the Gameplay Tag Manager to catch all cases.

[Image Removed]