Whole Tomato Software Forums
Whole Tomato Software Forums
Main Site | Profile | Register | Active Topics | Members | Search | FAQ
 All Forums
 Visual Assist
 Technical Support
 How to avoid unnecessary reparsing [UE4]

You must be registered to post a reply.
Click here to register.

Screensize:
UserName:
Password:
Format: BoldItalicizeUnderlineStrikethrough Align leftCenterAlign right Insert horizontal ruleUpload and insert imageInsert hyperlinkInsert email addressInsert codeInsert quoted textInsert listInsert Emoji
   
Message:

Forum code is on.
Html is off.

 
Check to subscribe to this topic.
   

T O P I C    R E V I E W
NeedVisualAssistanceX Posted - Apr 17 2019 : 01:39:26 AM
Hey guys. I like Visual Assist X quite a bit and I've been using it for a little under a year now. Unfortunately, the entire time I've been using it, I've been plagued by re-parses that are seemingly invoked by nothing. I'm not sure if this is just something to get used to when using VAX with Unreal Engine 4, or if I'm simply doing something that I shouldn't be doing that triggers a reparse.

My understanding is that as long as I'm working within the same project/solution (which in my case is the generated UE4 Engine project and my game project), and don't literally click the "Rebuild" button on the options dialog, there should be no need to reparse. Yet restarting my computer or seemingly just being away from the project for an extended amount of time seems to trigger a reparse of both my game, and the entire Unreal Engine source, which essentially locks me off of the project for about three hours unless I want to challenge myself with intellisense-less coding.

I've been to this support page several times to try to figure out what I'm doing wrong, but according to the two bullet points, there should be no need for a full reparse. Are there any secret pro-tips for preventing UE4 projects from triggering a reparse of the entire codebase? It's literally my current least favorite thing in the entire world, and I'd love to get it to only parse what's necessary at a given time.

Thanks!
23   L A T E S T    R E P L I E S    (Newest First)
ChrisG Posted - Oct 02 2019 : 03:07:43 AM
You should be able to place the UE4 source directory whoever you please. UE4 symbols will may not appear in italics. That's not to say there aren't issues with unnecessary parsing potentially popping up in some cases. Unfortunately, we don't have any reproduction for those issues as of yet.

If you can reproduce unnecessary parsing, please contact support@wholetomato.com, and collect logs as described by Sean above. That would be a tremendous help.

Additionally, it's a good idea to make sure Visual Studio isn't just crashing and also that Visual Studio is fully shutting down after you close it.
NeedVisualAssistanceX Posted - Oct 02 2019 : 02:54:23 AM
Hello again! Looks like I wasn't totally alone with my issue, so that's always good to see. Reading the replies, the answer would appear to be "not quite", but just wondering if there's any set of steps that I could follow to make sure Visual Assist X recognizes the UE4 source from an arbitrary directory that isn't on the C drive? I've left it on the C: drive for the past few months, but it'd be rather swell if I could move it to another drive/location of my choosing. UE4 is not a small set of software!
sean Posted - Sep 16 2019 : 7:33:42 PM
@HateDread The issue of symbols not being rendered as italic (case=140062) is, so far as I can tell, unrelated to the issue of constant parsing of engine source. We would really like to get that constant parsing problem addressed, but first we need to understand why it is happening.

Do you have VA 2341.2 installed?

Does the problem occur after a simple immediate reload of the solution?
Or is the problem dependent upon some sort of state change or command execution outside of VS before loading the solution?

