Visual Studio / Unreal Engine workflow

I’m not clear on the Visual Studio/UE workflow.
(I’m using VS 2022 and UE 5.7, VS Integration Tools disabled because for some reason when that’s enabled, CTRL+ALT+F11 stop working )

For example, I add a UArrowComponent from code to a class, press CTRL+ALT+F11 to build from UE and the arrow component shows up in the blueprint based on that class, as expected.

But then from code I change the arrow starting position in the constructor, save, build again from UE, but this time the arrow doesn’t update its position!
And then if I restart UE and press CTRL+ALT+F11 again, this time it update the position…

So, am I supposed to do a restart of UE every time I change the value of a variable?!
Is this how it’s supposed to be or am I using it wrong?

Because if this is the standard, then there is 0 incentive in using any C++ (although I would really love to, since to me using Unreal is more of an excuse to practice C++ and improve as a programmer) instead of just doing everything inside Unreal with Blueprint.

Please, tell me I’m doing something wrong and that this is not the expected workflow, because this is a miserable experience…

Thats a narrow perpsective on c++!

And yes everytime you make changes in your .h or.cpp add new components en blueprints though c++ you need to close unreal before you make the changes. cause the livecoding gives issues.

you also sometimes have to force unreal to rebuild by deleting your binairy. intermediate en . vs map, right click on your uproject/more options/ generate visual studio files en rebuild after restoring to avoid stale memory data. Its a pain but it keeps your app scalable for future modules and functions

I use a hybrid Unreal Engine architecture where C++ handles the core systems, data structures, logic, persistence, and performance-critical functionality, while Blueprints are used for orchestration, interaction flow, UI, rapid iteration, and designer-facing systems.

this also eliminates sphagetti blueprints (my brain gets a real mailfunction when i see all those cross wires lol).

C++ provides:

  • core systems and processing

  • reconstruction and measurement logic

  • persistent data/state handling

  • modular backend-oriented systems

  • optimized runtime components

Blueprints provide:

  • gameplay orchestration

  • UI workflows

  • interaction chains

  • rapid prototyping

  • spatial experience logic

  • visualization and iteration layers

The architecture follows a layered approach:

  • C++ = infrastructure and systems

  • Blueprints = orchestration and experience layer

This allows fast iteration without sacrificing scalability or performance.

What do you mean?

Also I remember toying with this some 3-4 years back, and although my memory is hazy, I don’t remember any problem of this sort - you would just recompile and see the change reflected in the editor.
Is this something that regressed with recent releases?

My reply is based on your “0 incentitive” comment, i dont know about the regression, i use visual studio 2026, unreal 5.7.4 and c++ for a few weeks now and spend hours debugging cause it was not working Only to find out it was the live coding that gives issues and unreal using stale memory. since ive been doing this, it usually solves the problem , that means if your code is correct

Oh, I only meant I personally had no incentive - I don’t program to make a game, I make a game to learn how to program - and so if I’m wasting all this time just restarting the engine and loading the project every time, I’m getting very little progress out of it.

But I could swear, this used to work much better and it used to be a joy to use VS and UE together.

Thi is a issue with Epic imo - they don’t value the user experience enough.
And this is also why I don’t think they’ll ever surpass Steam. The other day I simply clicked between my library and another tab, and it would take it a good second to switch between, appalling.

They have the greatest engineering minds on the planet, so I simply cannot comprehend how this is the end result.

  • end of rant

Hello,

I just want to add a more moderate view to the idea that you’d have to randomly delete your intermediate and binaries folder to avoid stale data, as if it were a regular housekeeping task.

I would recommend it after upgrading your engine version, but if you don’t encounter issues, you don’t really need to randomly delete these folders. I use 40-50 custom plugins in my game and can’t remember the last time I had to do this outside of an engine version change.

(Maybe if you force cancel compilation partway through, or if you abuse livecoding too much, idk)

Now, for your initial live coding/constructor edition question/rant, I feel like a there’s a few things to add:

1- Unreal Engine uses Class Default Objects, or CDOs, to underpin a bunch of the class instancing & blueprint creation. Basically, at engine startup, the constructors are all ran once, the result is stored, and then once you make a new instance, it basically copies the CDO. This is why, when you edit a variable after the fact with livecoding, the change won’t propagate until you’ve restarted the editor.

I should also point out that if you were to change this variable in your BP, it would be flagged as being overriden, and from this point on, you can’t really alter it by changing the C++ constructor.

2- The use of C++ constructors in UE should be done carefully. I know it’s standard practice in most coding languages/frameworks, but in UE it’s a bit more different. Namely because of point 1-, but also because this whole CDO business means that the code inside is executed at a time where most engine features are unavailable. Thus, while it is absolutely allowed to use constructors for some simple things (for instance to add default subobjects etc), you should always consider putting most initialization code into later functions, like BeginPlay, PostInitializeComponent, or any other of the gazillion lifecycle hook virtual functions that I forget.

Happy coding!

Thank you for the tips / explanation!
Also after starting this topic I had went to learn more about it, so I don’t necessarily feel that way anymore.

I was remembering the experience being smoother in the past, but that was only because I was following a Udemy course and they had me dance around the pitfalls without me even realizing.

The key takeaways for people encountering those same struggles and frustrations, are summarized in this reddit post.

My takeaway is this:

.cpp changes that are not in a constructor → Live Coding should be safe

.h changes that impact reflected types/layout (UCLASS, UPROPERTY, UFUNCTION, inheritance, adding variables etc…) → compile from VS and then start Unreal Engine from the green triangle button

Also a tip to other beginners from me, that hopefully is correct: from VS, from the Solution Explorer right click on the game and rebuild only that, not the entire Engine.