I have programmed assembler for 6502, 68000, went on to c++ and have worked with C#/Net now for 20+ years. I am back to the passion of game dev and I just want some input from those of you who are much more experienced in the environment of UE.
I know everything about the greater things in UE, mastering everything from creating materials and shaders, through translating animation rigs, doing advanced C++ and blueprints. But am I alone thinking that something is SERIOUSLY flawed in the integration with UE and Visual Studio?
I have have never in my career spent so much time in “recovery” because of manual interference in a specific file. Everything has to be UE-style when working with C+±files apparantely. Why is this? It is so time-consuming
AI has its explanations, but I would like to hear comments from you, real people working in this environment daily. Am I doing something fundamentally wrong hitting these annoyances?
I do understand the concept of how to work from UE with C++, but sometimes it truly conflicts with how I would normally quick-fix something
Any tips and hints to make the C+±experience less painful in UE would be much appreciated.
I will give a quick question as example: I have a class which I just need to change type on a variable. In VS I do this, and then UE wont even open my project, because I worked this out outside of its “realms”. The solution given by AI is to delete folders x, y, z, rebuild and hope for the best. That is not a solid reliable way of handling source. So why hasn’t Epic managed to keep up to modern ways of handling sourcecode?
Apart from this really annoying thing, just loving UE 5.8 of course
Everything has to be UE-style when working with C+±files apparantely. Why is this? It is so time-consuming
Given amout of custom tooling ue have - you just have to accept it’s not a c++, it’s a c++/ue, a flavour of language that has it’s own pros and cons compared to regular c++.
And of course you may use a nearly-regular c++ in any part that isn’t directly exposed to blueprints.
I have a class which I just need to change type on a variable. In VS I do this, and then UE wont even open my project, because I worked this out outside of its “realms”. The solution given by AI is to delete folders x, y, z, rebuild and hope for the best.
Can’t say what gone wrong here, but even when usually changing type\names of bp-exposed variables may lead to troubles, it’s never the level of “editor won’t even open”. As long as you rebuild your project - all should be fine.
I’d mention “beware of hot-reload”, but it’s just a matter of understanding - as long as you aware of limitations it works perfectly.
As for “delete binaries//intermediate//saved folders” - that’s quite a standard way to “surely remove all build artifacts and have a clean rebuild”. Nowadays it’s rarely needed, but still worth keeping in mind
Hi, I grew up with Commodore too - still miss Paula, Agnes and Denise.
Most nuances are to do with Blueprint - UObject based things are restricted to a limited set of supported variable types when marking as UFUNCTION or UPROPERTY.
For other types of classes and structs you can use pretty much what you want.
Rider is much more friendly for UE than VS - but does use a lot of memory - like 64GB is pushed when you’ve got the engine and your project all indexed. Much better than Cygnus Editor anyway.
Live Coding sucks - just avoid it - most of the intermediate object cleanups are needed from that.
UE predates templates and STL. So they had to invent their own way of doing everything before STL was even a thing. They added a lot of stuff that supports STL since. You can even use range iterators now. As others have said, don’t change anything in the header file if you’re doing live coding. You can change implementation of a function and that’s about it. Otherwise, I close the editor first and do my changes.
One thing that messed me up when I started was that UE uses constructors in a much different way than normal C++.
As for deleting intermediate, binaries and DerivedDataCache, AI will tell you to delete those because it fixes a huge amount of problems that you can get with UE. But this is usually related to build configuration.
Ultimately the answer boils down to reflection. Unreal, as an Engine, wants lots of meta data about types and properties and methods that is currently unavailable in C++. But it also wants to use C++. Every other Engine feature that gets mentioned, ultimately boils down to only being possible because of reflection support. GC, reflection. Blueprints, reflection. Serialization (file or net), reflection.
This does result in a bit of an … accent on the regular C++ and sometimes limitation on what you can do. But only ever within the scope of reflection. If you don’t care if it’s reflected, you can ignore it. Want to do pointers to structures, fine as long as you aren’t serializing or exposing to blueprint. Methods on structures, fine as long as you don’t need them called by blueprint. And even then there can be reasonable workarounds for a lot of these limitations that result in some minor boilerplate.
You’re not 100% wrong. Visual Studio’s always had various issues trying to be an IDE for Unreal projects. And a lot of that comes down to no understanding the “accent” I mentioned and all the macros. It’s gotten better, but currently Rider is the better IDE for Unreal development. You still have to install VS (or at least the MSVC tools) to build. But you don’t have to do day-to-day work in VS if you don’t want to.
It’s unclear what you mean by “won’t even open” because I’ve done this plenty and it can work just fine. Sometimes it can be a problem for pre-existing assets but it shouldn’t cause issues just opening the project. How are you editing files and launching your project? If you’re doing C++, you should be making edits, compiling and running from within your IDE. You’d be surprised the number of people that make edits and then try to launch their project from the launcher.
They have, sort of. It’s just that modern for C++ is not the same as modern for other languages. I didn’t really notice any significant difference between how Unreal works/builds with C++ than the custom engine I was worked with before. Other than perhaps the layer of UnrealBuildTool for managing the compilation instead of letting MSVC handle that. LiveCoding support has improved things a little bit as there are some C++ changes you can make and compile while the Editor is running.
It only predates the STL. Templates were introduced in C++3.0 in 1991. Tim didn’t start Unreal until '95 (though who knows what the state of template support was by that point). But even after the STL, plenty of places managed their own types for different reasons. One of the more famous being EASTL.
But even with that, the current version of the engine doesn’t exactly forbid use of the STL. In fact many of Unreal constructs (TAtomic’s the only one off the top of my head though) that have/are being deprecated in favor of STL versions which are better supported/maintained. And there’s never really been anything to stop you from using the STL in contexts where you weren’t interacting with reflection in some capacity.
This is quite a hard-to-understand example, because merely changing the type on a variable would never (probably – maybe there’s some edge case) cause the editor to fail to launch. If you really want an explanation for why this happened, we’d need to hear at least 10x as much detail as you’ve given.
(And deleting Intermediate isn’t really a solution. Maybe it can help sometimes, but if there’s an actual build issue, it’ll just pop right up again.)
I would say this is definitely an exaggeration. It’s normal C++. You can do everything C++ does. If you really, really want to, you can force a UObject to inherit from two different UObject classes (not interfaces). (Don’t do this though. It won’t work like you expect and it’ll probably cause weird issues.)
Certainly UnrealHeaderTool enforces some constraints on reflected elements that would be fine in vanilla C++, but as long as it’s not reflected, UHT ignores it and you can do whatever you want within the bounds of C++. Want to use the C++ standard library? You can. (You might not be able to build for consoles if you do though. I have no evidence for this, but it’s a possibility.)
There really isn’t a problem with this, though? There would be a problem if they don’t build the edits first (maybe that’s the mistake you’re referring to here), but as long as you’ve properly built and there were no compile or link errors, and as long as it was Development Editor and not DebugGame Editor, it doesn’t matter what method you choose to launch your project.
Launching from the IDE does provide some benefits (you have a debugger attached and can immediately see the location when something goes wrong; possibly check() calls don’t terminate, or maybe that’s in a DebugGame build), but I would not call it strictly necessary, and there are also disadvantages (like having a debugger attached – it could slow the game down in some situations).
Yeah, those are a couple of the bits that can trip people up. There’s settings some people rely on that are supposed to trigger compiles on launches, but /shrug. If you have an IDE to edit your source, there’s no reason to run from anywhere else (at least for programmers, it’s more complicated for content creators).
If you really need to always trigger a compile on launch, it’s probably sufficient to just set something up to delete the Binaries folder whenever you close the editor.
