I was getting started converting some of my blueprints to C++. Time and time again I find myself trying to look something up, but the docs are no more useful than my intellisense. Just as a small example, EInputEvent | Unreal Engine Documentation shows the EInputEvents I can use with BindAction, but it doesn’t explain anything at all. Is there documentation somewhere that actually explains stuff? Like what does IE_Axis and IE_MAX do? For functions that exist in blueprints, I can just look at the blueprints API Set Input Mode UI Only | Unreal Engine Documentation. However I don’t think I can get through it with just the blueprint documentation. Unreal is a very popular game engine so I suspect I might be missing where the real documentation is for C++.
There is a community wiki which has stuff on C++, https://ue4community.wiki/.
That has a lot of good stuff on it, thanks!
The API reference is an early work in progress, and some information may be missing or out of date. It serves mainly as a low level index of Engine classes and functions.
You are correct, it makes me sad though. Seems like people have been wanting better documentation for forever now "Lack of docs" whining has been a hot topic for years. Is there a viable solution? I think so. . Epic gave a mega grant to the community wiki, hopefully they didn’t think that was a good replacement for better documentation. Is there a schedule, milestone or roadmap for the documentation? I can’t seem to find it
How is this relevant to the question of “where is the real documentation”?
It is called source code, you just have to read
Please try not to be condescending. People have the right to ask questions.
@2865927525 your answer is the best, I think, but this is a very recurrent question since always. A quick search over the forum/answer-hub will lead to them.
In my humble opinion, there is no need of documentation when you have source code from a software, not only UE and yes I know is hard and it is not a 1:1 example, like everybody wants, but it is a powerful tool for learning. A more relevant question should be, how to read the source code? don’t you think?
I agree that you can get a lot of data from reading the source code.
All I was saying is that even though the question’s been asked before and you believe the answer is obvious, people still don’t deserve to be condescended to. We have the right to ask.
I couldn’t disagree more. A public API should be well documented. Having to “read the source code” to use the API is counterproductive; it is not only much more time consuming, but it encourages people to write to the implementation instead of the interface, which makes the implementation difficult to change without breaking a lot of people’s code. If you want to understand the engine internals then by all means read the source code, especially if you want to contribute.
The Unreal Engine API Reference is a good start; it just needs to be more complete. It is presumably auto-generated from the code, so classes that are well commented have good descriptions, whereas others have no description at all. It is frustrating to see documentation for a class like
AAbilitySystemDebugHUD with no description of what it is even for.
I agree there is no better documentation for UE4 than read the source code directly.
Which doesn’t mean that this is a good thing. Read a proper and well writen documentation is uncomparable faster than opening and searching stuff inside .h and .cpp files.
Unfortunately, I personally don’t have any hope that it will ever change for UE4 development.
Epic have asked this question before:
- How would you go about documenting a piece of software that contains millions of lines of code where tens of thousands of lines change every day?!
You can criticize, but make sure you also provide suggestions…
Do you understand now why the engine is completely free for developers making less than a million dollars?
If you are making bank, you can afford dedicated 1:1 developer support. Epic cannot teach the entirety of this engine to everyone.
It’s not humanly viable.
Wait a minute…
That point seems logically self-contradictory. You make two claims:
- If you’re making bank, you can write documentation.
- It’s not humanly viable for Epic to write documentation.
So, therefore, are you saying Epic is not making bank? But, if Epic is not making bank, why would they… make it completely free for developers making less than a million dollars?
Regarding the number of lines of code, it’s functions and variables that matter, not lines of code. I could write a simple CMD line calculator that has a million lines of code. I just need to hit enter a lot.
Regarding your inane requirement that people have to make a suggestion when they point out a fault… here is one…
I think Epic could help the economy a bit and add a few thousand jobs by creating a documentation division whose sole purpose is to continually write and update docs.
You did not understand at all what I said
Just because I don’t automatically agree with you doesn’t mean I don’t understand you.
Everyone else is just as smart as you and you’re not better than everyone else.
So, if you feel misinterpreted, you have to do the job everyone has to do when communicating with the rest of the human species and…
Write it better.
How would you go about documenting a piece of software that contains millions of lines of code where tens of thousands of lines change every day?!
That is a straw man argument. You don’t have to document millions of lines, just the API. The API does not consist of millions class/functions, and it doesn’t change every day.
You can criticize, but make sure you also provide suggestions…
I’m not ungrateful for the amazing engine Epic has made available to us, but that doesn’t mean things couldn’t be better. As for suggestions…
- Don’t accept any pull requests or merge any code that isn’t well documented (especially public classes/functions that are part of the API).
- Dedicate a portion of your time to paying down technical debt (adding tests, adding or updating documentation)
Documentation does not have to be a separate effort; it should be part of writing the code.
I completely agree with issues you point and suggestions.
I have also requested better documentation for years on end, but the only salvation I have found was to pay for Visual Assist X and dive into engine code for months and months…
I was just pointing why documentation will never be complete and why you shouldn’t wait for a complete documentation before start developing.
If I did wait for them to finish documentation, I would be still waiting today, since 2014.
Luckily you might wait for less years than I have lol
By the way.
The API actually do change everyday.
This is fact, just go over Unreal source code on GitHub and see for yourself.
hey @BrUnO_XaVIeR I totally agree with you brother, same story, I have been requesting info about RHI and the rendering system in general for years, but at some point I gave up, I bought Visual Assist as well and now reading the source code feels like reading a good book, but it takes time of course.
For those who haven’t read a single .h you will soon realize in the moment you do than the actual online documentation is auto-generated from there.
Btw regarding to visual assist it has been said multiple types in the streaming that not a single dev at Epic works without it.
It answers why the documentation is incomplete. It’s a literal disclaimer that basically says “this documentation is incomplete.” I get the question was “where?”, but that assumes Epic maintains a second “real” documentation that’s hidden somewhere, which is very unlikely since that would be more work than just maintaining one documentation.
Agree with this. If something doesn’t have documentation, it doesn’t just make it unusable. When I started digging into source code, I used the documentation for a lot of things. When it was missing something, I literally just used… the source code. The source will likely have comments, so there’s your documentation right there.
The engine’s source code is supplied for convenience, not necessity; it’s meant to be modified & extended, but not necessarily dissected. If you don’t know what something does, just experiment with it. The worst you can do is crash the program.
I made it a habit to comment every block of code I write as I write it, as if it were part of the code itself. Now, it’s hard for me not to comment my code; it looks “incomplete” to me if I don’t. I know comments and documentation are not necessarily the same, but an easy way to make documentation is just to use the comments.
You misunderstood him: