Sharp decline in Official Responses from Epic throughout the community.

[VictorBurgos]

While you're here, why directional light doesn't support Lux yet?

Please don't sidetrack this thread. Create a new thread or post in Answerhub. Thanks

[VictorBurgos]

1. There should be separate place for suggestions, something like UserVoice
2. I think it would be nice to have optional paid support (i.e. same questions as on answerhub but with mandatory feedback)
3. Bug reporting should have very strict rules to follow (ideally - bug reporter have to make a video with steps to reproduce it on a blank project)

DanielW Thanks for the answers. But IMO getting "this feature is not/won't be planned" is better than nothing.

junfanbl IMO Crytek doing it wrong. You pay to get access to hidden answers. WTF??? And paid support is expensive. $100+/hr.

Aye, Uservoice for Feedback is something a long long long time ago I asked for. Another thing was bug reporting directly to Epic from within projects (with the ability to take desktop/editor screenshots). Sadly, they even took a decently helpful feature out from the Editor..the Google/Doc Search bar...

[ClavosTech]

In addition to what you suggest above, how about documentation on the level of QT. Can you imagine how many questions would be resolved with outstanding documentation? (with examples, and the why).teak

+1 - Better documentation that actually explains things would be huge. In BP its easy to hotwire nodes and try things, but that doesn't bring much depth in knowledge.

In that sense BP is a fail, whereas C++ offers actual insights. However, only a few lucky devs are equally productive with both. If you're a small-Indie-team / solo dev, do you want to spend your time becoming an engine programmer or focusing on gameplay etc.

So please Epic, if you do offer premium support MAKE DOCUMENTATION part of the equation. Right now, its still too low a priority!

[S-ed]

