[Request] Changes to the 'Generate Visual Studio Files' tool

Development Programming & Scripting
1

Hello friendly neighbourhood Epic staff,

I have written some automation tools, external to Rocket, that could improve our productivity with the engine. There are a few snags, however, that would best be solved on your end. They are pretty minor changes (I assume), otherwise I would not ask it of you. They all involve the ‘Generate Visual Studio Files’ tool.

1 - Could any Visual Studio paths generated by the tool be rooted in an environment variable that points to the relevant install directories?

OR, failing that,

1 - Could any visual studio paths generated by the tool that refer to the Program Files directory be rooted in the %PROGRAMFILES% environment variable, instead of a hard directory path?

Either of these would allow me to dynamically modify the build tool location and include directories of the Visual Studio project instead of tedious manual re-modification every time new files need to be generated. In my case, a batch file could provide a temporary substitute before running the software, losing influence when the software closes.

2 - Could the tool be changed to maintain any filters that exist in any Visual Studio project file it is overwriting? At the moment it just creates filters that mimic the directory structure, requiring physical separation in the file system to maintain a clean file browser inside of Visual Studio. It is, of course, manually adjustable after generation, but I figure I may as well ask while I write this up.

3 - Is the tool available through the command line? If not, would it require much work to make it so?

The reason I ask is that the tool is only available through the right-click menu on systems with Rocket installed. On systems with access to Rocket, but not an actual ‘installation’ (portable drive installs, off-site setups), it is unavailable. Even manually associating the extensions does not give access to the tool.

I understand that these requests are not what you would call ‘in demand’ by the majority of the user-base, so I am not expecting you to go to trouble for them, but I would appreciate their implementation if they are deemed worthy of the effort.

Thank you.

2

Hi Andrew,

You have made this post Private, but it contains no confidential information. Would you object to me making it Public so that others can see the questions and answers as well?

Thanks

3

That’s fine.

4

I can probably answer #2 as well. Keeping the project structure in sync with the filesystem was desirable for us historically, so this is the direction we have taken. Theoretically you could just generate the project once and maintain it yourself after creation, but there will be no support for that workflow.

5

Thanks for the response again, you’ve been very helpful. I understand why you have done it the way you have. I figure I will just write a wrapper for the batch file that can maintain select settings (such as filters) across regeneration. That should give me the best of both worlds.

6

I can answer #3. You can invoke RocketGenerateProjectFiles.bat directly. It is found in the Rocket/Engine/Build/BatchFiles directory.

7

Great, thank you.