How can we improve UE4 Documentation?

Hello all!
To help organize our threads and open up the General discussion board a bit, here is where you can post your direct suggestion feedback.
So I ask you all, How can we improve UE4 Documentation? Send us your ideas, requests and suggestions.

Thank you all for the amazing support and help!

For one thing, there’s just way too many consolidation threads in the documentation feedback forum that may have overlapping contents and discussions about what to improve upon. An example would be, I can see that this can also be put in this thread, as well as taking contents from the Google Form and place it here. Or vice versa.

Unless you plan on copy/pasting or merging posts from other threads/other forms…

Also, do complaints count as “improving the docs”?

Appreciate the feedback!
there is always going to be some potential overlap. As stated before this is a new process and a learning one too. We welcome ideas on all fronts for improvement but unfortunately not everybody’s way of doing things or how they would like to see things done will be able to be implemented. There will be general threads plus specific ones that may lead to survey’s and I am just trying to keep things organized for everyone. As for complaints, as long as you are voicing your concern in a calm/collected manor I would want you to feel comfortable enough to post them here.

Actor LifeCycle Needs Improvement

https://docs.unrealengine.com/latest...cle/index.html

We really need to see what the lifcycle of ActorComponents is as well, with how and when Register/Unregister and the like correlate to actor lifetimes.

There are also other cases for example Alt+Drag duplicate/copy and paste, these things run a whole slew of undocumented serialize functions (including some bizzare text serializer that doesn’t seem like it should be there becasue you have the Archive system already).

Under what conditions am I supposed to call register myself? Why should I ever need to call AddInstanceComponent myself? I find that there are far too many stages and special case flows. Just make me have to call AddComponent all the time, there is so much guessing.

I posted something like this in the blueprint section: the player controller article just has a few paragraphs talking about what the player controller is on a high level but not how to implement it on a lower level. Seeing some examples of implementing the movement and some any other uses would be nice.

Hi,

It could be great to have a documentation on the cooking process, the chunk management etc…
There is so little information but it is really important as it is what you want to do to share your game.

More, there is also a “.Automation.cs” file that can be used to tweak, automate the builds etc… it could be great to have a better view on this.

Thanks,

When a reader clicks on the labels, “Unreal Engine 4.5” near the top of the documentation article, it should link to a webpage listing all Unreal Engine 4.5 articles.

Same goes for Unreal Engine 4.3 and future articles, such as 4.7.

Wouldn’t that be awesome? :slight_smile: We’re working on improvements to the platform that would allow for things like this. Unfortunately, it’s much more difficult with our current system (system is somewhat of a misnomer here as it is really just static HTML) than you would imagine it to be. I had an idea for a way to hack it into the current system last night that I will look at implementing that.

On Friday, I added support for skill level (Beginner, Intermediate, etc.) which should begin appearing soon. More general tags is something I would like to add too. Having those all be clickable would nice.

if the documentation is all static webpages then it might be time to convert the documentation into a wiki. With a wiki, comments can be turned on or off per page. Comments can be hidden or visible. Tags can be added and removed. A complete history of revisions can be kept. A consistent look and feel without inserting CSS tags over and over again – and so on. It’s allot of work at first, but the benefits make themselves immediately appearantl.

I oversimplified the situation. It isn’t like we are just editing static HTML pages to create the documentation. We have a proprietary source format we use and a tool that converts it to HTML. It has quite a bit of specialized functionality, but in the end it isn’t dynamically generated from info stored in a database so certain things are more difficult or impossible to implement.

With that said, we are currently looking into platforms we could use to host all of our learning resources (written, videos, etc.) in a single location. Some of the goals of this are to have better tagging, comments, and lots of other cool stuff. Switching platforms isn’t something that happens overnight, though. We have to make sure whatever platform we choose fits all our needs and requirements which takes time. Stay tuned for more updates on this.

Suggestions & Questions [So Funny]

Hi, I have been following up on tutorials for UE4, and I wanted to know (before I get my new computer) if this is a good thing to get, and the answer is yes. I do have a question about it, though.

  • Can you create animations WITHIN UE4, or does it have to be from an external source?

