I personally quit AnswerHub after spam bots invaded over there again and again.
Much appreciate the candid response, and I don’t disagree with you on some points there. But like others have mentioned and I did in my OP. Any response is better than no response. I mean, “insufficient detail” is subjective right? At this time there’s nothing anywhere stating what the minimum amount of information you need to provide.
The issue with Google sometimes is being able to get the right terms into the search to bring up what you want. I would like to think that most devs knew how to Google and tried to before posting on AH, and so that should be the assumption on your end as well. I know for a fact that even when you start typing in the Title into an AH post, when it brings up “relevant” posts, that 90% of the time it’s not related to it at all. I’m pretty sure it’s just using keywords in its algorithm.
TBH, if there were a way to link Issues links along with the related posts, that could be helpful. But I do admit sometimes Issues is just as bad when it comes to searches.
Anyway, so, if it comes down to $$$ , like I mentioned in a later post, I would like to see a Priority Support option for developers. Something in between what you have with the public answerhub and UDN. Be it a monthly subscription service or what have you. If it’s a lack of personnel, which I suppose may come back to $$$ anyway, I would obviously just say then “hire some more” devs. Someone linked something on here about Unity doing some But Report experiment hiring out 20-25 student (forgot already while writing this), but they went from 2k to 5k bug report logs on average a month.
Obviously, hiring an additional 20 bodies may not be feasible.
Feature request: “No, sorry” is better than nothing. Trust me. Feeling “unimportant” or “invisible” because there are no responses to what devs feel are “important” to them, is worse than a “No”.
As for “Mentioning”, if we could get a list of Epic Employees that do not mind being tagged separated by division, that would be greatly appreciated. Pin that somewhere, maybe even here in “Feedback For Epic”, or every major sub-forum. /shrug
Thanks again for the response!
Just want to clarify - I’m sharing my experience as an engine programmer with very limited time. We do have dedicated support staff who are extremely active in these forums and AnswerHub!
Thanks for all your responses. It’s good to have a dialog about this =)
While you’re here, why directional light doesn’t support Lux yet?
I think a paid support option would be nice. If you are a serious developer, and not just a hobbyist, you would likely take advantage of that. That would also encourage people to do there own research so they can save money instead of spamming the forums and AnswerHub. Otherwise, when you are stumped, you pay. I think that is a good idea. I know that is what Crytek is currently doing and I have been taking advantage of that. It’s rather nice actually. You get to talk to the staff about any issues you are having. Which for that engine is even more appropriate.
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
- There should be separate place for suggestions, something like UserVoice
- I think it would be nice to have optional paid support (i.e. same questions as on answerhub but with mandatory feedback)
- 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.
Please don’t sidetrack this thread. Create a new thread or post in Answerhub. Thanks
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…
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)
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.
@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.
@ 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.
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.
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. channel, places like that( and some of the others 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.
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.
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.
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 
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.
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.
Agreed. Let’s not derail this thread. We would be happy to discuss these documentation topics in the Documentation Feedback forum.
How about creating a Epic Dev Council that has rotating members for a year of service (or sooner, if a person doesn’t actually contribute). Anyway, the goal of this council is to consolidate all of the feedback into a single document / position paper to be discussed with appropriate Epic staff. Additionally, the group along with Epic staff would create a list of priorities that would be incorporated into longer term published plan on . Finally, there must be wins… I mean, items that the council collects that actually gets implemented…or…it would just be a waste of everyone’s time…
teak
PS: The council could start at GDC…and, each year after that a new slate of members is appointed. (or elected??)