Download

Should I always launch UE4 by running the visual studio project?

I’m a bit confused with the live coding/hot reload system. I understand that any changes to header files and constructors require restarting the engine, but a lot of times simple changes to the cpp file (not in the constructor) will require both a restart of the engine and visual studio.

Just want to know if I’m approaching this incorrectly

no it’s not required, however sometimes the changes u made in code doesn’t take effect in the editor, and u might have to close the engine and launch it from visual studio, or sometimes even delete the blueprint and create it again.

this is why I always suggest to prototype in blueprints and after u made sure the code is working convert that to c++ so u don’t have debug in c++

1 Like

this is why I always suggest to prototype in blueprints and after u made sure the code is working convert that to c++ so u don’t have debug in c++

ahh brilliant idea idk why I don’t do that.

nothing should ever require that you restart visual studio (outside of maybe running out of ram that visual studio can’t figure out how to release…) …

i always run from visual studio

  1. You can ditch slow and clumsy Visual Studio for buggy, but slick IntelliJ Rider
  2. You never have to restart code editor (unless it’s Visual Studio maybe)
  3. You don’t have to reload UE4 if you just make simple edits to .cpp files: there is Live Coding feature which allows you to recompile code while the game is running, this is so awesome

not to start an editor war, ::starts an editor war lol:: but IMO the only thing particularly useful in Rider is the search-all-files, but only if it’s caches are kept up to date. Which takes anywhere from minutes to hours to build.

Funnily, this is the only part I hate in Rider. I keep VS Code instance in background exclusively to do quick searches. This is the only place where it’s possible to find anything in a split second with working shortcuts and without wrong files in results, without weird sorting and without showing you 2 additional tiny code editors for no reason

not to start an editor war, ::starts an editor war lol::

It’s not your fault. If there is a code editor war, a wild me appears

Find-in-All (ctrl+shift+f) in Rider is absolutely wonderful compared to VS’s same function, otherwise it’s just an obnoxious editor to use. It feels like using a janky Java app from 1995 . . . probably because it is a Java app (i think)… and it spends minutes every time i hit any function to think about building whatever caches it needs for any operation to work. :expressionless:

Yes, “Find in Files…” in Rider is much better than this abomination in VS2019. But I was talking about VS Code. Search (and everything else) is just perfect there

Agree about Rider, but in your example, VS2019 would just freeze or show “Completing intellisense operation…” popup that blocks all input. It’s a digest of bad UI decisions, errors are everywhere where possible. The only good things are debugger and color scheme.

I once made a meme on it

The debugger is the issue for me. I do engine work and I spend half my time debugging, but I have no transparency into arrays with the Rider debugger. How that poor excuse for a debug experience ever passed their QA department is beyond me. It’s a shame too because I like almost everything else about it much more than VS, but it’s useless to me without the debugger so… why not just VS full time?

I hope that’s a priority feature for them.

The latest version of Rider is completely broken for me (i believe it’s because I changed the location of all my build tools thanks to a hard disk failure), but I distinctly remember that it had some nicer views of debug information, but not nice enough to make me do my debugging outside of VS, considering how awful the Rider interface is.