| 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
19322 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 |
|
|
| |
Topic |
|
|
|
Improvement for searching large UE projects
