I think this i misleading and can stifle imagination: “For game development in Unreal Engine 5.0 and beyond, the Levels window has been made obsolete by World Partition”. As far as I can understand world partition is not the correct tool to create noneuclidian levels where e.g. things are bigger on the inside, for those the level tool is needed?
The videos for the skeleton editing documentation has a single video that replaced all previous videos, it seems like after the 5.4 version of the documentation the videos somehow got replaced.
Was following through the Behavior Tree Quick Start Guide tutorial and noticed the full image for adding tags to the player blueprint was broken. Relatively easy to figure out but a small fix could help there.
The ML Deformer documentation doesn’t seem to have anything on what the Deformer Graph nodes do or what the ML Deformer Detail Pose Model is for. The whole ML documentation seem like it needs updating with the 5.6 updates as well as the MLDeformer Sample project which no longer works and looks like the picture in 5.6.
I want to incorporate a couple of UE based programs into a larger project using CMake. Said project has it’s own launcher and lobby and so on. I need command line capability so that I can build the whole shebang from a Git repository with a single make command or in a CI system.
The Linux quickstart guide at Linux Development Quickstart for Unreal Engine | Unreal Engine 5.6 Documentation | Epic Developer Community is broken. I have found a few other guides with other commands, but they seem to be from even older versions of UE. This is the official documentation and should be correct.
In section 4," Set Up Your Development Environment (C++)", step 2 states Locate your Unreal Engine install directory and open Build/BatchFiles/Linux, then run SetupToolchain.sh.
The “Build” directory does not exist. The SetupToolchain.sh script does not exist. I unzipped Linux_Unreal_Engine_5.6.0.zip and in the directory I unzipped it to, I ran the command find . -iname SetupToolchain.sh. There were no results.
In section 5b, " Build a Project Through the Command Line" has an example command [UE Root Directory]/RunUAT BuildCookRun -Build -Cook -Stage -Package -Run -Project=[ProjectName].
There is no RunUAT command. I unzipped Linux_Unreal_Engine_5.6.0.zip and in the directory I unzipped it to, I ran the command find . -iname RunUAT. There were no results.
On a related note, the page https://dev.epicgames.com/documentation/en-us/unreal-engine/creating-a-new-project-in-unreal-engine which is linked from the Linux quickstart guide, has this text about selecting the “Implementation” when creating a new project:
C++, if you want to build your project by programming with C++ in Visual Studio.
The other option is “Blueprint”. Which option do I pick if I want to do my coding in C++, NOT using Visual Studio because I am working on Linux. I don’t even want to use Visual Studio Code. Tying developers into specific IDEs is really really annoying.
Dear Unreal Engine Documentation Team. Please start using AI to improve the official Unreal Engine Documentation, which is often incomplete and out of date. Developers could greatly benefit from it and become more efficient. AI coding assistants would also greatly benefit from increased context. But perhaps most importantly, the entry barrier for new, aspiring developers is greatly reduced.
As example, I have created a schema for each HTTP Endpoint of the Unreal Engine Remote API Plugin. All it took was pointing Claude Code to the Remote API Plugin folder of my Unreal Engine installation with a simple request to compile each HTTP Endpoint JSON schema for me. It completed the task in one prompt, 5 API requests in total. The result: [Waiting for approval of Community Tutorial].
I fail to come up with a reason why the Unreal Engine Documentation Team wouldn’t want to do this at scale.
Love the initiative—community-driven discussions around docs and examples often surface the most practical tips you won’t always find in the official guides. 
The C++ API Reference page for Unreal 5.6, Unreal Engine C++ API Reference | Unreal Engine 5.6 Documentation | Epic Developer Community , is objectively worse than the C++ API Reference page for its Unreal 5.5 predecessor, Unreal Engine C++ API Reference | Unreal Engine 5.5 Documentation | Epic Developer Community . In fact, the only thing the 5.6 page has that the 5.5 page doesn’t is a plugin list, which I can already get from Edit→Plugins in the Unreal Editor. Otherwise, not only am I getting everything else the 5.6 page already has in the 5.5 page, I also get a Class Hierarchy page (which doesn’t seem to work), a Getting Started page, and lists for classes, constants, enums and functions. I don’t know whether the 5.6 page’s lack of basically-necessary content is part of some deliberate attempt to get more people using Epic’s Unreal Developer Assistant, the page’s authors think they’re more clever than they actually are or if it was just an honest mistake, but there was absolutely no reason to change the old page into something that makes understanding an already-massive engine more difficult, not less. Save for possibly adding a plugin list, the Documentation Team should just regenerate the entire Unreal 5.6 C++ API Reference page/sub-pages and all such pages for each Unreal version thereafter into what the 5.5 documentation offered. Because, what’s the point of going back to the 5.5 documentation for a class page that may already be grossly outdated?
I´m a 3D generalist, coming from 3ds max and Vray and about 3 years ago I started transitioning to Unreal Engine.
And although a really fun and rewarding ride overall, it was a bumpy one at times as well.
And at least 50% of the time, my biggest struggles were with UNDOING default settings meant to optimize performance.
Now, seeing how Unreal has started getting some bad feedback recently due to poorly optimized games from poorly educated devs, I absolutely understand the tendency to “hide” a ton of these performance optimizations under the hood.
And Movie Render Queue also does a lot of the heavy lifting in a lot of areas, especially when settings are exposed via Cvars.
But not all these settings are, some also must be set in project settings, editor setting, on a per asset base (sometimes during import) and in the detail panels in the levels etc.
Tthere are still tons of things I keep discovering by chance and by meticulous research, that are hindering my workflow.
I´ve spent months trying to figure out how to get the “distant to nearest surface” node to work properly, because its effect kept getting jaggy or disappeared completely with smaller meshes…
…and by the way, still haven´t really figured out this one to this day…
Often it starts in the viewport, because producing 95% ONLY cinematic content, I rarely even enter pie…unless its to test if some weird glitch/artefact/objects not appearing etc. might go away then…and I can´t constantly render either, to see if the problem actually ends up in the rendered output as well.
So, I´d very much appreciate some section dealing in WAY more detail with ALL these settings hidden under the hood, that I might wanna at least temporarily disable if I am ONLY working on cinematics for linear content production.
I remember seeing some virtual production guides, but a ton of things are NOT covered in these.
Ideally, at SOME point, I´d just like to have some centralized place where I could enable/disable all these performance hacks that I might not need for cinematic content too, so I wouldn´t even have to refer to the manual every time I encounter a problem, but that would still be a great starting point!
Thanks for opening this thread it is a great to have a relaxed space to talk about the docs and learning resources. UE4 has so much power, but sometimes the documentation can feel a bit scattered, especially for beginners jumping between Blueprints, C++, and engine tools. I always appreciate seeing tutorials, examples, and tips that fill in the gaps the official docs do not cover clearly. Looking forward to chatting with everyone, sharing experiences, and hopefully learning a few new tricks along the way.