| Author |
 Topic  |
|
|
evolution
Tomato Guru
USA
107 Posts |
 Posted - Mar 04 2026 : 2:27:27 PM
|
If VAX could add something to the context menu for a solution explorer folder item that allows me to search in that folder, I'll be your best friend forever! #128516;
UE solutions have all of the engine's code in a single project, so some of the workflow shortcuts for searches available in VS are not very useful in UE solutions (like search in Current Project). The equivalent for a vcxproj scope in a UE solution would be a UE module. Something I find myself wanting to do pretty frequently is constrain my search for a symbol or some text string to a specific module's folder. A module folder in UE is any folder that has a *.Build.cs file in it, and they're usually direct children of "Source" folders (though there can be additional intermediate folders in the folder hierarchy as well).
A way to search a specific folder from solution explorer, or a way to choose a specific UE module to use as the "Look in" value would be a nice way for VAX to add some value, and it doesn't seem like Microsoft has much interest in improving VS's search functionality. |
what could possibly go wrong? :D |
|
|
feline
Whole Tomato Software
United Kingdom
19325 Posts |
Posted - Mar 05 2026 : 07:44:28 AM
|
How much overlap is there between a UE module and a plugin? I ask, since I am thinking about VA's setting:
VA Options -> Games & GPUs -> Index Unreal Engine plugins (requires restart) = None / Referenced / All
which depends on VA having some level of understanding of which plugin a given file lives in.
If we can re-use existing logic and understanding, always a BIG if, but it's a good place to start, this would help.
Assuming the idea of "limit search to current plugin" would work here, would applying plugin scope to Find References be what you are looking for here? Or are you actually looking for a simple text search, the same as the IDE's Find in Files?
Assuming this was considered, setting the scope of a Find References to the current plugin seems like a logical extension of what we are already doing. The first problem is what happens if the symbol you trigger the Find on is declared / defined outside of the current plugin.
As for your signature, don't ask the support department like that, I already have a list of things that can go wrong in hand  |
zen is the art of being at one with the two'ness |
 |