And I do have a few suggestions!

  • A way to create your own custom destructible meshes (i.e. “drawing” paths on which the item can break)
  • An easy way to connect sockets withing Blueprint ('Cause I suck at C++)
  • And finally… a cloth or liquid editing system!

Hi holan. Those things don’t really belong in this forum. They are better placed under “feedback for epic” forum. It may also be advisable to move the question to another forum thread that is more appropriate somehwere else in the .

Cheers,

Thank you for informing me, I am pretty new to this, by the way.

What i think would be a great tool for you guys to have in place is on documentation pages have a Vote for update button somewhere on the pages so you can see where ppl are needing the most up to date info. *because in the real world not everything can be kept up to date :stuck_out_tongue:

this would allow more used/ hi priority pages to be kept up to date more efficiently.
also it seams a lot of ppl are using older versions of the software so solid updating of a page might not be in there best interest so a page history would be nice as well so if thee were updates to a page for version 4.1 and it was updated again around 4.7 they can go to a version at or before there own and see what may be more pertinent to them

https://docs.unrealengine.com/latest/INT/Engine/Basics/AssetsAndPackages/Saving/index.html

The content on this page appears to relate specifically to source control.
There are allot of pages or sections in pages as aprt of the documentation that relate to source control, however they are all split up according to where they occur in the editor.

Perhaps it could be better to put all this content into one page or one section of the documentation under it’s own heading in the table of contents called “Source Control” or something similar. Source control can be a pretty big deal for teams, and havng all the info in one place will make it easier to get a project started, and then they can stop worrying about packages and worry more about getting the work done.

Once Source Control topics are consolidated, then links can be made from where those other relevant pages to point to this new content.

Cheers, .

Have you checked this documentation out? https://docs.unrealengine.com/latest/INT/Engine/Basics/SourceControl/index.html

If so, in your opinion, how can we make this more complete in covering the topic of Source Control?

As far as learning material goes, personally what I would like to see is some reverse engineering of existing demos. Sometimes is better to learn from seeing something broken down into parts.

I think the Couch Knights demo would make a good example, because you’ve got several overlapping systems working together. You’ve got an interesting overlapping system in which your character is controlling another character while you watch, you’ve got a melee system with combos and blocking, IK systems, Oculus/HMD support(though it doesn’t seem to fully function without an Oculus IIRC) and on top of that you have it setup for multiplayer replication.

What I’m curious about is the thought process that went into implementation of each feature and in what order things were implemented. The melee characters first or the Oculus characters first? Was replication/multiplayer an after thought or pre-planned? It would be nice to see what the game would look like without the Oculus characters, or vice versa and then showing how they’re tied together.

Then of course there’s the Kite demo, it would be nice to see some focus on the AI/Cells/Crowd systems and how they were setup for the large open world. You could think of this as in depth usage case examples rather just reading more generalized documentation.

First of all, please link the documentation directly from the corresponding windows in the editor and the tooltips of the blueprint nodes. This alone would save ages of searching.

Then rework the scalability reference. It’s still not clear in what exact INI all those settings have to go to affect editor AND the packaged version of the game.

Another thing would be better documentation about profiling.

Not sure if this thread is still alive; it’s pretty old…

But I find the documentation to be non-existent almost every time I need it. Someone clearly ran an automatic documentation generator and then just stopped and said “good enough.”

The result is a thousand pages like this (I just clicked through the help randomly, nothing specific regarding these examples):

They tell the programmer absolutely nothing. No remarks, no examples, no explanation of the function parameters, no clarification on the difference between “InitBoxExtent” and “SetBoxExtent,” no “see also,” no hint as to which versions this applies to, and so on.

A very small fraction of the documented functions and variables contain anything useful. Personally, I’ve stopped using the documentation and just started going with trial and error. When that fails, I go to the Answerhub, which has actually become the “real” documentation of the engine.

Thank you for the feedback. Our Docs Team is aware of this issue and there are plans to improve this at some point in the future, however, because of the scale of this project, in addition to the task of keeping current documentation up to date, it is difficult to provide even a rough estimate of when this will be addressed. Until then, I’m glad to hear you are getting the help you need from the AnswerHub. The are also a great place to get information as we have an active and enthusiastic community.