Changing build target to DebugGame Editor is a good start, but it doesn’t work for all cases. When it happens, you can manually disable optimization for specific portion of code. Then you can freely step through it.
But keep in mind that even then, it might not work perfectly (or it might not seem like it does). I don’t know this for sure, but when you step through code it sometimes falsifies the line at which execution of the program actually is. I’m guessing that it’s caused by usage of macros above the line you’re at but I’m not sure about that.
It won’t work as expected when code from the game and from VS doesn’t match.
Anyway, to disable optimization for given code just use this:
#pragma optimize( "", off )
// your code
#pragma optimize( "", on )
It’s meant to be used temporary for the time you want to test given code. It rather shouldn’t be left out there in release code afaik.
I never had to use this in functions implemented in headers so I’m not sure if it would work there.
For inline, header functions you could use FORCEINLINE_DEBUGGABLE macro. I’ve seen it couple times in engine, but I never had to test that.
Usage:
FORCEINLINE_DEBUGGABLE void Function()
{
// Do stuff
}
See engine example (github account linked to UE account is required to read this)