[USER=“4894”] Hobson[/USER]
Sorry for late reply :s
I wrote “Change viewport Android” because I didn’t know it was called a “Preview”. It’s just me but I think C++ coding (scripting) is not enough highlighted and as a coder (more a Engine’s C++ User) It’s too bad that BP take so much place.
I know it’s not the subject but do you have the new Wiki’s release date ?
Bests,
Alexandre
So here is my burn down list that I would personally like to see:
-Epic having a procedure in place where when they answer a question (such as on answerhub), they follow up by checking the related documentation and adding that answer into the documentation so that we stop having so many repeated questions. If you are seeing questions, it is often because either it is darn difficult to FIND the answer, or the answer is not communicated clearly. So, start using your questions in Answerhub as the guide for updating your documentation.
-A document/weblist listing all default blueprint nodes, grouped as they are grouped by default in the right-click context menus, detailing the functionality/use of the node, preferably with links to default input/output nodes.
-Consolidation, perhaps curated by topic, of previously answered questions to reduce the overwhelming number of Q&A threads. (Essentially step one of the first suggestion). This would make it easier for us to find the answers we need without having to ask repeat questions, and give those answering a single target source to point questioners too.
I feel very strongly that a Forum post is the WRONG way to solicit feedback about documentation.
There should be a button on EVERY page of documentation that allows users to submit feedback, which will be ticketed with the link to that page of the Documentation. This can be done off-the-shelf with Zendesk, but I’m sure Epic Games can figure it out somehow.
Users should be able to click the button and send feedback about that page of documentation to Epic, point out what’s erroneous about it, how it can be made more clear, point out what the user would have liked from that page, etc. That would make it SO much easier for users. When I couldn’t find a similar button like that, my next step was to go search the , and lo and behold, this is where you want users to submit their feedback. I can imagine that extra, non-intuitive step of added friction will have Epic missing out on a mountain of feedback from users who are effectively doing the job for you(pointing out what’s out-of-date/wrong and how to fix it).
@VR_Nima Thank you for your feedback! We are investigating solutions along the lines you describe above.
Jim Bradbury | Learning Resources | Epic Games
Hello! One thing that would be useful for the documentation is updating it as Unreal’s features change. Material properties for example is still stuck on version 4.9. There are several differences between version 4.22’s properties and version 4.9’s. I’m sure it’s not the only section that needs updating.
Hi! my name is John and I’m working with Unreal for a long time, the sound into Unreal is my job but when I need some information about it in my opinion is very limited and with the old version (4.12, 4.13) I’d like to have more information/tutorials about new audio system, new ambisonic implementation, etc, with the newest version of Unreal.
The sound is one of those forgotten in production.
Anyway the changes you’re making in the documentation is amazing and look nicely
Thanks in advance
Can you add documentation about blueprint online multiplayer implementation ? Thanx
Suggestion related to the documentation sidebar / table of contents: It would be nice if the topics were sorted in a more meaningful way. For example, Engine Features -> Rendering and Graphics starts with “Fog Effects”, then “Virtual Texturing” and only then “Rendering Overview”, which IMO should come first of all.
Put more specific use-cases with pictures from actually doing it in the Unreal Engine throughout the docs. It doesn’t have to be full-fledged, final products ready to get sold in the marketplace. But at least showing, in some cases extensively or in a bit more detail than is currently shown, what exactly is involved in accomplishing the effect / using feature(s) / placing it in the scene.
Try summarizing the point at, click, click & hold, left mouse button / right mouse button, etc instructions. This is repeated in a number of basic how-to’s and other articles. It could be something such as:
LMB click-hold, drag to viewport, release
R-click in material graph, type “texture”, click “Texture_Sample” (node is placed where cursor is)
Use those kinds of instructions rather than spelling out every word and forming what, by stricter English standards, become lengthy, run-on sentences. It’s easier to read and even makes the docs more approachable.
This page says: “Our development and support teams currently use the latest version of Ubuntu; as a result, we may not be able to provide support for other Linux distributions (including other versions of Ubuntu). Additionally, read about Hardware and Software Specifications , and make sure your system has at least ten (10) gigabytes of disk space before performing the following steps.”
In reality this came out to be 78.7GB. It might be better to update this to state “make sure your system has at least eighty (80) gigabytes of disk space”.
We’ve un-sticky’d this post and we’ll likely be locking it in the near future. We’re working to streamline our , and part of that process is reducing and refocusing the sticky’d pages that appear at the the top of our . We really appreciate all of the great responses and feedback in this thread, and we really hope you keep it coming! Look for more moves and updates in the near future.