What's your C++ work flow with VS17

Hi all, just a simple question:

I had already developped some programs in C++ and recently tried to use it with Visual Studio 17 and UE4 but I often ended closing and reopening the project or visual studio because of compilation issues, reloading multiple times my blueprint created from C++ class and get conflicts, etc…

So, what are the good methods to:

  • Add Code to project (from UE or VS?)
  • Edit existing classes when blueprint are based on them
  • Reload blueprints after code editing

Hope the question was clear

  • Add Code to project (from UE or VS?)

Any method that can place files in right place and you feel comftibule with, but whatever method you do you need to regenerate project files. “Add Class” do that for you also put some ready template for the class.

Keep in mind that only VS compiler, uproject file and build acripts (*.cs files) is needed for UBT to build your code, the VS project it self is not used at all in that process, only reason why it exist is to let you easily edit code in VS. And yes that means you dont really need to regenerate project file to build added code files, UBT automaticly detect them if oyu build for example using “Compile” button in editor.

-Edit existing classes when blueprint are based on them

Don’t modify names of things you using in blueprint as this will invalidate nodes, you can use DisplayName meta specifier to modify name without modifing name of function or varable. Also don’t modify arguments, or atleast keep them in same order and add thigns at the end. Generally modifying class structure may mess up hot reloading, but this can be fixed by restarting editor. Modifying code of functions itself should not effect blueprint stracture

-Reload blueprints after code editing

Blueprint editor don’t know how to deal with function changes (that why it is the best t not modify names of things you already use), anything that breaks you need to fix manually.

My only recommendation is:

  1. Create your C++ project from the
    editor;
  2. Save the project and close the
    editor;
  3. Open your project in VS17; (It should be already opened if you’ve just created it)
  4. Build and run in VS debug; (this
    should start the Unreal Editor with your project opened)
  5. NEVER start the editor on it’s
    own or through the launcher. Always
    open your C++ projects from debug in VS17.

I hope this at least lowers the frequency of compilation issues.

Hi, thakns for your answer. So basically I have to be sure of my class structure before creating a blueprint based on it, otherwise it will have great chances to break it is that right ?

Thanks for your answer, short and clear. So you recommand opening VS and build for it to open the UE project?

Correct.

The Unreal Editor project is already compiled but if you start it through debug build in VS17 you will load all symbols needed and VS will actually let you debug crashes during your project loading.

Compiling and running your actual game from that point on is done through the editor.

The good thing about adding code from the editor is that it will automatically add all the necessary includes and even your copyright notice to all files.

Hot reload will only work when you edit code inside existing functions. If you add new functions or variables you will have to close the editor and compile from vs.

Run your project from VA debugger and if possible use Debug instead Development config. It will help you with debugging as development config let’s the compiler do some code optimizations that will make difficult debugging your code.

Blueprints will automatically adapt to changes made in C++ unless you are renaming your base classes. In that case you will have to configure class redirectors in you project config ini files.

In most cases you will want to implement your game logic in C++ and make blueprints as data only as possible but it’s ok to implement things in blueprints if you are in a heavy iteration stage like prototyping. You can always move your logic to C++ later.

pretty much, atleast that healthest way of doing it. Ofcorse only parts that you actually used in blueprint, adding new functions and variables should not harm blueprint.