If you have a way to repro, please enable VA logging before you load the solution (see details at https://support.wholetomato.com/default.asp?W305).

It would be helpful if you could capture separate logs for a couple of solution loads, by:
- exiting VS
- saving the previously generated va.log
- resetting whatever state is necessary to repro
- then enabling logging again
- loading the solution again

Then zip up the saved va.log files and email to support at wholetomato.com
feline Posted - Aug 27 2019 : 2:34:49 PM
In the solution where VA is taking you to the wrong version of the Unreal Engine, have you done a VA symbol database rebuild since changing solutions? The test system I produced from your earlier instructions has two copies of Unreal Engine installed, in two different path's, but VA is always taking me directly to the correct version of Unreal, based on the paths of the files I am jumping to.

Given that Unreal should be part of the solution in all of these cases, I am not sure why VA would be jumping to the wrong version, unless your symbol database is out of date.
feline Posted - Aug 27 2019 : 1:19:03 PM
In theory adding the directories should fix this problem, in both situations, but so far, in my tests, I have been unable to get this to work. I am currently trying to figure out why.

However, I am seeing one important seeming difference with your system. Even when none of the Unreal Engine symbols are being shown in italics by VA, and I have turned On:

VA Options -> Performance -> Parse all files when opening a project

VA is not re-parsing the Unreal Engine code when I close and reload the IDE.

This is what I expect to see, since in these tests the version, and the files making up the engine, have not changed. VA does check to see if the files have changed before reparsing them, so if the version of the engine has not changed, then VA should not be reparsing all of this code.

Are you actually seeing signs that VA is reparsing the entire engine all of the time?
HateDread Posted - Aug 24 2019 : 10:52:35 AM
quote:
Originally posted by feline

I now have a test case set up for your original situation, and I am seeing the problem with no UE symbols being shown in italics. It looks like in this situation VA is not detecting that this is an Unreal Engine using solution, although it clearly is.

I am currently looking into this, to try and see if I can find a solution to fix this.

There is a known problem that VA does not automatically pick up the Unreal Engine stable include directories when Unreal it's self is installed to a different drive letter, which it sounds like you are now encountering:

case=140062



Thanks for the reply - is there any workaround for this known issue? Should I manually add every source directory from the non-C drive UE4 install? E.g. Engine/Source, Engine/Source/Runtime/Launch, Engine/Source/Runtime, Engine/Source/Runtime/Core/Public, etc? It's a lot of manual work :)

EDIT: Can I batch-add a bunch of directories? I could copy the ones automatically-added for my other install and change the paths to match the non-C drive install and reinsert them.
feline Posted - Aug 24 2019 : 10:43:51 AM
I now have a test case set up for your original situation, and I am seeing the problem with no UE symbols being shown in italics. It looks like in this situation VA is not detecting that this is an Unreal Engine using solution, although it clearly is.

I am currently looking into this, to try and see if I can find a solution to fix this.

There is a known problem that VA does not automatically pick up the Unreal Engine stable include directories when Unreal it's self is installed to a different drive letter, which it sounds like you are now encountering:

case=140062
HateDread Posted - Aug 24 2019 : 08:31:05 AM
quote:
Originally posted by feline

Are you able to change the name of the tree that the unreal source code is copied into, "UnrealPackaged" in this case? I have a theory for how to fix this, and am currently running some tests on it now, that I have finally worked out all of the pre-requisites to get Unreal Engine source to compile here.



Oh, I wasn't clear - this time, I'm literally using a version of the engine downloaded using the Epic Games Launcher, just now at this following, non-default path:

quote:
D:\Programming\Tools\Unreal Engine\UE_4.22


I have added D:\Programming\Tools\Unreal Engine\UE_4.22\Source to the system includes in VAX manually.

Interestingly, once I removed this from my system includes in VAX, the UE4 types remain in italics, yet when I jump to them, it's the wrong UE4 version, i.e. a UE4 install in the default location which has been picked up and added to the system includes by VAX automatically.
feline Posted - Aug 24 2019 : 07:41:39 AM
Are you able to change the name of the tree that the unreal source code is copied into, "UnrealPackaged" in this case? I have a theory for how to fix this, and am currently running some tests on it now, that I have finally worked out all of the pre-requisites to get Unreal Engine source to compile here.
HateDread Posted - Aug 24 2019 : 12:27:02 AM
quote:
Originally posted by HateDread

quote:
Originally posted by feline

Apologies for the slow reply, UE4 really does not like being tested in virtual machines, which caused some problems with reproducing this problem here. I have reproduced it here now though, and yes, when UE4 is installed to a different drive VA is not automatically adding the UE4 libraries to your stable include directory list:

case=140062



Hi,

Was there any progress on this case? For example, if I have a stable copy of the engine in a non-standard location, can I avoid the constant reparsing on solution open? I know that the engine won't change.

Disabled parsing on load will make VAX perform much worse, however - I'd like the best of both worlds!



Just thinking about this - as a quick fix, can I add my non-C drive UE4 install to the system includes in VAX permanently? I think if I add them via the VAssistX drop-down menu, they'll only persist until I regenerate the solution, right? That is pretty common in the UE4 workflow, so I'd like to avoid reparsing when doing that. Would be good to permanently add this UE4 install's source directories e.g. via the Windows registry, or have some other GUI-based way to do this.
HateDread Posted - Aug 22 2019 : 09:22:19 AM
quote:
Originally posted by feline

Apologies for the slow reply, UE4 really does not like being tested in virtual machines, which caused some problems with reproducing this problem here. I have reproduced it here now though, and yes, when UE4 is installed to a different drive VA is not automatically adding the UE4 libraries to your stable include directory list:

case=140062



Hi,

Was there any progress on this case? For example, if I have a stable copy of the engine in a non-standard location, can I avoid the constant reparsing on solution open? I know that the engine won't change.

Disabled parsing on load will make VAX perform much worse, however - I'd like the best of both worlds!
feline Posted - Jun 15 2019 : 09:49:25 AM
Wall, head, bang. Every time I try and get this to build, something goes wrong. Eventually I will run out of problems that need to be fixed, and things that need to be done to make this build, and I can actually test this.
HateDread Posted - Jun 05 2019 : 6:40:52 PM
quote:
Originally posted by feline

I am having problems with this, but I don't know why. Perhaps I am just missing something obvious?

I have run the first 5 steps, apparently without any problems. For step 6 I have moved to a different machine where I have the previously installed the Epic Game launcher, and used that to download and install Unreal Engine, and found a simple test game project created there.

Step 7 though, I don't have any sign of this generated engine directory "EngineRoot/LocalBuilds/Engine/Windows". Doing a search across the entire hard drive of both machines, one with the github source code downloaded, and one with the epic engine installed, for something called "LocalBuilds" is not finding anything.

It is possible that this is because I set Github to use the 4.18 branch of Unreal Engine, but I did this since this is the last version of the Unreal Editor that will load in a VMware Workstation virtual machine, which is where I am trying to perform these tests, to avoid making a mess of the machine where I already have the Epic launcher installed, and that installed Unreal editor.

If I don't actually need to run the unreal editor GUI then I can try the same tests with the current version of Unreal Engine.

Which begs the question, when you are doing this, on the machine where you are seeing the problem with VA, have you ever actually run / used the Unreal Editor GUI? I am wondering if this could somehow be a factor in all of this.



It's possible that the BuildGraph system was a bit different in 4.18, but I'm surprised that if that's the case, step 5 still worked. You should see at the end of step 5 some output like (from memory): "Successfully copied to x/y/z", which would be your LocalBuilds. To be clear, when I said "EngineRoot" I literally meant your source build's root directory. So you should see LocalBuilds next to 'Engine' etc. Could be worth trying 4.21 for step 5, and only messing up your install if you get this folder from step 5.

I have definitely run the launcher GUI at some point, for sure.
feline Posted - Jun 05 2019 : 1:37:52 PM
I am having problems with this, but I don't know why. Perhaps I am just missing something obvious?

I have run the first 5 steps, apparently without any problems. For step 6 I have moved to a different machine where I have the previously installed the Epic Game launcher, and used that to download and install Unreal Engine, and found a simple test game project created there.

Step 7 though, I don't have any sign of this generated engine directory "EngineRoot/LocalBuilds/Engine/Windows". Doing a search across the entire hard drive of both machines, one with the github source code downloaded, and one with the epic engine installed, for something called "LocalBuilds" is not finding anything.

It is possible that this is because I set Github to use the 4.18 branch of Unreal Engine, but I did this since this is the last version of the Unreal Editor that will load in a VMware Workstation virtual machine, which is where I am trying to perform these tests, to avoid making a mess of the machine where I already have the Epic launcher installed, and that installed Unreal editor.

If I don't actually need to run the unreal editor GUI then I can try the same tests with the current version of Unreal Engine.

Which begs the question, when you are doing this, on the machine where you are seeing the problem with VA, have you ever actually run / used the Unreal Editor GUI? I am wondering if this could somehow be a factor in all of this.
feline Posted - Jun 04 2019 : 12:19:08 PM
I have a test case for a source build of Unreal Engine, but perhaps it was put together differently. I recall having problems trying to get it to work. I am following these steps now to start creating a new, locally built unreal engine. This will probably take a little while, but it clearly needs doing if there is a separate problem at work here.

Once VA has parsed the Unreal Engine at least once it will be remembered, until you rebuild the VA symbol database. Beyond this, when you open a code file VA will parse the included files, so assuming VA starts with no knowledge of Unreal Engine, it will slowly build up a knowledge of the engine as you open up and edit code files.

VA should also only parse files that have been changed since the last time they were parsed. Part of the problem with Unreal Engine is simply the sheer size, the large number of files to check. Still, VA should be treating unreal as a stable library, which is what I want to test here.
HateDread Posted - Jun 03 2019 : 10:10:31 PM
quote:
Originally posted by feline

The bug is down as an important one, and we are hoping for a fix fairly soon, but I don't currently have an estimate for when this will be fixed.

When you say "not the default location", is the UE code on your main drive, normally C drive, or a different drive letter? This bug is specific to having UE code on a different drive letter, not simply a different install location.

So first up I want to see if this should be a factor in the problems you are seeing.

Are you seeing any pattern to the crashes? It is possible that VA is a factor in these crashes, and if so, that's something we would want to look into. For example, do the crashes happen in a very large solution, after it has been open for a while? If so it is possible you are seeing problems with the IDE process (devenv.exe) running out of memory, since it is a 32bit process and can only access 4gig of RAM at absolute maximum.

In VA options, do you have:

VA Options -> Performance -> Parse all files when opening a project

turned On of Off? If this is turned On, does turning this Off make much of a difference?



It seems like this issue occurs even with UE4 elsewhere on the C: drive.

The complication is (I think) in how you might be determining installed build vs source build.

I'm currently using an installed build we generate ourselves from custom UE4 source, where that installed build is in a non-default location.

Here is a long list of steps, including building a UE4 installed build which will take a while, esp. if you don't have an Incredibuild network across which to distribute the build. A few steps are interconnected so watch out :)

Steps for installed build:
1. Download UE4 source, with e.g. 4.21 branch
2. Run Setup.bat to get dependencies
3. Run GenerateProjectFiles.bat to generation VS solution
4. Open UE4.sln and build just the AutomationTool csproj, then close the sln
5. cd to root of this engine and run something like:


"Engine\Build\BatchFiles\RunUAT.bat" BuildGraph 
-target="Make Installed Build Win64" 
-script="Path\To\Root\Engine\Build\InstalledEngineBuild.xml" 
-clean -set:HostPlatformOnly=true


6. Make/find a UE4 project using the same version of the engine source you pulled from Github, e.g. if you pulled 4.21 branch, use 4.21 in the launcher to make your project (avoids having to build against your newly-generated engine and bloating its size before copying it around in the next step). Can also verify at this step if UE4 symbols are in italics, if desired.

7. Find the generated engine from step 5 at EngineRoot/LocalBuilds/Engine/Windows and copy the folders so they're in a sibling folder to your UE4 project folder, e.g.


Root
    MyUE4ProjectFolder
        MyUE4Project.uproject
    UnrealPackaged
        Engine
        FeaturePacks
        Samples
        Templates


8. Change your UE4 project from step 6 to use this packaged engine version by opening the project's .uproject and set it to use a relative engine path, e.g.


	"EngineAssociation": "../UnrealPackaged",


9. (re)generate a solution for your UE4 project by right-clicking the .uproject file and selecting "Generate Visual Studio project files"

10. Open the solution and observe lack of italics on UE4 classes.

---------------------------------------

Re. crashes - I will keep an eye out. I believe, from memory, that they're mostly around intellisense/VAX operations now that you mention it. The other common situation is for VS to lock into "Microsoft Visual Studio is busy" notification and never escape. Could you see that being VAX-related as well?

Will look into "Parse all files when opening a project". How does VAX build up its understanding of something like UE4 source builds without this option enabled?

[Edited by sean to fix text wrapping/flow on the page -- I broke out the command arguments to separate lines]
feline Posted - Jun 03 2019 : 11:13:29 AM
The bug is down as an important one, and we are hoping for a fix fairly soon, but I don't currently have an estimate for when this will be fixed.

When you say "not the default location", is the UE code on your main drive, normally C drive, or a different drive letter? This bug is specific to having UE code on a different drive letter, not simply a different install location.

So first up I want to see if this should be a factor in the problems you are seeing.

Are you seeing any pattern to the crashes? It is possible that VA is a factor in these crashes, and if so, that's something we would want to look into. For example, do the crashes happen in a very large solution, after it has been open for a while? If so it is possible you are seeing problems with the IDE process (devenv.exe) running out of memory, since it is a 32bit process and can only access 4gig of RAM at absolute maximum.

In VA options, do you have:

VA Options -> Performance -> Parse all files when opening a project

turned On of Off? If this is turned On, does turning this Off make much of a difference?
HateDread Posted - Jun 02 2019 : 07:46:28 AM
quote:
Originally posted by feline

Apologies for the slow reply, UE4 really does not like being tested in virtual machines, which caused some problems with reproducing this problem here. I have reproduced it here now though, and yes, when UE4 is installed to a different drive VA is not automatically adding the UE4 libraries to your stable include directory list:

case=140062



Hi feline,

I'm experiencing the above issue on my work PC as well, where the UE4 install is definitely not in the default location (as is the case for most studios, I imagine, where the launcher builds are not the norm). The reparsing is most brutal when restarting VS after it crashes - nothing makes a crash worse than waiting for a full reparse.

Is there a temporary solution to add UE4 in a non-standard location to the stable include list? Is it that the engine needs to be on the C: drive _anywhere_, or specifically in the default location for this to take effect?

UE4 classes are not in italics for me, as one would expect based on this thread's findings.

Thanks!

EDIT: And what about builds we compile ourselves? Are they supported somehow, if they don't change = no reparse?
feline Posted - May 06 2019 : 10:27:40 AM
Apologies for the slow reply, UE4 really does not like being tested in virtual machines, which caused some problems with reproducing this problem here. I have reproduced it here now though, and yes, when UE4 is installed to a different drive VA is not automatically adding the UE4 libraries to your stable include directory list:

case=140062
NeedVisualAssistanceX Posted - Apr 19 2019 : 11:40:18 PM
So I took a shot in the dark, and long story short, it appears that having my Unreal Engine installed to my D: drive instead of the standard C: drive was the cause for the engine files not being picked up as system includes. After moving my installation there, all of the UE4 directories now populate the C/C++ Directories list, and I can now see Unreal classes being rendered in italics. I also reset my PC, and was delighted to see that it's no longer attempting to re-parse the entire engine.

If you'd like, I can still post the results from System Info if that would be helpful to you, but in my case at least, defaulting to the C: drive solved it. Seems obvious in retrospect that it wouldn't automatically scan the Program Files directory of every hard drive by default, but it took a bit for my brain to get there.

Thanks for your help
feline Posted - Apr 19 2019 : 06:06:48 AM
Both "FVector" and "AActor" are shown in italics for me, testing VS2019 and VA 2324 here.

What about "std::string", is this type shown in italics for you?

Can you please go to:

VA Options -> System Info -> Copy Info

and paste the details (from the clipboard) into your reply. This will give us the basic information about your setup. I would expect to see the unreal directories in your stable include directory list, but I am guessing they won't be there.

How did you install Unreal Engine? Did you use the Epic Game Launcher, or did you download and compile the source code directly from github? Or perhaps some other method?

In Solution Explorer do you have an "Engine" project, holding a "UE4" project? This is the expected structure for a solution using UE4.
NeedVisualAssistanceX Posted - Apr 17 2019 : 10:54:43 PM
Thanks for the reply, feline! To answer your questions:

Using Visual Studio 2019.16.0.1 and I believe I'm on Visual Assist X 2324 - or whatever the latest version is.

I definitely see this happen after resetting my PC. I believe it happens after opening the project again after a few hours, but not 100% on that.

VA Options -> Performance -> Parse all files when opening a project: On

VA Options -> Unreal Engine -> Enable support for Unreal Engine 4: On -> When a solution contains a project named UE4

And I have Show stable symbols in italics On, but don't see any italics in my editor. Assuming things like FVector and AActor qualify as "Unreal classes".

To me, "Parse all files when opening a project" seems like the most obvious culprit, but I've avoided disabling it up to this point because I don't want to disable any useful parsing. However, I'll go ahead and experiment with turning it off, since definitely sounds related.

You've got me curious about the "stable include directory" thing though. I can't recall ever seeing UE4 classes being rendered in italics.
feline Posted - Apr 17 2019 : 07:21:31 AM
Let's start with the basics. Which IDE and version of VA are you using?

When you see this problem, have you used the Unreal Editor to make changes to your solution? Adding new classes or code files? This might be a factor, but it seems unlikely it is always the cause.

Do you have:

VA Options -> Performance -> Parse all files when opening a project

turned On or Off?

What do you have:

VA Options -> Unreal Engine -> Enable support for Unreal Engine 4

set to?

Assuming you have:

VA Options -> Coloring and Attributes -> Show stable symbols in italics

are any of the Unreal classes being shown in italics inside the editor? This will tell us if VA thinks that the Unreal Engine is being treated as a stable include directory, which should stop it being reparsed by VA.

© 2019 Whole Tomato Software, LLC Go To Top Of Page
Snitz Forums 2000