| 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! |
| 30 L A T E S T R E P L I E S (Newest First) |
| feline |
Posted - Sep 07 2022 : 07:11:16 AM
Apologies for the delay in getting back to you about this, but I have just emailed you about this. I have a basic working script if you are interested in trying it.
case=148557 |
| Shambler |
Posted - Aug 17 2022 : 09:50:24 AM
Thanks for submitting those cases, each of those would be a big help alright!
Sure yes, a script to backup the database would be a very big help, which I could integrate as a step in my workspace setup process - to be run after initial parsing is complete. I'd be more than happy to try that out, and report back if it helps me recover when parsing starts up again (though which is unpredictable as to when it may happen). |
| feline |
Posted - Aug 17 2022 : 06:57:13 AM
Firstly apologies for all of these problems. We are considering having VA parsing limit its self as much as possible, automatically, when you start building:
case=96201
You are not the first person to ask about a manual pause option, but this would clearly make a lot of difference when working with 2 Unreal Engine solutions at once, so I have put in a feature request for this:
case=148447
As for backing up the symbol database, I have also put in a feature request for this:
case=148446
Would you be interested if I tried to work out a couple of scripts to emulate this feature? I am thinking run a simple script to back up / zip, the current VA symbol database, and a second script to restore the most recent symbol database backup and then load the IDE once the backup has finished.
This would obviously be a manual process, but you could change the IDE shortcut to the restore and load script if this was an option you wanted to test out. |
| Shambler |
Posted - Aug 16 2022 : 6:31:03 PM
Just a bump to note that this is a perpetually recurring problem with VAX and it's a productivity killer. Between two instances of VS2022 with different UE projects, both databases for each project have managed to nuke themselves after fully generating, and are rebuilding from scratch - to the point that more CPU time has been spent rebuilding databases today than doing a full compile of UE.
Not really able to spend time trying to help debug this - there need to be a few things that future VAX versions sort out, though:
1: Databases must never be corruptible. Even if it means keeping an entire backup database. Even a single extra reparse of UE is too much wasted time/resources.
2: There needs to be a simple menu option to stop/resume parsing - as just turning off VAX is the only way to restore productivity sometimes.
3: Don't reparse during builds - have it automatically stop. |
| feline |
Posted - May 13 2022 : 06:40:02 AM
All I can do is apologise again, but given the problems you are seeing, I can see why you have to move on.
I just hope that things go more smoothly for you in the future. |
| OmegaNemesis28 |
Posted - May 13 2022 : 12:38:47 AM
quote:
Originally posted by feline
I didn't expect the IDE's clang formatting to depend on the intellisense database, but indeed it does. That is a bit unhelpful, I assume that clang format has been merged into the IDE, rather than existing as a stand alone tool.
If you want to try disabling IDE intellisense, I have found this extension:
https://marketplace.visualstudio.com/items?itemName=LLVMExtensions.ClangFormat&ssr=false#overview
based on a couple of quick tests, it is picking up and using my ".clang-format" file without having to do anything, but it is using a different keyboard shortcut to trigger formatting by default than the IDE.
For plugin parsing, setting:
VA Options -> Projects and Files -> Upon opening a file, parse all other unparsed files in the same directory:
* if Solution is not empty
Since the plugins are split into directories, this will let VA parse one directory at a time, if the files have not already been parsed. Not ideal, but it should help.
Another thought, although it is rather manual, is to make a backup copy of VA's symbol database directory after VA has finished parsing everything, but before you have done much, so open the IDE, let VA's parsing finish, I am thinking over night here, then close the IDE and back up the directory. From the log file line above we know it is currently stored in:
c:\users\SomeUser\appdata\local\microsoft\visualstudio\16.0_ccada75a\extensions\xlb0fwhn.es0\Data\vs16_1
you could use a script to copy the database copy back across, and then load the IDE, so it gets done in "one" action.
A bit ugly, and I would love to get to the bottom of this corruption problem so you don't have to consider this, but it is a thought.
So I went ahead and disabled the intellisense database setting, and the issue still occurs. Possibly worse than before, VS crashed at least once. But otherwise, I just shutdown VS like normal.
Today I've had VSX reparse my solution 3 times today alone, over an hour of time lost waiting for it parse. I can't really be spending my time like this unfortunately, so I have to move on. |
| feline |
Posted - May 04 2022 : 05:44:51 AM
I didn't expect the IDE's clang formatting to depend on the intellisense database, but indeed it does. That is a bit unhelpful, I assume that clang format has been merged into the IDE, rather than existing as a stand alone tool.
If you want to try disabling IDE intellisense, I have found this extension:
https://marketplace.visualstudio.com/items?itemName=LLVMExtensions.ClangFormat&ssr=false#overview
based on a couple of quick tests, it is picking up and using my ".clang-format" file without having to do anything, but it is using a different keyboard shortcut to trigger formatting by default than the IDE.
For plugin parsing, setting:
VA Options -> Projects and Files -> Upon opening a file, parse all other unparsed files in the same directory:
* if Solution is not empty
Since the plugins are split into directories, this will let VA parse one directory at a time, if the files have not already been parsed. Not ideal, but it should help.
Another thought, although it is rather manual, is to make a backup copy of VA's symbol database directory after VA has finished parsing everything, but before you have done much, so open the IDE, let VA's parsing finish, I am thinking over night here, then close the IDE and back up the directory. From the log file line above we know it is currently stored in:
c:\users\SomeUser\appdata\local\microsoft\visualstudio\16.0_ccada75a\extensions\xlb0fwhn.es0\Data\vs16_1
you could use a script to copy the database copy back across, and then load the IDE, so it gets done in "one" action.
A bit ugly, and I would love to get to the bottom of this corruption problem so you don't have to consider this, but it is a thought. |
| OmegaNemesis28 |
Posted - May 02 2022 : 4:16:12 PM
quote:
Originally posted by feline
Apologies for this. The corrupt database will explain the regular reparsing, but it doesn't give us any clues as to the source of the corruption. Are you seeing the IDE crash at all? I assume not, since you probably would have mentioned it, but best to ask and check.
I am asking our developers if they have any way to help us track the cause of the corruption, since it should not be turning up like this:
case=148072
The over slow parsing problem I have run into, so far is only showing up when VA is told that Unreal Engine is on a different drive letter, so I will double check that this path on C drive doesn't seem to trigger it as well.
In VA Options, what do you have:
VA Options -> Unreal Engine -> Index plugins (requires restart) = None / Referenced / All
set to? Setting this to None or Referenced should speed parsing up a fair bit, by cutting down the amount of code that VA needs to parse.
Do you have IDE intellisense Enabled or Disabled? This is normally disabled via:
IDE tools menu -> Options -> Text Editor -> C/C++ -> Advanced -> Disable Database = True
it might be worth trying to disable this, if it isn't already disabled. I am thinking about the total amount of memory the IDE uses, since VS2019 is a 32bit process, and is limited to 3 GB of RAM, and Unreal Engine makes for a very large solution.
Plugins is currently none (I'd like to have it on but can't risk the downtime)
Disable Database is false. I can try to set it to true temporarily but that will remove ClangFormat support which I rely on.
VS itself usually doesn't crash on me. UE can crash often though. |
| feline |
Posted - Apr 25 2022 : 07:53:16 AM
No obvious performance problems here, placing UE 5 under "C:\Root\Engine\"
Getting VA to rebuild its entire symbol database, using the UE setting:
VA Options -> Unreal Engine -> Index plugins (requires restart) = Referenced
took about 20 minutes. This is accessing UE via a junction point. So you should not be running into the really slow VA parsing bug I have encountered with this UE install location. |
| feline |
Posted - Apr 22 2022 : 06:55:33 AM
Apologies for this. The corrupt database will explain the regular reparsing, but it doesn't give us any clues as to the source of the corruption. Are you seeing the IDE crash at all? I assume not, since you probably would have mentioned it, but best to ask and check.
I am asking our developers if they have any way to help us track the cause of the corruption, since it should not be turning up like this:
case=148072
The over slow parsing problem I have run into, so far is only showing up when VA is told that Unreal Engine is on a different drive letter, so I will double check that this path on C drive doesn't seem to trigger it as well.
In VA Options, what do you have:
VA Options -> Unreal Engine -> Index plugins (requires restart) = None / Referenced / All
set to? Setting this to None or Referenced should speed parsing up a fair bit, by cutting down the amount of code that VA needs to parse.
Do you have IDE intellisense Enabled or Disabled? This is normally disabled via:
IDE tools menu -> Options -> Text Editor -> C/C++ -> Advanced -> Disable Database = True
it might be worth trying to disable this, if it isn't already disabled. I am thinking about the total amount of memory the IDE uses, since VS2019 is a 32bit process, and is limited to 3 GB of RAM, and Unreal Engine makes for a very large solution. |
| OmegaNemesis28 |
Posted - Apr 21 2022 : 8:52:13 PM
The corrupt database is correct, I'm seeing a lot of it.
GetSymDefStrs idx c:\users\SomeUser\appdata\local\microsoft\visualstudio\16.0_ccada75a\extensions\xlb0fwhn.es0\Data\vs16_1\cpp\Db10Ds.db is corrupt, fid=0x56772f12, sp=0x2, rel=0xcba0, act=0x204db5 tid=87492 uiTid=130840:330 4/21/2022 20:25:55 0x155c4
Where Db<>s.db is a bunch of various files saying similar. So something is corrupting them. I have another thread open about the VSX slow parsing but I havent had time to go through those steps yet. But if I can fix the corrupting leading to the reparsing as the root of the issue then it wouldn't be so bad.
To answer the first question of the C++ directories if that matters, they are pointing to `C:\Root\Engine\` where `Root` is a symlink to my D drive, both SSDs.
|
| feline |
Posted - Apr 11 2022 : 07:49:57 AM
Clearly this shouldn't be happening. Also, it sounds like VA is taking longer than it should to parse Unreal Engine, unless you have a slower machine.
As a first check, can you please open VA's Options dialog and go to the C/C++ Directories page. Does VA list all of the directories inside Unreal Engine 5 in the list of stable include directories?
If not, where, on which drive and in which directory do you have Unreal Engine installed? 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\", which you might be running into, and I do have a work around for this, which might help a bit.
You mention logs, can you please look for the file
C:\Users\%USERNAME%\AppData\Local\Microsoft\VisualStudio\<IDE version>\Extensions\<random hash>\Data\Startup.log
where the IDE version directory will be "16.0.xxx" where the last part is a hash. You should only have one such directory though, making it easy to find. Another user who is reporting regular reparsing of Unreal Engine does have this file, and it is logging messages about VA's symbol database being corrupt, so its possible you will have the same thing.
If VA detects that its symbol database is corrupt then it will automatically rebuilt it, which seems to be why the other user is seeing VA doing a lot of reparsing of Unreal Engine. |
| OmegaNemesis28 |
Posted - Apr 08 2022 : 2:16:36 PM
Just reviving this thread since it seems like it's a problem even with UE5 source. I catch my VSX in VS2019 doing this sporadically when I open the solution up, reparsing the entire contents of my Engine source folder when it's definitely done it before. This means I cannot use VSX for up to an hour after opening my solution.
It does not reliably happen on load, something seems to trigger it and I can never collect logs on it when it happens because it's already happening. I'll try to remember to always enable logging every time I reboot VSX since it turns off automatically which it difficult to track. If I do collect logs, I'll post them here and email as well.
VA_X.dll file version 10.9.2440.0 built 2021.11.17
DevEnv.exe version 16.11.32228.343 Professional
msenv.dll version 16.0.32228.297
Comctl32.dll version 6.10.19041.1110
Windows 10 10.0 2009 Build 19044.1586
64 processors (x86-64, WOW64)
Language info: 1252, 0x409 |
| 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 [email protected], 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? |
|
|