|
|
evolution
Tomato Guru
USA
107 Posts |
Posted - Mar 06 2026 : 1:15:10 PM
|
To answer first question: A plug-in can contain multiple modules. I'd say that most plug-ins have only one module, but the more complex plug-ins will consist of multiple modules. Each module can consist of multiple folders. The folder structure for modules is arbitrary, but the engine's build system will apply special behavior to certain folder names (e.g. Public, Private, Classes) so most modules will have at least a Public and Private folder; Classes functions as another container for header files, but is not widely used outside the Engine project.
To answer second question: Actually, I don't think having a search (or find-references) scope of "plug-in" would be very useful for any UE devs, for two main reasons:
* Even if you're a plug-in author creating plug-ins for marketplace, you'll probably be developing your plug-in within a blank project that's autogenerated from UE editor, or maybe within LyraGame or one of the other sample game projects. So using "Current project" as your search location is probably sufficient if you want to search only within your own code.
* Whether you're developing a game, plug-in, or standalone program that uses UE code, the location you need to search is seldom just your own code. For example, I'm a professional dev and this past week I was converting our game project to use Iris (a new networking system in UE that has a much different API than the previous networking system). Although the code I'm writing goes into our game project (inside various existing modules), the code I need to understand and interface with is in the Engine\Source\Runtime\Net\Iris folder (prior to UE version 5.7, it was in Engine\Source\Runtime\Experimental\Iris\Core\). That code corresponds to a module that has several subfolders, not a plug-in. And I searched this code a LOT  ; Throughout the course of my task, I'd most often want to search the Iris module, but occasionally I needed to search other specific locations in the engine that already use Iris, like the GameplayAbilitiesSystem plug-in. GAS consists of two modules - the system itself (GameplayAbilities) and the editor support for that system (GameplayAbilitiesEditor). But only the GameplayAbilities module contained code I was interested in. As a workaround, I can change the "Look in" for the search to be specific folder in UE, but that is a little inconvenient.
I seldom use Find references, because neither intellisense nor VAX are reliable enough with parsing references (at least in UE projects) to trust that I'm not missing something if I only consider the references reported. They both work well enough when you first open a newly parsed solution, but both seem to break down in different ways as I go about my daily tasks of creating new code, modifying existing code, etc. over the course of several days. (Which makes these issues difficult to isolate and report in a minimal repro)
For example, UE recently (maybe in 5.6?) added an abstraction to the main string class, FString, to allow defining 3 versions of this class without using templates. It's no longer declared like class FString, it's declared like "class UE_STRING_CLASS", where UE_STRING_CLASS is a macro defined in a previously included header to create three different classes with the same members, but different underlying data type (FString, FUtf8String, and FAnsiString). This seems to completely break both Intellsense and VAX to the point where FString members are no longer visible to VAX at all. FString doesn't exist, as far as VAX is concerned. So I still primarily rely on Find in Files. Epic seems to make these parsing-breaking changes pretty frequently. Maybe they like messing with you guys 
I think the biggest productivity boost related to searching would be if I could define a set of modules to search in. This is the thing that is most often what I want to do. I don't want to search the entire engine, or the current project. I want to search something in between - I want to search Modules A, C, and H, but nothing else. Then next week, I'm working on a different area of the engine and I want to search for related code in modules D, F, and M. Sometimes those modules will be inside plug-ins, but sometimes they won't. That's not something I can do, so I just search entire solution and wade through a few dozen irrelevant results in 300 plugins that I don't care about even if our project IS using them.
Lastly, I think find-in-files is a neglected area of VS. VS, having perhaps been *ahem* inspired by features in VAX, now has a pretty decent symbol lookup and jump-to-symbol features. But they haven't really done much with search at all. They've added the ability to keep 5 search result panels open (wow, amazing /s), you can now pin a search result so it doesn't get replaced with a new search (pretty helpful), and you can append one set of search results to a previous search (less helpful, but cool I guess). They also changed search to cache using indexing, which of course immediately broke Find-in-Files for UE. It took them several patches to get that working again...and I've turned that off because it occasionally misses results just like Find-References does...but I digress. Anyway, that's the only improvements they've made to Find in Files in 20 years. Which is incredible when you consider how often developers need to search code for something. |
what could possibly go wrong? :D |
Edited by - evolution on Mar 06 2026 4:26:03 PM |
|
|
|
feline
Whole Tomato Software
United Kingdom
19325 Posts |
Posted - Mar 11 2026 : 12:20:48 PM
|
First a quick answer, I MAY have a fix in hand for FString. Can you please try closing all instances of the IDE, and assuming you are using VS2022, edit the registry key:
HKEY_CURRENT_USER\SOFTWARE\Whole Tomato\Visual Assist X\VANet17\ExtHeader = ...
adding:
.src;
to the end of the string, so it becomes:
ExtHeader"=".h;.hh;.hpp;.hxx;.ipp;.tlh;.inl;.p;.rh;.dh;.ih;.ph;.hm;.ixx;.src;
because understanding FString in UE 5.6 requires parsing the file:
\\Epic Games\UE_5.6\Engine\Source\Runtime\TraceLog\standalone_prologue.h.src
which used to be just called "standalone_prologue.h", but now has a "special" file extension we haven't seen before.
But yes, it sometimes feels like things change in bizarre manors just because they can. Some of these changes I can help you work around by editing a helper file or two, or as in this case, editing a registry key. Once I have figured out where the change is of course. |
zen is the art of being at one with the two'ness |
|
|
|
feline
Whole Tomato Software
United Kingdom
19325 Posts |
Posted - Mar 11 2026 : 12:54:15 PM
|
For the find, my first instinct is actually to try and put together a powershell script. For input, I would want two text files. One file holds a list of directories to search in, your module list. The second file is simply your search string.
Loop across the directory list, doing a recursive find in files, dump the output into a 3rd file. Depending on what information you get from a powershell find, specifically if you get a line number along with the file name, you could generate an output file of results in a format that you could simply copy / paste into the Find Symbol dialog, since that accepts line numbers along with the filename.
This sounds relatively easy to put together, and my instinct would be to have the three text files open in the IDE, for easy access.
For some of what you are doing, I would be tempted to drop Hashtags at the spots you are working, and Alt-G between them. This is something I sometimes do myself. Not the same, and a bit manual, even with a snippet to help insert them, but a thought.
Given the list of modules / directories seems to be quite fluid, I am not sure how to go about making a good VA feature request for this. But I am more than happy to discuss this if you have any thoughts / ideas.
From a support point of view, I am concerned about your experience here. FString not being picked up was first reported 6 months ago, and since then you are only the third person to report this. I am starting to be concerned that UE developers are so used to problems, and some of them are so hard to describe, that it doesn't feel worth reporting them.
Are there other "broken from IDE load" problems you are seeing with VA? This seems a good place to start, since its easier to reproduce. |
zen is the art of being at one with the two'ness |
|
|
| |
Topic |
|
|
|
Improvement for searching large UE projects
