Whole Tomato Software Forums
Whole Tomato Software Forums
Main Site | Profile | Register | Active Topics | Members | Search | FAQ
User name:
Password:
Save Password
Forgot your password?

 All Forums
 Visual Assist
 Technical Support
 2021.01.26 and unreal engine skipping indexing
 New Topic  Reply to Topic
 Printer Friendly
Author Previous Topic Topic Next Topic  

msew
Ketchup Master

86 Posts

Posted - Feb 18 2021 :  3:19:30 PM  Show Profile  Reply with Quote
So 2021.01.26 has unreal engine skipping indexing of plugins by default.

I don't think this is what you want to do.

LARGE portions of the engine are in plugins. And those portions are often what you use.

So, by default, when we got the new version of VAX Visual Studio became un-usable.


In our game, most everything we are writing are also plugins. So it was even worse for us lol.



I think you could add try skipping Engine/Source/ThirdParty/... as a defaulted on option.

But I think Plugins need to be included (even tho it takes time to parse them all) as that is where a huge portion of the engine's functionality lies these days.

evolution
Ketchup Master

USA
96 Posts

Posted - Feb 18 2021 :  8:47:40 PM  Show Profile  Reply with Quote
I'm loving the new option when working in projects that don't need anything from Engine\Plugins. All of these plug-ins add an overwhelming amount of noise to symbol lookups, suggestion lists, etc. But yeah, it's pretty common these days for studios to have functionality that they want to share across UE4 uprojects, so those go into Engine\Plugins.

Maybe a reasonable tradeoff for VAX would be to separate plug-ins into two categories based on which ones are enabled in the uproject files, then have the active plugins be enabled by default.

what could possibly go wrong? :D
Go to Top of Page

feline
Whole Tomato Software

United Kingdom
17186 Posts

Posted - Feb 19 2021 :  08:33:12 AM  Show Profile  Reply with Quote
Currently we work out what to skip by looking at the directory structure inside the Unreal Engine directory tree.

Skipping all plugins was done to make a large difference to both parsing time and memory usage when working with Unreal Engine, so we don't want to add in to many more plugins by default, if we don't need to. We considered separating out the ThirdParty sub-directory, but found that it didn't make much difference to the parsing and memory usage.

evolution, do you tend to work on several different Unreal Engine solutions, or just one? I am wondering if the list of "enabled" plugins is going to grow over time as we consider more projects.

Currently VA works out what it is doing by parsing the Visual Studio solution and project files, not the .uproject files.

Looking at some .uproject files the plugin section seems fairly straight forward. However, looking inside the "SteamVR.uplugin" file, picked at random, while I work out what is going on here, I am finding that this also references yet another plugin.

Assuming VA parses the included and enabled plugins, would we also need to then find and parse all of the enabled plugins that these plugins also reference? I can see this spreading out a bit, but if we need to parse these files to be useful, then we need to. I just wonder how many plugins we will be able to skip and this how much we will be able to reduce parsing time and memory consumption.

zen is the art of being at one with the two'ness
Go to Top of Page

evolution
Ketchup Master

USA
96 Posts

Posted - Feb 19 2021 :  12:11:36 PM  Show Profile  Reply with Quote
quote:
Originally posted by feline
evolution, do you tend to work on several different Unreal Engine solutions, or just one? I am wondering if the list of "enabled" plugins is going to grow over time as we consider more projects.



Both. As a consultant I work in several different solutions (usually containing a single project/uproject under the "Games" folder of the solution), but I think the majority of game developers will be working with a single solution and single uproject. Far less common is to have multiple uprojects within a single solution.

But what seems to be pretty common is having a single [mostly empty] uproject under "Games", with all the actual functionality implemented across multiple plug-ins inside the UE4 project (I think this is what msew is describing). This makes it easier to move functionality between different custom builds of the engine, such as when you have multiple organizations that are maybe using different versions of UE4 but want to share functionality, or to share functionality between uprojects.

It's hard to say how many UE4 users work across multiple solutions vs a single one. Indie devs, consultants, contractors etc. probably tend to work in more than one solution, with completely different sets of unrelated plug-ins enabled in each one. But I bet most game developers work in a single solution most of the time (aside from having multiple similar copies of the solution in different p4 branches, of course).