Funny thing. I've recently offered Epic to make new documentation engine for them.
(I've been thinking about it for years, but just recently got some confidence)

[Raildex_]

I think implementing a stackoverflow moderation would help alot.
in SO, every member can flag posts as duplicate, on hold and too broad (afaik if you have some reputation threshold) which all reduce the reputation.
Having your own threads marked as these surely encourages to overthink the question and searching for a solution yourself.

[junfanbl]

S-ed I've been using CE since it came out, so I don't use paid support a lot. Only occasionally. Otherwise it does add up fast. Sometimes you need it though.

franktech I haven't done too much C++ development in UE4, what exactly is it lacking? Is the API documentation not thorough enough? As far as BPs go, those are great for prototyping game mechanics, but are hardly suitable for packing and shipping a game. I wouldn't exactly call them a failure. I don't think they were meant to replace good old fashion coding.

I think at some point if you aren't paying for support, then you are going to have to struggle through the process. Unless of course something just flat out does not work. That's a different story.

[VictorBurgos]

This is the thing about time and money when it comes to Game Development. You're either spending time doing something or wasting time trying to do it and in the end time equals money.

You could try to debug something that may not be fixable on your end for 8 hours (or days), or you could get that reply from someone within an hour, and saved yourself 7 hours (or days) of dev time doing something else. Let's say it's an engine bug and there's no way to fix it, so you need a workaround, well, hopefully the engine tech will be able to give you that workaround a lot quicker than coming up with it yourself. Or at the very least, you know that you don't need to try to debug it on your end any longer and you can figure out a workaround yourself.

Either way, a priority support system in this scenario would work for 90% of devs. The other 10% will be the cheapskates that can't afford the priority support and will no doubt be "all up in arms" about it.

Trying to please everyone is futile, but you sure could please a lot of folks with priority system in place. It's optional. The regular answerhub "answer rate" should not be affected, especially with the money coming in from Pri Support, you should be able to afford a few extra bodies.

But, we're getting ourselves a bit off topic with the pri support sadly. Still need to do something fundamentally about Answerhub Bug Reporting and Feedback For Epic.

[ClavosTech]

I haven't done too much C++ development in UE4, what exactly is it lacking? Is the API documentation not thorough enough?

1. Automatic-documentation-generation, so not real actual docs.
2. Partially or totally out-of-date sample projects and tutorials etc.
3. Broken promises regarding adding more examples and wikis.

C++ examples: 1 2
BP - examples: 1 2

As far as BPs go, those are great for prototyping game mechanics, but are hardly suitable for packing and shipping a game. I wouldn't exactly call them a failure. I don't think they were meant to replace good old fashion coding.

The vast majority of the BP-API docs are auto-generated or code-scraped one-line reference pages that lack clarifications, examples, explanations of nodes that appear to do the same or similar things. I'm saying that's an 'F' grade fail in documentation, that's all. BP rocks overall, even lesser-loved Kismet when leveraged had moments of brilliance! Whereas Wikis (Rama etc), quality-forum-threads, free-community-projects, compendiums by eXi / Romero etc... That's real documentation!

I think at some point if you aren't paying for support, then you are going to have to struggle through the process.

There will be struggling even with it, just more so without new docs!
So better to keep expectations low for now, for two reasons. Why?
The numbers don't really add up. Some Reality check / guesswork:

Trying to please everyone is futile, but you sure could please a lot of folks with priority system in place.

#1. Priority / Premium Support.... But who really gets priority....???
Its likely that even with paid support, it won't be a level playing field.
Some kind of priority / system would probably begin to emerge imo:

1. Epic-Active Games / Internal Projects,
2, UDN partners and high rollers,
3. Premium engine contributors (Rama and co)..
4. Community leaders and visible supporters (Victor and co).
5. Skilled game designers or higher-profile Indie-projects (TheJamsh / Jacky and co).

So what about everyone else? Its reasonable to assume those lacking high-profile projects or badges would be further down the list at tier 10 sitting in a queue somewhere. That's just reality, and why new solid documentation is so important, because it brings possible benefits to everyone...


#2. Headcount... Subscriptions - #How many new extra Epic staff....???
For a long time Epic held off adding headcount to the marketplace team, claiming it was a break even operation. So we know Epic are vary of adding headcount, just like any US corp really. But lets say 1000 devs sign up to premium support. Lets say the cost is what the engine used to be or $20-$30 USD / month. How many devs does that pay for? Salary for a dev in NC (75-100k mid-level, 120-150k top-pro?). But the overall cost to Epic will still be double or treble after all govt-taxes / benefits / all hiring costs are factored in. So how many people will get hired? 2 Maybe!

But ok, so what-if 10,000 devs sign up? Now things are looking brighter. But there's still going to be a trail off at the end of Year1, Year2, Year3 as devs leave the program (after getting what they need) or finding out it isn't what they wanted. So maybe 5-10 new staff get hired overall. But realistically speaking 10,000 subs is a lot for this community. So at a guess I think 2 new hires is a more likely outcome, one dedicated to documentation and the other an engine-specialist / support-tech. If so, that's not going to bring overwhelming change, but the documentation might improve....

[xuri]

Ian Shadden actually explains the problems with the docs quite well during one of the streams( I think it's the fireside chat stream from a year or two ago ). He said something like with 500 men and 10 years they still couldn't get it done because the engine is constantly evolving, things are added/removed/modified, and that instantly makes them out of date or not quite right. It's one of those infinitely endless tasks. He also mentions that often times the code comments, from which the docs are generated, aren't always that great either which also causes problems.

Personally my first port of call when I'm researching something is usually youtube. Matthew Wadstein's channel, places like that( and some of the others franktech mentioned ). I only go to the official docs as a last resort.

I avoid answerhub like the plague. I think I've only ever posted there once. It's such an ugly thing to try and read.

[ClavosTech]

Ian Shadden actually explains the problems with the docs quite well during one of the streams.... He said something like with 500 men and 10 years they still couldn't get it done because the engine is constantly evolving, things are added/removed/modified, and that instantly makes them out of date or not quite right. It's one of those infinitely endless tasks. He also mentions that often times the code comments, from which the docs are generated, aren't always that great either which also causes problems.

You have to note though, how this tactic sort-of gives Epic a license to get out of creating new docs.
Not that it isn't true, its a fact particularly at the C+ level! Its just that its also built on a few mis-truths...

What do I mean by that???

Well imo the engine changed more radically and broke more things between 4-4..4-10 vs 4-10.. 4-16.
Whereas at the Blueprints core code level, movement / collision etc, hasn't really changed that much...
So it'd still be invaluable to get detailed documentation on these 2 topics for example... This and This...

[kamrann]

As an engineer, providing support on these forums is not in any way required by Epic, and I handle a lot of support from other sources that is part of my job (UDN, internal projects). I'm only here because I care about improving the engine, and doing my best to help out users so we can make great things together, but I don't have much time.

Your choosing to be here, however infrequently you may have the time to actually post, is definitely appreciated DanielW .
I want to give my thoughts on bug reporting, from the perspective of a programmer.

With a couple of exceptions for urgent cases (the last one I considered 'urgent' related to an issue with core UBT functionality; it was ignored and persists 2 full engine versions later), I essentially gave up reporting bugs to Epic a long time ago. As ridiculous as it sounds, I often still write down some details that I keep locally for my own reference, but don't submit a report because it's an unjustifiable waste of time.

The fundamental problem is that invariably reports have to get through a support technician before an engineer will see them. I understand completely why this filtering is needed. As a programmer though, when I find what I think is a bug, I dig into the engine code to see what's happening. As such, my reports generally had detailed information about what happened, why, and generally linked to specific offending lines of engine code on Github. These reports would be dealt with by support techs without any programming knowledge, often misunderstanding the technical details, asking for full repro projects, etc. This is no disrespect to those people, who of course were doing their best to help, but the bottom line is the time investment required to get a report accepted was absurd.

The alternative is Github PRs, but in most cases, I know enough to pinpoint the bug, but not enough to be confident of the best way to fix it. I don't want to abuse the PR system; anyway, lately even PRs are suffering from the same problem, building up without response.

I think an ideal system would be to have some automated filtering of reports, so that technical reports with references to specific lines of engine code could go through more directly to the relevant Epic engineers. I realize this is squarely in the "we won't get to it anytime soon" category, of course. I just wanted to point it out though; I really think Epic are missing out on a lot of potential help from their community due to lack of good feedback infrastructure.

----------------
As to Victor's general point, I agree the Feedback forum is definitely not what it used to be. There has without doubt been a steady decline in staff involvement ever since the UE4 subscription model was scrapped, though I suspect it's more down to the increased number of engine users and requests than any intentional change in policy.

[Doctor Ergot]

There has without doubt been a steady decline in staff involvement ever since the UE4 subscription model was scrapped, though I suspect it's more down to the increased number of engine users and requests than any intentional change in policy.

Also... there's lot of of requests for major systems like Blueprints. It would be awesome to implement most of them, but... if you'd look at the Issues, there's 27 pages of bugs listed in the main Blueprint category. Simply Blueprint engineering team isn't big enough.
https://issues.unrealengine.com/issu...t&sort=updated

They're adding new important features to blueprints in recent releases, it wasn't always like that. And we waited long time for those features.
So I guess, we have to wait until some engine teams will be able to find time for all these community requests

[xuri]

You have to note though, how this tactic sort-of gives Epic a license to get out of creating new docs.
Not that it isn't true, its a fact particularly at the C+ level! Its just that its also built on a few mis-truths...

What do I mean by that???

Well imo the engine changed more radically and broke more things between 4-4..4-10 vs 4-10.. 4-16.
Whereas at the Blueprints core code level, movement / collision etc, hasn't really changed that much...
So it'd still be invaluable to get detailed documentation on these 2 topics for example... This and This...

I don't disagree with you. As someone who struggles with blueprints it would be nice to have some of the more solid, and therefore less fluid or evolving, features more nicely documented. Not everyone, myself included, is particularly adept at learning by tearing apart example and template projects. It's a particular pain when you're first starting out and you don't know what to look for in the first place. I mean, before I started using unreal, I was using a DX9 based graphics library and my way of learning was to read the docs for X function and then go from there. I've had to completely change with Unreal and spend a lot of time watching videos( which are often out-dated, though still useful in a general sense ) and I have a more difficult time learning that way. A mild example of this is destructible meshes. Anybody watching a video on youtube about how to setup basic destructible meshes is going to find them confusing since in 4.18 you now need to enable that functionality as a plugin. I'm sure Epic has a reason for doing that but it is going to make those video's very confusing for people coming to the engine afresh. I haven't checked, maybe in the docs it now mentions that you must enable the plugin, but I suspect it doesn't.

Maybe Shaddenfreude can pop in and just give us a heads up on if there are any plans for improving the documentation because at the moment it can be a bit irksome. Though as I said above I do get that it's an endless task and if they have with, whatever system they're using( doxygen? ), some in-house rules about their code comments. I haven't actually looked at UE4 source at all yet as I'm still learning the basics but they must have some sort of guidelines for the documentation scraping. I know it can be a pain and time consuming but if the engineers had some solid rules to follow about the information in their comments the docs might not be quite so uninformative.

[ClavosTech]

Maybe Shaddenfreude can pop in and just give us a heads up on if there are any plans for improving the documentation because at the moment it can be a bit irksome. Though as I said above I do get that it's an endless task

Lets try other devs who do docs too Richard Hinckley Jeff Wilson...

Docs in an ever changing 'live' environment, has always been a challenge.
But this is the path Epic has set itself now under software-as-a-service etc.
Every corp in the same boat has the very same challenge, can't be ignored!

[VictorBurgos]

Lets try other devs who do docs too Richard Hinckley Jeff Wilson...

Docs in an ever changing 'live' environment, has always been a challenge.
But this is the path Epic has set itself now under software-as-a-service etc.
Every corp in the same boat has the very same challenge, can't be ignored!

Please keep it on topic. This is not a discussion about documentation. There is already a sub forum devoted to that, which I am pretty sure I even have a thread on there about this. Which you linked. So anything relating to documentation should go there, not in this thread please.