Find-in-Blueprints now uses the same search data for both Find-in-all-Blueprints and Find-in-Blueprint. That searchdata is no longer stored in the asset registry, it is stored in the DDC and is managed by a new class. Searching is multithreaded to reduce overhead on the main thread during long searches in large projects.
virtual UEdGraphNode::AddSearchMetaDataInfo which sets base find-in-blueprints metadata and can be overriden with more detailed search data.
#change UEdGraphPin::GetDefaultAsString will return the text value as string if set
Added FBlueprintEditorUtils::GetEntryAndResultNode, moving most of the functionality from FBlueprintGraphActionDetails::SetEntryAndResultNodes to the new function
Added FBlueprintEditorUtils::GetGraphDescription to get graph descriptions from their metadata
Added FBlueprintEditorUtils::GetNodeByGUID to find nodes using their Guid
Blueprints now cache their search metadata on compile, this is a CPU intensive process and can no longer occur every time the Asset Registry queries for the Blueprint's tags
#change Fixed an issue with finding a pin type's icon (UK2Node_Variable::GetVarIconFromPinType) where we would search for a class we already had available.
Added an overridable function to UEdGraphNode to collect Blueprint search metadata.
#change FJsonObjectConverter::UPropertyToJsonValue is now available outside of the .cpp
#change Rewrote how Find-in-Blueprints works both for local and global searches, now uses Json to resolve a variety of format issues and also to make it much more extensible.
#ttp 290376 - K2: Ability to search (find in blueprints) important pin values
#ttp 298599 - ROCKET: TASK: K2: Search results should indicate where the instance is located in the results page (construction script, event graph, custom graph)
#ttp 304819 - Blueprints: Editor: L10N: "Find in Blueprint" needs to work with other languages
#ttp 308572 - UE4: ANIM: K2: Searching doesn't work for anim nodes right now
#ttp 316678 - UE4: BLUEPRINTS: SHADOW: Default values are not searchable
#ttp 318180 - UE4: K2: Cannot search for spawnactor using find in blueprints
#ttp 320141 - UE4: K2: Find in blueprints does not find functions declared in another blueprint (if the function isn't called in that BP)
[CL 2110494 by Michael Schoell in Main branch]
Other Updates:
- The WidgetReflector is now in its own module as well. It will be converted to a plug-in later.
- The Public API of both Slate and SlateCore has largely been reorganized for better discoverabilty. More cleanup work is needed.
- Added a lot of missing API documentation and fixed existing ones. More and better documentation is needed.
- Removed dead code, fixed a couple things I stubled upon, and conformed to coding guidelines (NULL vs nullptr, line breaks, etc.)
Upgrade Notes:
- The Slate Remote Server is currently disabled - will be re-enabled shortly!
- If your module previously had a module dependency to 'Slate', it now also needs a PrivateModuleDependency to 'SlateCore' in its Build.cs file.
- If your module exposes in any of its Public header files types that are now declared in SlateCore, it needs a PublicModuleDependency to 'SlateCore'
- The ToolTip property type on SWidget has changed from SToolTip to IToolTip; change local variables to TSharedPtr<IToolTip> instead of TSharedPtr<SToolTip> where needed
- IToolTip is not a widget. If you need access to the actual widget that represents the tool tip, use IToolTip::AsWidget(); If you need access to the tool tip's content, use IToolTip::GetContentWidget()
Troubleshooting:
- After syncing to this changelist you may have to clean your /Engine/Intermediate/Build/ directory and rebuild your entire project
- If in your project you are getting linker errors for unresolved types that are now declared in SlateCore, you may be missing a dependency to 'SlateCore'
- If in the Engine code you are getting linker errors for unresolved types that are now declared in SlateCore, you may need to rebuild the entire Engine
[CL 2057118 by Max Preussner in Main branch]
#ttp 330039 EDITOR: Platform-agnostic editor code depends on Windows-only VSAccessor headers
#detail Source code access is now extensible via plugins, so any new editors can be easily added.
#add Added SourceCodeAccess module that routes access via plugins.
#change Moved much of the old VSAccessor code into a new VisualStudioSourceCodeAccess plugin.
#add Added a counterpart XCode plugin & migrated the code from FSourceCodeNavigation (Applescript etc.) into there.
#remove Removed applescript for XCode access (it is now done via code).
#remove Removed source code access functionality from platform layer.
#add Added details customization for source code access settings, so users can choose their own accessor.
#remove Removed dependencies on VSAccessor.
#change Changed API in SWidget to not require building a string to be parsed, instead this acesses and forwards filenames & line numbers.
#extra Tested on Mac by Mark S.
reviewed by Andrew.Brown
[CL 2048697 by Thomas Sarkanen in Main branch]