General Documentation Discussion

Hello all!
This thread is an open opportunity to casually discuss anything and everything documentation, tutorials, and content examples. Feel free to post questions/comments/concerns; again anything you feel like casually discussing about UE4 documentation.

Thank you all so much for your support and help as this amazing Unreal community continues to grow!

  • Brandon

I know this is meant for the general documentation as a whole but I didn’t see a section for Root Motion, so I’ll post it in here:

Has anyone checked out the Root Motion documentation lately? The AnimMontage part is outdated (Root Motion is on normal animations but not available to turn on / off in the montage .etc)

This leads me on to the point, I think the documentation is great and helpful but just like my books gets outdated SUPER-quickly. Which is an obvious problem, but what if the community used the version changelists to create / update pages for the documentation and submit them in a pull-request like fashion?

Because the documentation is so huge, I believe it’s something that a community effort would help keep it updated all the time.


Hey Kitatus!
First, thanks so much for the dedication and effort you have shown to help make the Unreal community that much better with your help in this feedback process. Also, thank you for bringing the Root Motion documentation to light. It does seem we have certain tasks in place to get them updated; but as you know and have even pointed out, as the engine grows it is hard to keep up with documentation with how fast things can change. And that is indeed where the community can help. Right now identifying what is out-of-date and what is important documentation wise to users is a big help. There has been loads of talk of other ways the community can help and keep an eye out for future things to hit. But for now continue to help as much as you can with this process(it really is a big help) but also help other community members with questions they may have and guide them in their learning experiences. Again, keep an eye out for future ways the community will be able to help with documentation.

  • Brandon

Can you add [this]( Cinematics and Gameplay) to UE4 documentation as well please? Looks like some users were confused about the usage of Dumpmovie command so it would help if you also point out that the project needs to be packaged in order to use it.

Hey Jacky!!
thanks for the heads up and info. I will look into seeing what I can do to make a request.

Duh, I didn’t even know this sub-forum existed until I read that post about it going public. LOL!

Anyway, here’s an idea for all and any API documentation pages:

link the Header under References to GitHub source tree !

Ideally the API pages should be dynamic and offer you a drop-down to switch the Engine version. Then based on that it could link to a specific source file in GitHub for that branch.

Thanks Amigo!
I will turn this into a request

Requests for documentation:

  1. Split the documentation into two groups, Blueprint API, and C++ API.
  2. For C++ API, have all articles provide Usage and Example Code so that everyone can easily learn how to use the APIs to code quickly. Blueprint API does this by showing the user what the blueprint node looks like with a picture.
  3. Since there is an article for Unity developers switching to Unreal Engine 4, why not have an article that explains concepts that all UE4 specific macros use to a C++ developer that had done standard coding? (If it’s already been done, I couldn’t find it. What title is that article called?)
  4. Could the documentation copy the format that MSDN uses for their Win32 API documentation, such as listing out what the parameters of a function means, what return values a function can return (NULL, nullptr, 0, -1, Numbers with a meaning, Enums, etc.), etc.? For MSDN documentation, even if the function states what obvious action the function does, they still provide a brief description telling the user what the function does. There are some UE4 documentation articles that gives only the function names, and no descriptions, such as _getUObject(), StaticChecks(), constructors, etc.

Could really do with some tutorials or Documentation on how to Properly use Timelines in C++. I can’t find a single example anywhere on how to actually implement one.

This subthread about the documentation is a great idea. The UE4 answer hub is like hit with an avalanche in 2 minute intervls with basic question, which kind of reflects that the documentation in its current form is not ideal.

I am using Matlab on occasion, and they have a very nice documentation style.
If you have a license, there is even more indepth on top of this, like Rotations with axis&Angle, Euler, Quaternions and how the all play together and so on.
In UE4, no one even know the rotation order, except for the one developer who coded it.

Essentially, they push their developers to write more than one sentence about a feature.

Like UE4:

99% of the user base will not use it, because a) they won’t know that it exists and b) if, then they don’t know what exactly it does (no example)
This is especially true for the now free UE4, which will attract lots of kids and younger people, who have no idea yet of what a dot product is.

Here we say: why even implement a feature first place, if it is not fully documented. Those who find out in code how it works, can do it themselves, and all others won’t use it.

For a while now I’ve heard mentions from various Epic devs that ‘C++ documentation is coming soon’. It’s been very highly requested on the roadmap page for a long time. I realise bits and pieces of new documentation get added continuously, but the impression I’d got was that a complete overhaul was going on behind the scenes and we would be getting something much more comprehensive. I was assuming also that this would include a C++ API reference with details beyond simply auto-generated class and method names and signatures.

