T O P I C R E V I E W |
pampersrocker |
Posted - Apr 06 2021 : 1:18:19 PM I get very frequently the case, that symbols are not recognized by any VAX action, but are highlighted properly.
Given the following Scenario: UE4 Source engine (with mulitple NDA platforms) and a game project. Cleared Cache and Rebuilt Database VS 2017 15.9.33 Visual Assist X build 2399 Options:
![](https://forums.wholetomato.com/forum/uploaded/pampersrocker/20214613118_UE4Options.png)
![](https://forums.wholetomato.com/forum/uploaded/pampersrocker/202146131155_PerformanceOptions.png)
After a while of parsing the code highlighting kicks in, highlighting the symbols properly:
![](https://forums.wholetomato.com/forum/uploaded/pampersrocker/202146131327_Code.png)
However, pressing Shift+Alt+Q on the UpdateProjects method (to implement it) or the ULiProjectProvider does not provide the quick refactor menu. Also right clicking on the symbols the quick actions submenu is almost completely greyed out. The caret moves to the front of the symbols, so something seems to be recognized.
Finding symbols tells me:
---------------------------
Visual Assist
---------------------------
Find References is not available because the symbol is unrecognized.
---------------------------
OK
---------------------------
VAX has been running great for multiple years now, but in the recent time problems have started to grow. Working fine and a minute later no symbols is recognized and VAX starts parsing all files from the beginning (which takes a while given UE4 Source).
|
17 L A T E S T R E P L I E S (Newest First) |
feline |
Posted - Apr 30 2021 : 10:23:55 AM Thank you. As people move to a new version of Unreal Engine, more and more people will be using a version that helps VA to locate the engine location.
Needing to use the junction point is a separate issue that we are aware of, but I don't currently have an estimate for when we will fix this. Discovering the performance impact of the junction point was rather unhelpful, since this limits the helpfulness of this work around. |
pampersrocker |
Posted - Apr 29 2021 : 10:26:50 AM quote: Originally posted by feline
I am glad this is working for you. Another user reported the speed problem with junctions a few days ago. This isn't something I had come across before, but it does seem to be a low level problem that we run into using junctions across different physical hard drives as a work around. We are working to improve our handling of, and support for Unreal Engine.
One of the changes in the latest version of VA is:
Added support for reading configuration information from a new Visual Assist specific section of Unreal Engine solution files. (case=143077)
but it will take time for this to really start to help, since it will only help if people are using a version of Unreal Engine that includes this information.
For the registry keys, on my Unreal system, I have 3 different versions of Unreal Engine installed, 3 different directories under:
C:\Program Files\Epic Games but only two paths listed in the registry under this key, and neither of them point to "C:\Program Files\".
I suspect this is because I have two different "types" of Unreal Engine install on this machine. I have used the Epic launcher to install pre-built Unreal Engine, and I have also downloaded and compiled the Unreal Engine source code from github. These different approaches to Unreal Engine produce different results in some cases.
Unreal Engine is complex ![](icon_smile.gif)
Ah you are correct, I am only dealing with two of the three engine installation types (Installed (built via the Make Installed Engine BuildGraph) and Source) here, the third One (Rocket from the Epic Games Launcher) I usually don't have installed.
Looking at FDesktopPlatformWindows::EnumerateEngineInstallations it seems two locations are actually used. I've looked at the code years ago the last time, since we register our custom build installed engines into the registry as mentioned before. |
feline |
Posted - Apr 29 2021 : 06:59:39 AM I am glad this is working for you. Another user reported the speed problem with junctions a few days ago. This isn't something I had come across before, but it does seem to be a low level problem that we run into using junctions across different physical hard drives as a work around. We are working to improve our handling of, and support for Unreal Engine.
One of the changes in the latest version of VA is:
Added support for reading configuration information from a new Visual Assist specific section of Unreal Engine solution files. (case=143077)
but it will take time for this to really start to help, since it will only help if people are using a version of Unreal Engine that includes this information.
For the registry keys, on my Unreal system, I have 3 different versions of Unreal Engine installed, 3 different directories under:
C:\Program Files\Epic Games but only two paths listed in the registry under this key, and neither of them point to "C:\Program Files\".
I suspect this is because I have two different "types" of Unreal Engine install on this machine. I have used the Epic launcher to install pre-built Unreal Engine, and I have also downloaded and compiled the Unreal Engine source code from github. These different approaches to Unreal Engine produce different results in some cases.
Unreal Engine is complex ![](icon_smile.gif) |
pampersrocker |
Posted - Apr 29 2021 : 02:46:08 AM After some more testing now, everything seems to be in working order, once VAX has finished parsing the solutions, which is due to the Junction still very slow.
Not sure if you are aware but since the UE4 projects are not discovered properly, all Engine Versions are registered in the registry under HKEY_CURRENT_USER\SOFTWARE\Epic Games\Unreal Engine\Builds for the UnrealVersionSelector to provide a dropdown. This may help to identify the UE4 versions. |
feline |
Posted - Apr 09 2021 : 11:37:14 AM Thank you, that is reassuring, and good to know. We need to make sure we parse enough of the plugins for VA to be properly useful to you. If we can safely skip good sized chunks of code then this is ideal, but we do need to be careful. It turns out skipping all plugins was a bit over eager ![](icon_smile.gif) |
pampersrocker |
Posted - Apr 09 2021 : 11:21:54 AM No, a lot of plugins often only add implementations to interfaces (such as Media Players or OnlineSubsystemSteam). I guess the only true list of plugin modules used, which we need actively parsed are stored in the Build.cs file of the modules, and the dependencies of those plugin modules. |
feline |
Posted - Apr 09 2021 : 11:07:25 AM Points 2, 3 and 4 is what I worked out when discussing this with another user, who also found that to much code was being excluded.
For point 1, doing a find in files, across the Unreal Engine 4.26 source code, for *.uplugin files containing:
"EnabledByDefault" : true
I get 79 plugin files. Just doing a search for *.uplugin files, I have a total of 355 of them. So basically 20% of them before we start.
I am concerned that if we automatically parse all of these as well, we are going to keep on limiting the usefulness of the "limit parsing" setting. But if they do all need parsing, then they need parsing. But are you likely to be using all 79 of them? |
pampersrocker |
Posted - Apr 09 2021 : 08:22:53 AM quote: Originally posted by feline
I am glad I mentioned we are looking to work out which plugins to parse. I have added your comment to the case, clearly plugin usage can be more complex than I, at least, was expecting.
I assume you would want / need VA to parse the OnlineSubsystem plugin?
Yes, the OnlineSubsystem in this example is something we want to have parsed.
From my point of view, to detect the relevant plugins: 1. Find all uplugin files, mark those, which are enabled by default 2. Check the uproject file, mark those that are enabled here and unmark that are disabled. 3. Check dependency lists of the marked plugins and mark them accordingly 4. You should now have a list of required plugins which need to be parsed
quote: Originally posted by feline 2 hours is rather longer than I would have expected VA to need to parse everything, so I assume you have a particularly large solution. I am used to seeing parsing Unreal Engine its self take more like 15 minutes on a laptop, so not a massive machine, but still powerful. So it does suggest that the junction point is having an effect, I haven't come across this before now.
The solution is a complete source version of UE4 with all 90 Projects and the game project. One of the game projects is currently rather small on the code side.
When I started working with UE4 in version 4.5 with VA 15-20 minutes were the expected time I had with parsing a source build of the engine.
The junction definetly added a factor of 10 to that. This is on a Ryzen 7 3800x with the parsing setting set as mentioned in the OP. The code itself sits on a 2TB Samsung 970 Evo Plus. |
feline |
Posted - Apr 09 2021 : 07:45:13 AM I am glad I mentioned we are looking to work out which plugins to parse. I have added your comment to the case, clearly plugin usage can be more complex than I, at least, was expecting.
I assume you would want / need VA to parse the OnlineSubsystem plugin?
2 hours is rather longer than I would have expected VA to need to parse everything, so I assume you have a particularly large solution. I am used to seeing parsing Unreal Engine its self take more like 15 minutes on a laptop, so not a massive machine, but still powerful. So it does suggest that the junction point is having an effect, I haven't come across this before now. |
pampersrocker |
Posted - Apr 08 2021 : 09:26:15 AM quote: Originally posted by feline
For plugins, we are working on an update, to only parse the plugins that are mentioned / included by your uproject file. I am assuming that the plugins you don't need parsing aren't listed in your uproject file?
case=144467
Not entirely, as an example we link against the OnlineSubsystem Plugin and have that listed in our ProjectModule.Build.cs. However OnlineSubsystem is not listed in out Project.uproject file, since the OnlineSubsystem plugin has in its uplugin file: "EnabledByDefault": true.
quote: Originally posted by feline
The performance with the junction point is odd. Are the different drives all local drives on your system? Are they of similar type / speed, all spinning drives, all SSD? A junction point is a low level file system concept, as I understand it, so it should be quite invisible to VA and the IDE.
Was VA still trying to parse Unreal Engine, or were you no longer seeing status bar messages about VA parsing Unreal Engine?
Usually it took around 1-2 hours with my VA settings for the engine to parse (although as mentioned it did not seem as complete as of now, so not sure how comparable that actually is). A bit of searching around seemed to indicate that junctions can cause a performance issue when the junction is across different drives, that's nothing really to do with VA or VS, just how junctions seem to be handled internally by Windows ( see https://github.com/Blosc/bcolz/issues/128 ). Both of my drives are SSDs the C: drive is a bit slower one, but as nothing is really red from it this should not cause a bottleneck of that size.
With parsing done I mean no longer seeing the parse message and the VS process no longer using 30-90% of CPU time.
One project seemed to be completely parsed after a day now. So far the completions and goto navigation seems to work as expected. |
feline |
Posted - Apr 08 2021 : 09:03:34 AM For plugins, we are working on an update, to only parse the plugins that are mentioned / included by your uproject file. I am assuming that the plugins you don't need parsing aren't listed in your uproject file?
case=144467
The performance with the junction point is odd. Are the different drives all local drives on your system? Are they of similar type / speed, all spinning drives, all SSD? A junction point is a low level file system concept, as I understand it, so it should be quite invisible to VA and the IDE.
Was VA still trying to parse Unreal Engine, or were you no longer seeing status bar messages about VA parsing Unreal Engine?
I am glad the results are a lot more complete. If VA wasn't properly registering that it was parsing Unreal Engine, then any of the Unreal Engine specific fixes we have made, to try and help our parser make sense of the code, probably didn't take effect, which obviously would have an effect.
If you run into any cases where VA does not understand Unreal Engine correctly I would be interested to know, to see if we can do anything about fixing them. |
pampersrocker |
Posted - Apr 07 2021 : 4:14:53 PM Some more results after a day of testing:
* There seems to be a performance issue when a NTFS junction goes across different drives. I was not able to complete a full parse of the engine for either of my UE4 projects, both with the new junction path. Before this took about 1-2 hours. * While the results are not complete yet, the parsed data seems far more complete than before. Noticed while looking at implementation that use a typedef like typedef FPhysicsInterface_PhysX FPhysicsInterface; Before only one or two of those typedefs are picked up, now when using the goto (Alt+G) it showed all typedef variations. |
pampersrocker |
Posted - Apr 07 2021 : 08:59:38 AM quote: Originally posted by feline
Do you often see the IDE crash? VA rebuilding its symbol database after a crash is by design, since we cannot be sure that the crash didn't corrupt something.
Crashes are a semi occurence due to some other plugins, such as the debuggers for the game consoles I am working with. Another crash source seems to be the perforce plugin, which sometimes hangs for more than 10 minutes or so and I rather kill VS and restart it instead of waiting for the plugin to respond. Still a better solution for me than constantly reconciling offline work in perforce.
quote: Originally posted by feline
You might want to try disabling the IDE intellisense parser, if you haven't already done so:
IDE tools menu -> Options -> Text Editor -> C/C++ -> Advanced -> IntelliSense -> Disable IntelliSense = True
since this will reduce the amount of parsing that gets done.
Already did that years ago ;)
quote: Originally posted by feline
If you don't need VA to parse the Unreal Engine plugins, then you can turn this off via the setting:
VA Options -> Unreal Engine -> Index plugins (requires restart)
but since you have this On, you have probably turned it on manually, since you do need this code parsed.
The problem is, we need parts of it, probably not the longest ones to parse (such as the boost library hidden inside the ProxyLODPlugin or the gigantic Alembic Importer library). But other plugins such as Niagara, Paper2D and the compelte OnlineSubsystem is in frequent use, so it's 50:50.
Another side node: Putting the UE4 engine into the junction did not fully Pick up the Engine\Platforms directories. I don't think it matters much as this is not much code, but still. Some very specific subdirectories are added, probably related to Projects in the Solution such as the DevKit utils. |
feline |
Posted - Apr 07 2021 : 07:27:45 AM Thank you, this should help with at least some of your problems.
Do you often see the IDE crash? VA rebuilding its symbol database after a crash is by design, since we cannot be sure that the crash didn't corrupt something.
You might want to try disabling the IDE intellisense parser, if you haven't already done so:
IDE tools menu -> Options -> Text Editor -> C/C++ -> Advanced -> IntelliSense -> Disable IntelliSense = True
since this will reduce the amount of parsing that gets done.
If you don't need VA to parse the Unreal Engine plugins, then you can turn this off via the setting:
VA Options -> Unreal Engine -> Index plugins (requires restart)
but since you have this On, you have probably turned it on manually, since you do need this code parsed. |
pampersrocker |
Posted - Apr 07 2021 : 06:09:52 AM Thank you for your response,
As you suspected, the engine directories were not in the list. They are now after the junction creation.
I'm currently letting it parse due to the directory change and will test and report back. |
feline |
Posted - Apr 07 2021 : 05:00:13 AM As a first step, can you please look in the VA Options dialog, and look at the:
VA Options -> C/C++ Directories
page. The list of directories should contain all of your Unreal Engine sub-directories, but I suspect this isn't the case.
There is a known limitation in VA, that it won�t correctly pick up the Unreal Engine directory tree if it installed outside of "C:\Program Files\"
case=105950
to work around this problem can you please create a junction point link to point at the installed engine. So:
Create the directory C:\Program Files\Epic Games Open a command prompt inside this directory, and run the command:
mklink /J UE_4\4.26 "C:\UE4\4.26"
Where the second path is the directory where you have installed / placed Unreal Engine. This will create a directory link inside the Windows file system, so while Unreal Engine will appear to exist inside this Program Files sub-directory, is still where it was originally installed.
Now make sure all instances of the IDE are closed, and then go into the directory that holds your game solution. From here you should find in the following files:
Intermediate\ProjectFiles\UE4.vcxproj Intermediate\ProjectFiles\UE4.vcxproj.filters
Open both files in a text editor, and do a search and replace for the old Unreal Engine path to the new Unreal Engine path, so in this case search
"C:\UE4\4.26\"
And turn all instances into:
"C:\Program Files\Epic Games\UE_4\4.26\"
Save the changes and now reload the IDE and your solution.
To avoid having to do this again, if you run the Unreal Engine editor, or Unreal Engine script files via the junction point path then when they update the Visual Studio solution and project files Unreal Engine will use this junction path, rather than the actual physical path that the engine is installed into.
Doing this should help with some of the problems you are seeing. Once Unreal Engine is being properly picked up, VA won't reparse the engine so often, since it knows it won't be changing often. |
pampersrocker |
Posted - Apr 06 2021 : 2:03:19 PM After letting the scanning finish completely, the operations start working again and everything is working fine.
The main problem is this happens from time to time, although nothing is changed on the setup. The game project is developed further but no major changes have been done on the engine side.
Things I have noticed so far: * Re-opening the solution after a re-generation tends to reparse the whole solution * VAX tends to re-parse the whole code when Visual Studio crashed (due to a debugger crash or so) (corrupt database? or related above). * Switching to different game projects with the same engine causes VAX to re-parse the engine. The last points is extremely noticeable as the source file opens with the correct syntax highlighting, then loses all information and the re-parse starts again, taking around an hour to complete for it to start working again.
Sadly this is not a to the point bug report, but a collection of problems using VAX in the daily workflow. I have set the parsing priority to lowest otherwise I hardly can use the computer while it is parsing, or severly hindering the compile times. |
|
|