| T O P I C R E V I E W |
| ML_Umberto_Carletti |
Posted - Jan 31 2025 : 06:16:42 AM
Hi,
I have a very big Unreal solution with many plugins. Without filters the symbols count is about 1.850.000. I am trying to reduce the symbol count using the .vscode/settings.json. I have ~180 pattern entries in the settings.json (mostly folder paths like "**/Engine/Source/Programs/**"). What I am noticing is:
1. The "Find Symbols" window is showing a reduced symbols count, but still showing some symbols from excluded patterns.
It seems like it's still parsing all the symbols from .cs files from the excluded patterns (it matches **/Engine/Source/Programs/**/*.cs).
When I try access those excluded symbols from this window, the source file is opened with a warning: "The file is excluded by a rule defined by .vscode/settings.json..."
What i would expect is that the symbol should not be shown at all in the "Find Symbol" window, but i would still be able to access the file if needed from visual studio without the annoying warning showing up all the time.
2. The "Open File in Solution" window is showing a reduced number of files but became very slow to load. It looks like it's parsing the files with the settings.json every time the window is opened.
In this case I would expect that the window load faster for having less files included.
Also in my opinion the solution still has those files in it and maybe should still show them in the "Open File in Solution" window. The filters should work only to exclude symbols, helping reducing the symbol count.
I'm using
VA_X64 10.9.2530 2024.07.30
DevEnv.exe 17.12.35521.163
msenv.dll 17.0.35514.174
Thanks in advance |
| 30 L A T E S T R E P L I E S (Newest First) |
| feline |
Posted - May 20 2025 : 12:57:24 PM
The conversation about excluding C# files is that there was a bug, recently fixed, where the exclude rules were not excluding C# files, even though the exclude file said to do so.
Based on some tests here, if you make the file:
x:\source(svn)\verA\vsproj\.vscode\settings.json
and give the file the content:
{
"files.exclude": {
"../verB" : true,
"../verC" : true
}
}
this should work.
After saving out the file, I would press the button:
VA Options -> Performance -> Rebuild symbol databases
and restart the IDE, to make sure that VA's symbol database is cleared out, since it will probably still be remembering files otherwise. |
| superzmy |
Posted - May 20 2025 : 02:51:14 AM
quote:
Originally posted by feline
VA 2025.1 has just been released, and the release notes contain the rather helpful line:
New Added support for excluding C# files being parsed with a "settings.json" file.
You can download the new build from here:
https://www.wholetomato.com/downloads
what is excluding c# ? May I exclude some dir of different version source dir, which are placing together?
My dir are
x:\source(svn)
x:\source(svn)\verA\vsproj\.sln
x:\source(svn)\verA\vsproj\.vsxproj
x:\source(svn)\verA\*.cpp
x:\source(svn)\verB
x:\source(svn)\verC
When I editing VersionA, sometime verB verC ver D symbol are all come into VA symbol window.
Sometime I use alt G and Edit for some minutes, I found i am in VerC so waste my time.
I want some.json in verA to tell VA not to read verB and verC. |
| feline |
Posted - Apr 29 2025 : 08:56:48 AM
Interesting link, and that should make locating the engine easier, at least some of the time.
For VA missing symbols, do you remember any of the cases when this happens? I am wondering if its a "predefined" symbol, one that will show up if I simply download the raw UE source code, or a symbol generated from compiled code, including the UE pre-compiler. A "simple" theory here is files that appear after we have generated the list of files to parse, so we don't know to parse them until you manually open the files.
I have never noticed this happening, but I don't work in UE, I simply go digging in it when someone reports a problem. |
| ML_Umberto_Carletti |
Posted - Apr 29 2025 : 03:37:53 AM
I think it would be OK to support the two main project structures proposed by epic https://dev.epicgames.com/documentation/en-us/unreal-engine/managing-game-code-in-unreal-engine
At the moment you fully support the "Foreign Projects" installation type. You could add support for "Native Projects" setup. We use that one and probably all major studios do as well.
Following Epic guide lines, maybe it would be enough to look for "Engine" in the path, and an option to specify if is Native/Foreign projects. This way we can choose if look for the engine dir in "C:\Program Files" or ".\<projectroot>\Engine"
As for VA not picking up symbols, I think that since it takes roughly 2 mins for a full DB rebuild, if I start doing stuff like compiling while VA is still scanning, some symbols never get scanned until I manually open the file containing them. As I mentioned in the other comment I don't have exact repro steps. |
| feline |
Posted - Apr 22 2025 : 11:35:41 AM
For italic symbols, the idea is that if you have gathered the Unreal Engine source code from github, you are editing the engine code, so its no longer a stable library. So, it's no longer shown in italics, since italics is used to indicate symbols from a stable library.
The current method for working this out is a bit flawed though. If the engine code is installed under "C:\Program Files\" then we assume that you have downloaded the engine pre-compiled from the Epic Games Launcher, so the engine symbols are shown in italics, since its not being changed.
If it is found outside of this directory tree, you have downloaded the source code from github, so it is no longer shown in italics.
Obviously this is not a good or reliable rule, but it is simple to explain, and easy enough to fool, if you want to, by using junction points in the Windows file system. Some form of flag we could pick up to tell us if you downloaded the source code from github would be a better rule, but I don't know of any such flag. Plus, if you are editing the code, it might not be all that reliable either.
With recent versions of VA parsing the UE tree so much faster, a lot of the performance problems with parsing Unreal Engine regularly have gone away, thankfully.
For the Open File and Find Symbol lists / dialogs, there is always going to be some lag once a solution reaches a certain size. Obviously this partly depends on machine speed, but I think we can all agree Unreal Engine solutions tend to be "big" 
For plugins, the setting:
VA Options -> Game Development -> Index Unreal Engine plugins (requires restart) = None / Referenced / All
should help in general, but not in all situations.
When you mention VA not picking up changes to symbols, was this symbols being removed due to editing that are still listed, or new symbols being added not being picked up? I ask since its possible they are different sorts of problems. |
| ML_Umberto_Carletti |
Posted - Apr 17 2025 : 03:56:22 AM
With a full rebuild with the settings.json it takes around 1-2 mins to load all the symbols. that is totally reasonable and I am keeping enabled the option for parsing the whole solution at start Up, since I noticed that sometimes the option for parsing only changed files leaves some symbols behind...
It's worth noticing that VAView has also the file list, and I noticed that it got stuck as well sometimes, but I don't have more details about that. it just seemed unresponsive and had to reload visual studio.
mparker, yeah I have the Italic for Engine symbols enabled as well but it only seems to work with the classic installation of Unreal from Epic Store (and not with engine built from source).
The problem arises when you use the settings.json. I noticed that the "Find Symbols" dialog open faster with less symbols parsed. In your case it may be worth to dump all the engine plugins that you don't actively use and exclude them with settings.json... Once case=165513 is fixed the OFIS will also work properly. Without settings.json my OFIS opens instantly as well |
| mparker |
Posted - Apr 16 2025 : 7:32:01 PM
I was reading some of the messages here and wanted to add some of my own info. I have "Index Unreal Engine plugins" set to All, as I'm often working on the engine or engine-level plugins, and I had some issue long ago with a plugin I needed not being indexed. I'm on UE 5.5.2, and my installation is in a nonstandard location with no sym links, so engine symbols are generally not shown in italics (I have that setting enabled anyway). Having said that, in VS, my Find Symbol dialog shows 5,131,624 symbols; Open File in Solution shows 143,078 files with "Show only files in the current solution" checked. Find Symbol takes about 5.5 seconds to populate in VAX 2554. OFIS seems basically instant. Our project is a AAA game, and I don't expect it to be wildly outside the average, but I guess I don't have any data on that. |
| feline |
Posted - Apr 16 2025 : 11:16:17 AM
I have your email, and the settings file, thank you for that.
With this file applied, it is taking about 20 seconds to open and populate the OFIS dialog for me, with the UE source tree build solution. It is around 1 second, or less, when turning off the exclude file. So we clearly have a problem here.
If you have the time, can you see how long a full symbol database rebuild is taking on your system? Here, doing a full rebuild, and timing it until the status bar messages about VA parsing stop showing up, with no filtering, it is taking about 2 minutes 20 seconds. With the filtering file, it is taking about 1 minute 30 seconds.
A fair difference in time, but under 3 minutes for a full symbol database rebuild isn't terrible, when you should only need to do this when you install a new build of Visual Assist, or something serious has gone wrong. Normally, it should only take a few seconds. So I am wondering if your numbers are massively different to mine.
I have attached the settings file to the case for the OFIS dialog coming up slowly, since this is a better and more sensible test case than the one I cobbled together.
case=165513 |
| feline |
Posted - Apr 14 2025 : 08:57:22 AM
Can you send me a copy of your ".vscode\settings.json" file, so I can try it here? I don't think the file should contain much if any sensitive information.
This way I can be sure I am doing a similar test here.
For the case numbers, I am not sure why they are missing, since that makes it harder to look things up to check when looking at what was fixed. I need to remember to ask about this. |
| ML_Umberto_Carletti |
Posted - Apr 14 2025 : 06:47:45 AM
Hi! thank you for the update! I just tested it and it seems to work fine! I managed to greatly reduce the number of parsed symbols!! Thank you for this.
The "Open File in Solution" problem it's still present. Every time I open it it hangs on "Open File inSolution [loading...]" for almost 15s. once is loaded it works fine as long as I keep the window opened. As soon as I close it and open it back it has to load again.
I noticed you didn't write the case number on the latest changelogs. Is that something that you will do from now on? |
| feline |
Posted - Apr 01 2025 : 07:56:10 AM
VA 2025.1 has just been released, and the release notes contain the rather helpful line:
New Added support for excluding C# files being parsed with a "settings.json" file.
You can download the new build from here:
https://www.wholetomato.com/downloads |
| feline |
Posted - Mar 18 2025 : 12:28:37 PM
When you re-load Visual Studio, VA should only need to parse any files that have changed. The only times this won't apply are if you have triggered a VA symbol database, or loaded an "extra" instance of Visual Studio. For me, re-loading Visual Studio, and loading this large solution again, I am not even seeing messages about VA doing any parsing at all. This is expected though, since nothing has been changed.
Reparsing does happen automatically after a crash, but we have already covered this, and it should not be a problem.
For an extra instance, each instance of Visual Studio gets its own copy of the VA symbol database, to stop problems where the databases overlap. Given the solution size, I only mention this to be complete, and it should not be much of an issue.
Does this match your experience, that there is only limited parsing most of the time?
I have already put in a case for C# files still being parsed, even though they have been excluded. |
| ML_Umberto_Carletti |
Posted - Mar 17 2025 : 06:47:30 AM
Nice! I have no idea why it didn't work before...
Anyway, with all the plugins and modules in our code base, a have a total of 1.890.941 symbols. I rebuilt the database and it took several minutes (i didn't profile the timing but i'd say 10 min). This is acceptable for the first time, than I switch to parsing only modified files.
From the "Open files in Solution" I see 88.438 files. And that is why I would like to exclude from parsing some plugins that we don't need to be parsed with VA. |
| feline |
Posted - Mar 14 2025 : 1:25:12 PM
I had yet another look at this, and this time, Unreal Engine decided to build successfully.
I have absolutely no idea why it decided to build and work this time, and not any of the previous times. Very confusing, so I don't want to touch it if I don't have to. But what matters is that I can finally actually run some tests, and do some investigating of this.
For the record, the test game project I created is:
First Person
C++
Target Platform = Desktop
Quality Preset = Maximum
Starter Content = On
First observation, I got this working before installing Visual Assist. So VA had to do a full VA symbol database build when I first loaded this game solution. Using VS2022 and VA 2547 this was finished in just a few minutes. I didn't time it, but certainly I didn't get the "come back in a few hours" parsing time that I have sometimes seen with older versions of VA and really massive solutions. |
| feline |
Posted - Mar 03 2025 : 12:41:41 PM
One step forward, one step back...
I had to double the allocated RAM to the VM, but I now got a "UnrealEditor.exe" out of the compile.
But when I run it, I get a fatal error. "The game has crashed and will close"
Due to:
Fatal error - unable to read manifest from ...UnrealEditor.modules
Probably related to the compiler errors, which start with the fascinating:
Severity Code Description Project File Line Suppression State Details
Error C2039 'system_clock': is not a member of 'std::chrono' UE5 F:\GitHub\UnrealEngine\Engine\Plugins\Media\BlackmagicMedia\Source\BlackmagicCore\Private\BlackmagicInputChannel.h 39 |
| feline |
Posted - Mar 03 2025 : 09:17:25 AM
I always looked in the folder:
Epic Games\UE_5.5\Engine\Binaries\Win64
for "UnrealEditor.exe" or failing that, for "UE4Editor.exe" or anything else sounding helpful, but never found it. So I concluded this ignored icon mattered.
Currently, I have started with a new, empty Windows 11 machine. Its a virtual machine, configured with 16 processors and 32 GB of RAM, but I am wondering if this is enough. I have installed VS2022, GitHub Desktop, downloaded the source code, done all of the steps...
I am still getting the ignore icon, and I am currently at about 15 crashes of Visual Studio trying to build the UE 5 main trunk. The list of exe files in the folder "Epic Games\UE_5.5\Engine\Binaries\Win64\" is:
F:\GitHub\UnrealEngine\Engine\Binaries\Win64\CmdLink.exe
F:\GitHub\UnrealEngine\Engine\Binaries\Win64\crashpad_handler.exe
F:\GitHub\UnrealEngine\Engine\Binaries\Win64\EpicWebHelper.exe
F:\GitHub\UnrealEngine\Engine\Binaries\Win64\iostore_analysis.exe
F:\GitHub\UnrealEngine\Engine\Binaries\Win64\LiveCodingConsole.exe
F:\GitHub\UnrealEngine\Engine\Binaries\Win64\MinidumpDiagnostics.exe
F:\GitHub\UnrealEngine\Engine\Binaries\Win64\radpatcher.exe
F:\GitHub\UnrealEngine\Engine\Binaries\Win64\UnrealTraceServer.exe
F:\GitHub\UnrealEngine\Engine\Binaries\Win64\UnrealVersionSelector-Win64-Shipping.exe
F:\GitHub\UnrealEngine\Engine\Binaries\Win64\zen.exe
F:\GitHub\UnrealEngine\Engine\Binaries\Win64\zenserver.exe
none of which seem to be the one I want.
The instructions really do seem clear enough, so I have no idea why I cannot get this to work. |
| ML_Umberto_Carletti |
Posted - Feb 28 2025 : 08:57:03 AM
You could just delete the git tree, I don't think you need the whole history of the git project. That would make the directory smaller. Also about the "Ignored" thing, from a quick look on google it looks like related to source control, and the fact that files are ignored from the source control shouldn't prevent you from compiling. Did you try to build the editor after having downloaded all the missing VS components? Also I guess the "ignored" symbol would disappear if you'd make a fork and have the engine on your own git. |
| feline |
Posted - Feb 28 2025 : 07:58:50 AM
I am so used to Visual Studio telling me to install extra bits I was just ignoring the yellow box. Especially since UE 4.x compiled just fine.
I have just installed all of these extras. I then did a reboot, to make sure, and re-ran "GenerateProjectFiles.bat" to make sure any changes had been accounted for. Then open the UE5.sln, and the same result. The solution and UE5 project are both marked ignore.
Clearly there is some problem with this machine, but I have no idea what, or where to look for it.
I need to find the space for a new, clean VM, since the git tree for all of this is 260 GB on its own! This is going to be a fairly large VM... |
| ML_Umberto_Carletti |
Posted - Feb 28 2025 : 04:57:52 AM
From the screen you sent it looks like you are missing visual studio components to game develop in unreal. Did you install the missing components? you can also try to follow this
https://dev.epicgames.com/documentation/en-us/unreal-engine/setting-up-visual-studio-development-environment-for-cplusplus-projects-in-unreal-engine#newvisualstudioinstallation |
| feline |
Posted - Feb 27 2025 : 1:54:39 PM
I am using Github Desktop for my git client, but hopefully that won't matter. I had Unreal Engine cloned into:
F:\src_github\UnrealEngine
I have deleted this from github desktop, and fully deleted the entire directory tree from the hard drive. Then I grabbed the Unreal Engine main branch into "F:\UnrealEngine\"
Then "setup.bat", for the prerequisits
Then "GenerateProjectFiles.bat" which gets me a "UE5.sln"
Open the generated SLN file...
I have made sure I have the correct configuration selected, and restarted VS2022.
I am left to conclude there is a problem with this machine, but I have no idea what or where to look. I have compiled Unreal Engine 4 from source code before on this machine.
I am going to have to start over from scratch on a new test machine. |
| ML_Umberto_Carletti |
Posted - Feb 25 2025 : 05:48:28 AM
I just tried with a fresh repo. Following https://dev.epicgames.com/documentation/en-us/unreal-engine/downloading-unreal-engine-source-code#downloadingthesourcecode I:
1. git clone https://github.com/EpicGames/UnrealEngine in S:\UnrealEngine
2. run setup.bat
3. run GenerateProjectFiles.bat
4. oepend UE5.sln
5. from Soultion Explorer: right click on UE5 project -> build
this succesfully built the editor.
I also created a new project in S:\UnrealEngine\Games\MyProject from the newly built editor UI. This created MyPProject.sln. Then:
1. opend the MyProject.sln
2. from SolutionExplorer, right click on MyProject -> Set As Startup Project
3. f5 to build and run with default configuration (Development Editor - Win64).
It compiled my project and opend the editor with the Engine I built (ue 5.5.3). |
| CliffyP |
Posted - Feb 24 2025 : 1:19:46 PM
quote:
Originally posted by feline
I am currently trying, and failing, to get UE 5 main branch to compile.
Main branch is a hot branch.. can't expect it to always compile. Use Release instead. |
| feline |
Posted - Feb 24 2025 : 12:41:19 PM
I have been trying for days now, and I simply cannot get UE 5.5 or 5.4 to compile.
It doesn't seem to matter how many times I grab the latest code from GitHub, or re-generate the solution files, but I always end up with the UE5 project in Visual Studio 2022 flagged with a small red "stop" icon, telling me that the project is being ignored. I have double checked that I have set the right configuration.
Web searches aren't turning up anything useful so far either. |
| feline |
Posted - Feb 14 2025 : 07:46:04 AM
Please be aware that none of these changes / bugs have been done yet, so don't get to excited about these for the next release.
I am currently trying, and failing, to get UE 5 main branch to compile. So I did another code update from github, and am running another compile, in the hope that it will help. |
| ML_Umberto_Carletti |
Posted - Feb 14 2025 : 03:25:03 AM
Thank you very much for your time. I'm looking foreward for the next releases! |
| feline |
Posted - Feb 13 2025 : 10:39:41 AM
This is a very interesting idea, and if it can be made to work, it makes a lot of sense, and is clearly going to be very helpful, since catching the errors without needing to do a full build all of the time is going to be most welcome. I have put in a feature request for this to see what our developers make of it:
case=165519 |
| ML_Umberto_Carletti |
Posted - Feb 12 2025 : 03:24:09 AM
Yes you are right and you phrased it better. It is actually code inspection with UHT. It makes sense to run it only on the current header live while you are writing code (maybe when you pause if there are code changes from last run, or every n seconds, or a combination of both).
Thank you very much for your support with the problems related to the settings.json.
|
| feline |
Posted - Feb 11 2025 : 12:11:27 PM
Ah, now I see what you are thinking, and talking about. Would it make sense to model this after Code Inspection? I am thinking how when editing, once you pause, VA checks the file and reports any errors that are coming from clang-tidy. A similar method could work here, at least in theory. Then you would see the errors disappear as they are fixed.
Since this is limited to just the current header file, I am hoping it would be fairly responsive.
I have put together a test for large numbers of files being excluded, and the effect on the Open File in Solution dialog. The results are a mess, no wonder you are having problems here. I have put in a bug report for this:
case=165513 |
| ML_Umberto_Carletti |
Posted - Feb 10 2025 : 04:25:25 AM
At the moment the UHT is run every time I hit compile.
Example:
MyFile.h
#inclue "myfile.generate.h"
#include "other-file.h"
when compiling I see this output:
Running Internal UnrealHeaderTool H:\myproj.uproject H:\myProjEditor.uhtmanifest -WarningsAsErrors
H:\MyFile.h(1): error : #include found after .generated.h file - the .generated.h file should always be the last #include in a header
I'd like the UHT to be run only on the current header opened.
What I would expect is that as soon as I open (or switch to) a .h file the UHT is run automatically on the file and underline any error. For the example case, I would expect that, as soon as I switch to MyFile.h, the line '#inclue "myfile.generate.h"' gets underlined in red, and when I hover my mouse, i get a window with the error:
"error : #include found after .generated.h file - the .generated.h file should always be the last #include in a header".
I would expect this behaviour to be activated from the VAOptions->Game Development->Unreal Engine->Run UHT on header files |
| feline |
Posted - Feb 07 2025 : 12:14:10 PM
I will set up a test case with the source code, thank you for confirming the version number.
A quick search on the Unreal Header Tool is getting me to this page:
https://dev.epicgames.com/documentation/en-us/unreal-engine/unreal-header-tool-for-unreal-engine
Which suggests it is possible to use:
IDE Tools menu -> External Tools...
to set up a tool command to run this compiler on the current header file. But I assume you are looking for something more automated. This is an interesting idea. I am just trying to work out how to describe the feature request.
You don't want to run this on all header files in the solution, that would be crazy. But how would we define the set of header files to check? |
|
|
