With the old answerhub system we had community involvement; others would report the same issue and share their own findings. Others would post workarounds and how you can get by in the meantime. We no longer have that and it falls entirely on you to deal with the bug report process. It is an exercise of frustration.
The two most recent bugs I posted consumed a lot of time dealing with the person on the other end who simply couldn’t reproduce basic issues, you basically go down an ELI5 (explain like I’m 5) rabbit hole until either they see the issue or there’s no other way to clarify - and these are with simple problems with simple steps.
This has put us in a terribly anti-community position of having to not report bugs, fix them internally, and not share the solutions other than seeing someone in slackers asking about it and telling them. In the past we would have fixed it and the bug report that anyone could search on google would have the solution for anyone who can’t wait. But now we have no means of reporting bugs that doesn’t waste heaps of time.
And the people on the other end never escalate issues - they merely give up and don’t respond. With my previous bug report, they finally saw the issue and filed it with something they believe is similar yet is completely unrelated in every possible way and now the issue is buried instead. Fixing the one that filed it under wont fix this.
As far as I’m concerned, you no longer have a usable bug report system.
Generally I agree, sometimes it’s really a pain to explain them what is wrong exactly (besides submitting steps, example project and everything), but if you are able to fix it internally, you should consider contributing via PRs. PRs can also contain workarounds and detailed issue description, and that’s also well searchable on Google.
Also, you can still write a “Bug Report” on AnswerHub, then submit the bug report ticket with the link attached. If they can’t deal with it, it will still be searchable via Google. I know that it’s not optimal and involves some extra work, but it’s the best we can do right now. Although I agree that Epic should definitely look into it, knowing their speed of response for issues like this, it’s not gonna change in the near future.
Why do you feel explaining the issue is a pain, anymore than you’d need to explain it to help get it resolved?
Echoing KristofMorva’s sentiments, you can still share on AH, and we certainly encourage you to do so. Our teams won’t always be able to jump in, so having that larger collaboration with the community is important.
We’ve found that the form has improved the quality of the bug reports we receive and helps us pass something of value to our dev teams. Now, if they can’t reproduce the issue, it certainly makes it difficult to share and solve.
That said, there are certainly ways we can work to improve the process. I’ll bring it up. Thanks for the feedback!
PR isn’t going to happen. When we fix stuff internally its not going to be how Epic wants it fixed, it’ll suit our needs and be a band-aid. We’re not hobbyists and don’t have that much free time, our goal is to make a game (imagine that!) not fix their engine for free. None of us want any extra engine builds floating around taking space either, we have no need of master otherwise.
Lots of PRs just get backlogged anyway.
Yes, we can post on Answerhub and thats all we’re willing to do - but we’re not going to go repeating ourselves in two different places. Keep it in one place where everyone can see.
So have the form post to answerhub -______-
Its a pain because they can’t understand simple issues with clear repro steps (that have been provided to other team members to test without any issue). You have to ELI5 everything you say repeating every step several times to make sure there isn’t anyway they can not understand it. Its an exercise of frustration and time wasting.
And even if they reproduce it, even if they understand it, they never escalate and in my experience they don’t resolve it or even file the thing correctly - so even when you eventually get there, its for naught. And so a genuine bug that has been reported remains not in the tracker and the fact other people have the issue not publicly available and the workarounds also not available.
You want to filter out the large amounts of bugs that aren’t engine related from people who don’t know what they’re doing, fine, but you’ve filtered out genuine issues that affect everyone and need fixing too. And now, the only people who will use your system are the ones who aren’t busy making something worthwhile because that takes *so much time and energy - *like your bug reporting process.
I wasn’t aware of this when posting but you already have a massive thread telling you all the problems with your system and you’ve ignored the thing. I wonder if it has gotten to the point where your company doesn’t want to admit it screwed up and is obstinately sticking with a poor system.
You really expect people with experience to work for free on your engine? Because all you did was filter those people out.
Not everyone likes the new Bug Reporting form. Can we call that out and have Epic accept it as fact, based on posts here?
Its more likely ‘anyone whose anyone’ is using UDN. This Zak Parrish clip says a lot about what Epic actually thinks of AH.
The truth is, you’re either part of Epic’s inner circle flying ‘first class’ with access to UDN and 24-hr turn-around support etc.
You’re Joe-The-Fortnite-streamer flying-in-coach and pretty much invisible to Epic now. That’s a long way from 2014-2016…
When the engine was weak and Epic needed the ‘Community’, they were happy to tap that option. Its a different world now…
Users have tried holding up a mirror: Here / Here / Here etc etc. Response: <Tumbleweed> Conclusion: We’re on our own…
All reported issues (at least by licensees) should be visible publicly by default. Also, all the issues are known for the released version of the engine. Even if reported internally.
People should never ask to make any issue public - such information should always be available and searchable.
This way next team encountering issue wouldn’t waste time on reporting it again, finding repro and so on.
Mostly because the bias between needing help to resolve that and making a courtesy for followers not to run into it again is shifted towards the latter and likely, bug reporting in this context can hardly be justified by expectations for it to be fixed within dev cycle, unless it is a critical showstopper.
Bug or undesirable occurrence being detected, described and available is by itself far more valuable for others than any effort to fix it.
Fun fact that sometimes, info from Joe The Streamer might come pretty handy.
Answerhub is slow, buggy, frustrating to use, often loses information for no reason and it’s search system is shocking. I couldn’t even get pages on AH to load for months, before it was spontaneously fixed. I really wish Epic would port over to a system which actually encourages discussion and makes it easier to respond (say for example, stack-overflow style system).
It would also be nice if Issues / Bug Report Form / Forum / Answerhub could be linked together more conveniently.
I agree that the bug submission forum, while it is a good way to get info directly to Epic, completely bypasses any kind of community involvement. You could jump through a lot of hoops without ever knowing if somebody else in the community fixed it already. It wastes our time and Epic’s.
I find that Discord is honestly the best place to get answers to common issues at the moment.
After 4.22 upgrade my previous projects have started to crash before opening, there are error codes and logs etc. which I can share. But how do I tell you to reproduce it?? And if I can’t I can’t submit.
For all that months and months of hard work, ALL I can do right now, it seems, is to hope next release fixes it. It’s like walking into the dark. I posted in answers hub and got the standard, this is not active anymore response.
I know engine is free but users are putting their life, belief and sweat into it too.
There is the Crash Submission screen that opens automatically on an editor crash, where you can also explain the reproduction steps.
And what are you talking about that there is no way to submit the bugs? That’s exactly what the bug submission form is for. Everything I have reported so far has resulted in a decent response or the recording of the issue.
It’s a totally different issue if your project is not compatible with 4.22 due to changes, which you’ll have to fix yourself (or with the help of the community, but not Epic’s). Of course.
Totally agree with this post… seriously I’ve completely quit reporting bugs ever since the new bug report system. When previously i was successfully reporting bugs all the time. The ppl on the other end are literally retarded. Don’t even try. They’ve done the exact same thing with my bug reports. Which were impossible NOT to reproduce as i reproduced them on multiple computers and other users agreed also… And my reports were explained as if the people on the other end were a 5 year old. (even included ready projects and videos, and perfectly explained steps) And they still couldn’t reproduce anything, or they fill it in with something similarly titled but completely unrelated.
100% guaranteed… They are either intentionally trolling-bullshitting or they are literally retarded.
You’re not doing anything useful by reporting bugs… Just forget it. The people on Github is what’s been saving the engine all these years… Unfortunately reporting there, only works if you also fix the issue yourself… bcs others may add additional code that’s completely unrelated to the issue you reported, and even if someone gave a fix for your report, they wont accept it. There are trolls there as well it seems.
Please read my post, “After 4.22 upgrade my previous projects have started to crash before opening, there are error codes and logs etc. which I can share. But how do I tell you to reproduce it?? And if I can’t I can’t submit.”
Also I’ve sent automatic ones, already before 22.1 was released. Hoping there would be a fix but that is what I mean by walking in the dark.
I see, there isn’t much more you can do in that case than the automatic crash reports, although you should check first if the crash is caused by any C++ code of yours or not. If you share the issue in a specific post, there will be probably someone who can help you to locate the core of the issue.
Although PR validation could (and should!) be a hundred times faster, they do accept focused fixes regularly. To be fair, whatever we send in with PRs, they’ll have to test and maintain it throughout the lifetime of the engine. Of course it’s not an excuse to leave there PRs for years (!) untouched, but it’s better than nothing.
I think it’s terrible. It seems to me an easy way to get people to stop talking about the bugs. For example the OnAudioPlaybackPercent bug has been there since 4.15. If anyone brings it up on answerhub they refer you to report it on the new bug system… It still is broken in 4.23.