Can someone clarify what the situation is in this respect?

Hey kamrann!

We put out some new pages and improvements with the 4.7 release including a new introduction to UE4 programming, a comprehensive Networking section, sample code for a bunch of the most commonly used functions in the API reference, a series of tutorials, and various other new pages. This is an ongoing effort and we will make pages and functionality available as they are complete. It isn’t likely to be a situation where one day you show up and everything is new.

Sure, fair enough. Is there going to be a specific effort though to flesh out the API reference with some more info regarding intended method usage, parameter/return value descriptions, etc?

Of, course sections dedicated to particular areas with examples are always welcome, but I really feel like having some basic info at a lower level to fall back on is vital. Often these higher level sections of documentation will provide descriptions and example code only for the most common usage pattern, and anyone needing to do something even just a little different will be stuck. Of course, the source code is there in this situation, but it’s a slow process to follow it through to find out what a particular method does and how it should and shouldn’t be used.

I think there’s a fair bit of bad practice and misinformation out there currently, which is inevitable when people are forced to dig into uncommented code to try to ‘find what works’. Often, what works will be a misuse of the engine code, which might not work in the future or in a different context.

Hey Chariots,
I will add this info to a current request to get NavMesh documentation updated.

Are we focusing on blueprint documentation, or C++ documentation?

Neither. All of it. :slight_smile:

Could there be reference links between blueprints and its C++ doppleganger for each of both the blueprints articles and the C++ articles? If users were able to transcribe blueprints to C++ and vice versa, our documentation will be completely programmer-designer friendly.

I love this idea. I have both a programmer and designer background. I can write boilerplate without much difficulty, but when I’m working with hundreds of objects I can no longer hold my head above water. This doesn’t mean however that I can’t read API docs. If I could click a link to see the class, the input type(s), output type(s), and exception list in written form, this would let me decide better if I want to use that function in my blueprints.

Cheers, Rigel

First of all, I would like to commend you all for the great work you have all done with the docs. I love the Docs more now than ever. So first of all, Thanks!

Suggested these in the past and even though it seemed everyone agreed to the need and even started to implement them, they seem to have lost focus at times now.

    • Date & Version Stamp
      • Although this was an issue of concern by the community and partially implemented in the past, it seems to have fallen once again to the wayside.
        Which with all the reworking of the Docs one can understand it losing focus. Now though it should be reconsidered and fully implemented as a required part of the Docs.
      • This should be a required field on every page of the Documentation before it can be uploaded to or put in the Documentation.
        (For sake of clarity: This has always been a problem with all the updates & revisions that come out. A user can’t tell whether or not the Doc should work with the version they are running or not.)
        (With all the new users this has become an even bigger problem now, more so than in the past & will become an even bigger problem in the future as new content is released.)
        (This will help everyone and especially those in charge of keeping the Documentation updated.)(This could also be applied for footnotes for when errors for certain versions are found and updated.)

****** Edit: Updating #2 Suggestion/Feedback *********
-----although I had ran across this in the recent Docs, I cannot find the pictures I had found the issue with & have found that the ones I did find may have just been missing the link that opens the illustrations in a new window. A simple workaround is just to right click & use ‘Open in New Window’ which should work in most cases------

    • Some of the Illustrations & Pictures are too small and can’t be seen.
      • In the past most Tutorials & Documentation were updated to do this but recently after the updated Docs came out, I have seen this resurfacing and becoming a problem again.
        (ie: We don’t all run 52" Monitors &/or dual + monitors. That should be enough explanation but if a user can’t see the example’s illustrations the example is almost useless.)

*** Edit: would like to add another suggestion for this Topic:
- Rename this thread to reflect it’s purpose more clearly
- ie: Possibilities include:
General Documentation Feedback (or) Documentation Feedback - Post Here! (or) Post Documentation Feedback Here!

*** Again thanks for the wonderful Documentation & all the efforts put forth by Epic & it’s employees. TYVM :wink: ***

Example Code Please

as requested from this thread

to add to that,
even the basics have no code at all, for example unreal’s special specifiers, ie UClass, UFunction ect.
here is the class specifiers page
it presents a big list of available options (with no example)
click on an option, a common one might be Blueprintable, and there is a short description without an example.
it would be really good if they all looked more like this page

another example that would really help me at the moment is any kind of documentation on vehicles c++. not just a list of variables but a description of how the classes involved interact and what they do.

i know it takes time to do