| Author |
 Topic  |
|
|
Zeblote
Tomato Guru
183 Posts |
 Posted - May 08 2017 : 9:19:17 PM
|
I'm trying to use VA with an Unreal Engine project.
While exploring the engine source, I'm frequently distracted by wrong colors all over the place.
Some examples I found in a matter of seconds by opening random files, seems to mostly affect class variables:
WorldContext is not a class. Why is it yellow?
More weirdness:
Z is most definitely not a class:
What even happened here?
Both of these fields are FVector4's. Yet one is purple for some reason.
You can probably imagine how this is a little irritating... am I doing something wrong or is it a bug? |
|
|
Zeblote
Tomato Guru
183 Posts |
Posted - May 08 2017 : 9:40:02 PM
|
| Oops, forgot to post the build number and stuff. I'm using VA 2217 (should be the latest one, just installed it today) and VS 2017. |
 |
|
|
feline
Whole Tomato Software
United Kingdom
18748 Posts |
Posted - May 09 2017 : 12:22:13 PM
|
Using VS2015 and VA 2217, I have found the code sample from your first screen shot in the file "GameInstance.cpp", on line 156.
How much do you know about the Unreal Engine source code, and how it is structured? I am seeing the colouring problem here, but I also think I see the reason. I am seeing several instances of "WorldContext" in this code file, but no definitions. It is as if this is a global variable.
But if VA does not know where the correct declaration lives, then it is going to have trouble knowing that this is a variable.
Interestingly, the IDE, in VS2015, cannot find the declaration for WorldContext either. |
zen is the art of being at one with the two'ness |
|
|
|
Zeblote
Tomato Guru
183 Posts |
Posted - May 09 2017 : 1:09:32 PM
|
| The declaration is over in GameInstance.h (it's a class variable), VA must have figured that out too because it shows the hover tooltip properly and Alt+G on WorldContext takes you there. |
|
|
|
Zeblote
Tomato Guru
183 Posts |
Posted - May 15 2017 : 6:22:21 PM
|
Well, is there a solution for this? I still get wrong colors all the time in unreal projects.
The weirdest thing is that if I open the file where the variables are declared, the colors are correct there. So VA clearly knows those symbols should be variables... why are the colors wrong in other files that include them? |
Edited by - Zeblote on May 15 2017 6:24:12 PM |
|
|
|
accord
Whole Tomato Software
United Kingdom
3287 Posts |
Posted - May 16 2017 : 08:13:56 AM
|
For now, as a workaround, you can try VS syntax coloring to see if it works better for this case:
1. uncheck Coloring and attributes -> Text Editor
2. make sure this is set to false Tools -> Options -> Text Editor -> C/C++ -> Advanced -> Disable Semantic Colorization
But it will only work if you haven't disabled default intellisense which might be slow in a large project such as unreal. |
|
|
|
accord
Whole Tomato Software
United Kingdom
3287 Posts |
Posted - May 16 2017 : 08:22:11 AM
|
As for the problem: can you please type .WorldContext. (including the dots) into Find Symbol dialog? You can trigger it by alt+shift+f or by VAssistX -> Find Symbol...
If you do that, do you see more than one instances, defined as different types? VA can have issues with overlapping symbol names. |
|
|
|
feline
Whole Tomato Software
United Kingdom
18748 Posts |
Posted - May 16 2017 : 10:22:11 AM
|
Sorry for the slow reply, I am seeing the problem here, but I have not yet been able to figure out a pattern or rule to explain this.
The symbol "WorldContext" is a member variable, but also an enum item. So it is defined, and should be shown with two different colours, which is known to confuse VA. However it is not shown coloured as an enum. I cannot find any other declarations using this string, even doing a find in files across the entire solution. So none of this explains why in some files, but not other files, VA is colouring this as a type.
Even more interestingly, in GameInstance.cpp I have the VA Context field showing "WorldContext" coloured as a variable, while at the same time the VA Definition field is showing "WorldContext" coloured as a type.
Zeblote, do you know much about the macros that Unreal is using in the Engine code? My current theory is that these are somehow a factor, but this theory isn't helping much so far. If I could find a macro that took "WorldContext" as a parameter, and turned it into a function then this would help to explain this problem, but I have not yet checked all macro calls. This is the next step in my investigation. |
zen is the art of being at one with the two'ness |
|
|
|
Zeblote
Tomato Guru
183 Posts |
Posted - May 16 2017 : 2:33:17 PM
|
Ok, this is the result of find symbol:
And this is the result of find symbol when you check "only classes" at the bottom:
Could the issue with WorldContext be caused this line over in GameViewportClient.cpp?
Maybe the forward declarations are confusing it.
 |
|
|
|
Zeblote
Tomato Guru
183 Posts |
Posted - May 16 2017 : 2:38:31 PM
|
Not sure which macros you are talking about here, but the most common ones are probably the reflection system... where they have macros above variables and classes so Unreal Header Tool can parse them and generate even more macros in the .generated.h files.
Unreal uses such a ginormous amount of macros all over the place, it'd be very hard for anyone to understand how it all works :D |
|
|
|
Zeblote
Tomato Guru
183 Posts |
Posted - May 17 2017 : 07:41:29 AM
|
I removed the forward declaration in GameViewportClient.cpp and now the WorldContext in GameInstance.cpp is purple:
Still wrong though :D |
Edited by - Zeblote on May 17 2017 07:55:03 AM |
|
|
|
feline
Whole Tomato Software
United Kingdom
18748 Posts |
Posted - May 19 2017 : 08:10:02 AM
|
The forward declaration is in fact part of the problem, and VA should not be handling it like this. This is a known bug, and I have put an example from this file into the case, as another test to check:
case=21164
Unfortunately colouring "WorldContext" in purple is probably "correct", in that it is currently the expected behaviour. Since VA colouring has to run very quickly, and without much context, we can be confused by a single symbol being defined as two different types in two different places. Note that "WorldContext" is an enum item, so if your enum items are set to Purple, this makes sense. |
zen is the art of being at one with the two'ness |
|
|
|
Zeblote
Tomato Guru
183 Posts |
Posted - May 19 2017 : 7:55:25 PM
|
Maybe it could track symbols that have multiple declarations, and run some more detailed checks only for those, to get the colors right?
Hovering the mouse over WorldContext shows it in the correct color, so clearly the data is available.
Or maybe attempt to select the correct one based on the context: if a "WorldContext =" is found, the enum one is definitely not correct.
Do you have any plans to improve this in the future? |
Edited by - Zeblote on May 19 2017 7:59:09 PM |
|
|
|
feline
Whole Tomato Software
United Kingdom
18748 Posts |
Posted - May 20 2017 : 10:48:18 AM
|
We are aware of this, and have one eye on this, but we have to work as the IDE dictates we work, since we are working behind the scenes. If we want colouring to keep up with scrolling and editing, then it has to be run very quickly, which means it cannot run to many checks.
Tooltips, and other feedback that runs more slowly is able to check more deeply, since there is the time to be more clever about this. It sounds easy, but it isn't easy in reality, sad to say. |
zen is the art of being at one with the two'ness |
|
|
|
Zeblote
Tomato Guru
183 Posts |
Posted - Jun 06 2017 : 12:37:23 PM
|
The colors also seem to get more wrong while writing/browsing code, and pressing ctrl-s fixes most of them? Very strange.
Before saving:
After saving:
|
|
|
|
feline
Whole Tomato Software
United Kingdom
18748 Posts |
Posted - Jun 06 2017 : 2:48:06 PM
|
If you stop typing and simply wait for a few seconds, to give VA's parser time to catch up, does this have any effect on the colouring?
If this has no effect, can you try the command:
VAssistX -> Tools -> Reparse Current File
and see if this has any effect? |
zen is the art of being at one with the two'ness |
|
|
|
Zeblote
Tomato Guru
183 Posts |
Posted - Jun 06 2017 : 3:21:07 PM
|
Colors don't seem to change on their own if I just wait.
Reparse current file has the opposite effect - it resets the colors to the broken "before saving" image. |
|
|
|
feline
Whole Tomato Software
United Kingdom
18748 Posts |
Posted - Jun 06 2017 : 4:24:45 PM
|
| If you place the caret into one of the wrongly coloured symbols, does VA show the correct information in its context and definition fields? These are normally shown at the top of the editor, and are where the Alt-M list appears. |
zen is the art of being at one with the two'ness |
|
|
|
Zeblote
Tomato Guru
183 Posts |
Posted - Jun 06 2017 : 4:52:34 PM
|
It shows the correct information, and it also seems to fix the colors for that specific line
Before click:
After click:
Interestingly the color in the status bar is still wrong:
|
Edited by - Zeblote on Jun 06 2017 4:54:39 PM |
|
|
|
feline
Whole Tomato Software
United Kingdom
18748 Posts |
Posted - Jun 07 2017 : 05:25:09 AM
|
Can you please open VA's Find Symbol dialog, Alt-Shift-S, and use the filters:
.Position.
and
.Normal.
.Add.
I am wondering if these symbols are both member functions and something else, perhaps enum items. |
zen is the art of being at one with the two'ness |
|
|
|
Zeblote
Tomato Guru
183 Posts |
Posted - Jun 07 2017 : 10:00:58 AM
|
| Well it finds hundreds of results for common terms like that, variables, structs, enums, everything. But why does it instantly figure out the correct color when the cursor is placed on it? |
|
|
|
feline
Whole Tomato Software
United Kingdom
18748 Posts |
Posted - Jun 08 2017 : 08:01:52 AM
|
"normal" colouring has to run very fast, to keep up with scrolling through a code file. When you hover the mouse over a single symbol, you are giving VA plenty of time, and only a single symbol to think about, as opposed to an entire screen full of symbols.
Also, since VA often wants to update VA View with the type information for this symbol, we have the time to think about it, and it is important to think about it. So the result is that the two situations are fairly different.
We do our best to apply the correct colouring all of the time, but correct colouring and fast colouring are pulling in opposite directions. |
zen is the art of being at one with the two'ness |
|
|
| |
Topic |
|
Wrong colors all over the place