If the set of plug-ins VAX parses is global to the machine/user, rather than per-solution, then yeah I guess parsing a union of all enabled plug-ins across all solutions is probably not as much as an optimization (but it probably still IS an optimization worth having). Applying the same parsing settings to all UE4 solutions on the machine seems like it makes more sense for the public versions of the engine, since those will generally be the same across all users of the engine. But not so much for users that download the source from epic's p4 or github, then customize it.


what could possibly go wrong? :D
Go to Top of Page

feline
Whole Tomato Software

United Kingdom
17186 Posts

Posted - Feb 22 2021 :  07:20:33 AM  Show Profile  Reply with Quote
I just want to have a good sense of what we want to achieve here before putting in the feature request. I know enough to support VA's parsing of Unreal Engine, but I still know basically nothing about Unreal Engine its self.

I was going to start with the assumption that there is only one UPROJECT file that we need to check, but you have just stated that there can be more than one per solution. Do you know if they are always referenced by the Visual Studio projects?

Looking at my various simple example projects here, both from GitHub downloaded source code compiled, and from downloaded Unreal Engine, the UPROJECT files are not mentioned in the SLN files, but they are included in the project, VCXPROJ files. If this always holds then we can locate all of the UPROJECT files we should check for a given solution.

It looks like plugins are just referenced by name. Is it safe to assume that the names are unique? I am not seeing anything other than their name so far to help locate them, so I hope this is a reasonable assumption.

So far every plugin reference I have checked has a matching .UPLUGIN file somewhere in the engine tree. So it looks like we just have to append the plugin extension then go hunting for it. Then spread out from there for every other included, enabled plugin.

Definitely more parsing, but if we are not parsing enough code to be helpful, then the setting just isn't going to work for a lot of our users.

zen is the art of being at one with the two'ness
Go to Top of Page

evolution
Ketchup Master

USA
96 Posts

Posted - Feb 22 2021 :  1:07:26 PM  Show Profile  Reply with Quote
quote:
Originally posted by feline
I was going to start with the assumption that there is only one UPROJECT file that we need to check, but you have just stated that there can be more than one per solution. Do you know if they are always referenced by the Visual Studio projects?

Yes, they are always referenced by vcxproj files, as vcxproj files are autogenerated by the UE4 tools. When you have multiple project folders under your UE4 root directory, you can generate a solution containing all of those projects, or you can pass in the project name (to GenerateProjectFiles.bat) to generate a solution with only that project. Each uproject will be represented by its own vcxproj in the solution.

quote:
It looks like plugins are just referenced by name. Is it safe to assume that the names are unique? I am not seeing anything other than their name so far to help locate them, so I hope this is a reasonable assumption.

This is a safe assumption, with the exception that game plugins (plug-ins located in the Plugins directory of a uproject, as opposed to the Plugins directory of the Engine folder itself) override engine plugins of the same name. If you have Engine\Plugins\Foo and MyProject\Plugins\Foo, MyProject\Plugins\Foo is the one that will be used.

quote:
So far every plugin reference I have checked has a matching .UPLUGIN file somewhere in the engine tree. So it looks like we just have to append the plugin extension then go hunting for it. Then spread out from there for every other included, enabled plugin.

Yep, pretty much! Keeping in mind that game/project plugins override engine plugins of the same name. You can check out FPluginManager::ReadAllPlugins in UE4 to see some of the logic at play (references to manifests are for packaged builds, I think - such as when you're packaging for a console). In fact, in that method I see references to other types of plug-ins as well, like "mods" and "enterprise" plug-ins. These are other modes that UE4 can support. I don't know much about the enterprise stuff beyond that it's for non-game applications like architecture planning. Mods are for a way for end-users to add their own content to released games, though I'm not sure how widely used that functionality is.

I hope that helps!

what could possibly go wrong? :D
Go to Top of Page

feline
Whole Tomato Software

United Kingdom
17186 Posts

Posted - Feb 23 2021 :  08:59:17 AM  Show Profile  Reply with Quote
Thank you, very helpful. I have put in a feature request for this, detailing what we would need to do to achieve this. A bit more complex than the current "skip all plugins" approach, but clearly a lot more useful.

case=144467

Still, I am not sure how quickly we will try something like this, given the extra complexity, and it not being clear how much parsing time this would save us. It would obviously vary a lot from system to system.

zen is the art of being at one with the two'ness
Go to Top of Page
  Previous Topic Topic Next Topic  
 New Topic  Reply to Topic
 Printer Friendly
Jump To:
© 2019 Whole Tomato Software, LLC Go To Top Of Page
Snitz Forums 2000