looking at the 4.8 preview thread, there are more bugs than ever!
some things that used to work are now broken, other things have remained broken for a long time, new ‘features’ are also broken.
please mr Epic it cant carry on like this, have a heart for all those good people struggling to see a reason to continue with ue4.
edit:
woo just noticed, thanks for the badge
(btw the last ‘rocket’ was pretty good, what on earth happened with ue4…)
I’m just going to up this thread one more time…
[]
looking at the 4.8 preview thread, there are more bugs than ever!
some things that used to work are now broken, other things have remained broken for a long time, new ‘features’ are also broken.
please mr Epic it cant carry on like this, have a heart for all those good people struggling to see a reason to continue with ue4.
[/]
I am starting to feel it same. I am sure that Epic is doing best and hard work but this is not going very well. Every build introduces more and more issues and many of them are fixed in next major version, so waiting for fixes is very long and even after release of update, people can’t use fixed build because it introduces new bugs. That must change :/. Simply less feature, more bugfixes.
Anyways, still I am huge fan of Epic and UE. Thank you Epic 
[=tegleg;294180]
looking at the 4.8 preview thread, there are more bugs than ever!
some things that used to work are now broken, other things have remained broken for a long time, new ‘features’ are also broken.
please mr Epic it cant carry on like this, have a heart for all those good people struggling to see a reason to continue with ue4.
[/]
Unfortunately it’s true. I really like UE4, but it’s quite hard to develop a game when you spend 50% of time on implementing new features and another 50% on finding workaround for bugs. From my experience, it’s like a vicious circle:
1. In 4.x version you find a bug that stops you from developing certain part of game mechanics (or really slows you down, for example, I’ve spent 5 days on investigating a single bug, to find a workaround and make a precise repro steps)
2. After some fighting, you write a bug report and after a few months, fortunately, it’s fixed in 4.(x+1) version! Yeah.
3. You convert your project to the new version to test it, but in like 2 minutes you discover a new, shiny bug. Repeat from step 1.
That’s an interesting idea with 4.9 being focused on stability and bug hunting. Maybe not in 100%, but let’s say, just have a 4.9 development under a “Rock solid stability” theme 
Epic, keep up the awesome work on UE4 and let’s kill these bugs!
[=tegleg;294180]
looking at the 4.8 preview thread, there are more bugs than ever!
some things that used to work are now broken, other things have remained broken for a long time, new ‘features’ are also broken.
please mr Epic it cant carry on like this, have a heart for all those good people struggling to see a reason to continue with ue4.
edit:
woo just noticed, thanks for the badge
(btw the last ‘rocket’ was pretty good, what on earth happened with ue4…)
[/]
Hi tegleg,
We certainly want to be able to address your concerns, however can you be more specific? What tools are you having trouble with? Which ones are broken and how are they broken? Have you made answerhub posts for these errors so we can track them and provide more in depth assistance?
and , if you could, please provide the same information I requested of tegleg. What specific bugs are you seeing and what steps can I take to reproduce them on my end? Have you posted these to the answerhub?
We want to be able to get bugs reported so they can be addressed, however without specific information as to what the bug is and how to reproduce it there is not much we can do on our end.
hello , thanks for the reply.
this is not something related to a specific bug but a request to fix all (or as many as possible) bugs before introducing new bugs (ahem features i mean).
please take a look at the bug report section in answerhub for more information on specific bugs users are suffering with.
it may also be an idea to look through the acknowledged (UE-somenumber) bugs and go through them one by one and fixing them. some are well over a year old and still not addressed.
thanks
ps
to all ue4 users, if you would like to see a concerted effort by the epic team to deal with the known issues please let yourself be known.
if everybody says please fix ue4 maybe they will.
cheers
Personally I really need UMG to work flawlessly with consoles, eg: controller support bug free widget focus etc. Right now its just too unpredictable and I cant limit myself to rows of menus, for a final product on consoles. In my situation its more important than any feature you can ever add.
As long as the polish includes the ability to use curves and arrays in the material editor, I support a polish only release!
[=tegleg;294449]
this is not something related to a specific bug but a request to fix all (or as many as possible) bugs before introducing new bugs (ahem features i mean).
please take a look at the bug report section in answerhub for more information on specific bugs users are suffering with.
it may also be an idea to look through the acknowledged (UE-somenumber) bugs and go through them one by one and fixing them. some are well over a year old and still not addressed.
thanks
[/]
I’d like to take a moment to address your concerns here. I think I understand where you are coming from here tegleg; You have been using UE4 for a long time (you’re been around since the beta after all) and there are still glitches in UE4 that get on your nerves, that have already been reported. So, it makes sense that you are frustrated with those still being a problem.
Let’s talk about solving these issues and hopefully I can shed some light on how these are handled from our perspective. There are a lot of bugs that have been around for a long time and have not been addressed, that is true, but most of those were prioritized under the more critical fixes. Critical bugs are prioritized over older, less critical bugs and we are only able to do so much at a time. Another thing to consider is that we have plans on replacing some of our older systems, so bug reports for those systems will get lower priority as we implement all new workflows. That is why when we go through the reports and pick which ones to fix, it does not mean we will necessarily choose the older ones.
The Answerhub’s bug reports are not going to favor bringing up long-standing bugs either. Most of the issues coming in have to do with the most recent builds or previews and not older issues. The 147 that are currently open at the time of this post are mostly 4.7.6 and 4.8 preview bugs that are new.
To better assess what long-standing bugs should be prioritized, we take into consideration community insterest; literally how many people talk about the issue. If there are bugs that are older that you would like to see fixed, you should mention them specifically here in the feedback section. I would really like to know so we can get more eyes on them and clean up anything that has been around for a long time.
Thanks!
[= ;295086]
Let’s talk about solving these issues and hopefully I can shed some light on how these are handled from our perspective. There are a lot of bugs that have been around for a long time and have not been addressed, that is true, but most of those were prioritized under the more critical fixes. Critical bugs are prioritized over older, less critical bugs and we are only able to do so much at a time.
[/]
Hey
Exactly because you are only able to do a certain amount of fixes at a time people here in this thread wish that there would be something like a 4.9 Release where all your developers are only working on fixing bugs, so no new features, just trying to fix most of the bugs. At the moment you seem to have most of your developers working on new features and I guess like 10% working on fixing bugs. Increasing this number to like 100% for 1 or 2 months (4.9 Release) is what we would like to see :rolleyes:
The point of this thread was to attempt to reduce the bugs, and increase usability, as much as possible in one go. This would do a couple of things that would benefit I think:
If we can reduce the bugs to null, if a new feature is added and a new bug comes out of it, it is easier to investigate that bug. When adding new features that have bugs, on top of a program that has multiple bugs already, it is a bit of a strain on the programmers to try to fix. Is this bug related to another bug? Do I have to fix X bug, and Y bug, in order to fix Z bug?
A stability release for end users would be a good build to use for applications as you are confident that your programmers won’t need to allocate resources to fix engine bugs.
A usability release would be great. Some experimental features that are almost always projects (I’d need to be in front of my computer to say which). This includes things such as better content management, UMG usability, just things to make QOL better overall.
By having something like this, while new “big” features wouldn’t be implemented, there would still be some new, or rather, updated things implemented. For example, a new OVR SDK update, and stuff like this. This would allow the feature team at Epic focus a more time on their new feature, rather than rushing the process, they can have a bit more time for polish or additional features that they want to implement, but may not have time to.
[=pedro_clericuzzi;276981]
Yeah, there are two discourses at Epic which directly conflict with each other:
“Avoid upgrading if your projects to newer versions”.
“This bug will be fixed in the next version”.
[/]
**I agree with this 10000% ** I’m in the position right now of having a game-breaking bug in 4.6 that required moving the project to 4.7. Come to find out there’s ANOTHER game breaking bug in 4.7 that will be fixed in 4.8. It’s a continuous cycle and it wastes a ton of time.
These sorts of things are expected in a complex software like UE4 but I think * Epic should really consider that many of their customers are single developers.* It’s COSTLY to us to upgrade to new versions, to test everything to make sure nothing has been broken and no new bugs have been introduced.
New tools are nice, but what small shops want more than anything is simply a rock solid, stable release because we just don’t have the time or resources to chase updates in the hopes that the bug we are dealing with has been fixed.
This is exacerbated by not having a public bug tracker, so it takes quite a bit of time to figure out if upgrading will fix the bug. I’d estimate that out of the 30 hours a week that I have available to work on my project, **25% of my time is spent working around, solving or discovering issues that turn out to be bugs in the engine. **
Don’t get me wrong, UE4 is hands down the best tool that I’ve used in years and I love it to death but the ultimately, the less time we spend struggling with bugs in the engine the faster we can release our work and the faster Epic can get their cut
A stability/bug fix release is badly needed in my opinion. Not because the engine is riddled with bugs, or a bad product but just due to the fact that time is our most valuable resource and it only takes one bug to bring our progress to a standstill.
That is somewhat essential for workflow.
The need to switch to different viewmodes is counter intuitive. The reason i call it essential is because you are after all working with a tool for creating art…
And this
UE-14749
Not being able to undo camera movement is extremely frustrating at the best of times. Especially if it took you a while to get just the right camera angle and have a mouse slip
Would it not be possible to setup test cases, focus groups, get the community involved in breaking specific features. Testing on different devices. Sometimes it’s enough for you to create specific builds during development, with debugging on, so we can break these features. Coordinate with the community, maybe even have a permanent section for bug hunting. Maybe even do badges for bug hunters. There are so many things that could be done to focus on making things stable.
One big step would be to tell to focus on something specific at a time. For example “Can you break our terrain tool? How does it work on different devices?”. in such a thread, there would be a huge list of bullet points where you ask the community to reproduce and try to crash the thing.
That will make it more of a group effort than having a couple of developers at Epic trying to cover huge ground. Team up with us. We just need coordination on this.
I also hope we one day get something better than AnswerHub. It’s incredibly fragmented and split between beginner questions and deep issues that needs solving.
[= ;277204]
Hi everybody,
We’re all really interested in this feedback and we’d love to help out with stability. While we do have eyes on what is directly reported to us via the Answerhub’s Bug Reports (and to an extend, crash reports) and we try to fix those as they come in, that doesn’t always translate to greater overall stability.
What would help us to understand exactly where to concentrate our efforts would be more information about the specific features and areas that you all feel are unstable. Does the instability come in the form of “unexpected behavior”, crashes or corruptions? Some posts are very helpful with this already, but I’d like to get a better picture from more perspectives.
Any information about this will help us better concentrate our testing as well as give us an opportunity to discuss the progress that has been made internally.
Thanks!
[/]
In my experience, blueprint corruptions are the killer.
Compared to text based scripting languages it’s the achilles heel. Imagine if you could corrupt a text based script file just by typing the wrong thing into it. Would this be acceptable in any way? Sure, you might introduce a bug or lock up the game thread but you’d never expect to have to completely rewrite the actual script file from scratch because the file itself corrupted because of something you typed in it. It shouldn’t even be POSSIBLE to corrupt a text file by typing the wrong instruction into it.
I’ve been developing my project for the last year from the first version of UE4 till now. I make frequent backups, am very cautious and test thoroughly when upgrading to a new version of UE4 (Only do this when forced to by bug fixes that I need to take advantage of). In spite of all the precautions I take, I’ve lost days/weeks of time due to corruptions in blueprints. REINST errors, generated structs corrupting and Blueprint Function Libraries are the culprits.
When using blueprint it feels very odd/frustrating to have to handle things like structs or circular references with kid gloves lest your blueprint corrupt and force you to have to completely recreate it. Having to completely rebuild a blueprint because it has become corrupted is frustrating because if we were scripting in a text based api we could just edit the script to fix the bug you’ve introduced and keep on working.
In Blueprint, corruptions cause data loss and this feels very very backwards. If you don’t catch the corruption in time, your recent backups could also contain the corruption. There’s no go way to tell. It’s the worst and scariest part of developing in UE4.
A few real world examples from this past year:
A math node caused a blueprint to be unstable. It compiled, with no errors but it would corrupt the project save. I lost 5 days finding the source of this bug.
I have 3 class blueprints that no longer compile if I use them with blueprint function libraries unless I recompile the function libraries. No warnings, no other errors. These are base classes for my game and recreating them from scratch to fix an error that nobody understands or knows how to prevent again is a tough sell.
Editing a struct corrupts references to that struct about 20% of the time. No way to predict why, or how or when this will happen. The structs just disconnect and you suddenly have 5, 10 blueprints that won’t compile.
Let me be clear: I’m a HUGE fan of you guys and what you have built. Blueprint is an amazing solution, but the corruption spectre really really makes it scary to rely on.
[=;276993]
Wow… a major update just for stability… I think that is a bit too much - I have never heard something like Windows 2000 which fixes all bugs from Window Me (and no new features).
I personally think the reason of so many minor revisions within 4.7 is because there are quite major architecture changes within the engine. So it affects features which used to work and there are lots of features in this engine… Probably 4.8 will be much better.
[/]
Windows 2000 was NOT a fix for ME! In fact 2000 was shipped in june (Or july), And Me shipped in september! Just wanted to clear that up. Also I still use ME! It’s not nearly as buggy as people claim it to be. Windows 98 service pack 1 was actually worse! And XPsp1 was smoked by my ME computer! One of the major reasons it was hated, Was it didn’t allow MS-DOS mode. That’s my two cents on the matter. Also I agree with the reason of this thread! (Also Me is based on the 9xwindows and 2000 on NT.)
Wow! Great info from I’m going to try to address as many posts as I can at once, so forgive me if I miss something.
[=;295099]
…]you are only able to do a certain amount of fixes at a time people here in this thread wish that there would be something like a 4.9 Release where all your developers are only working on fixing bugs, so no new features, just trying to fix most of the bugs. At the moment you seem to have most of your developers working on new features and I guess like 10% working on fixing bugs. Increasing this number to like 100% for 1 or 2 months (4.9 Release) is what we would like to see :rolleyes:
[/]
It’s more like 50%/50% most of the time, but that means we add new code at the same pace we fix it. We do “Bug Bashes” where developers spend several days doing only fixes, but development is always a back-and-forth between adding and fixing. This is simply the beast that is software development.
But I do agree with here that it is not a far-fetched idea to do a build with a focus on stability and minor feature updates. I say to include “minor feature updates” because some of the bugs that are being reported in this thread are actually feature polish or new features to current systems.
[=;295147]
Would it not be possible to setup test cases, focus groups, get the community involved in breaking specific features. Testing on different devices. Sometimes it’s enough for you to create specific builds during development, with debugging on, so we can break these features. Coordinate with the community, maybe even have a permanent section for bug hunting. Maybe even do badges for bug hunters. There are so many things that could be done to focus on making things stable.
One big step would be to tell to focus on something specific at a time. For example “Can you break our terrain tool? How does it work on different devices?”. in such a thread, there would be a huge list of bullet points where you ask the community to reproduce and try to crash the thing.
That will make it more of a group effort than having a couple of developers at Epic trying to cover huge ground. Team up with us. We just need coordination on this.
[/]
That was mostly the point of the preview builds. So the community can use UE4 and let us know what is not working for them based on their project’s needs. I like the idea of doing coordinated, community-involved bug hunts; it could be fun and I’ll run it past to get his opinion.
The “Bug Hunting” section is the feedback section right now.
[=SaviorNT;295103]
If we can reduce the bugs to null, if a new feature is added and a new bug comes out of it, it is easier to investigate that bug. When adding new features that have bugs, on top of a program that has multiple bugs already, it is a bit of a strain on the programmers to try to fix. Is this bug related to another bug? Do I have to fix X bug, and Y bug, in order to fix Z bug?
A stability release for end users would be a good build to use for applications as you are confident that your programmers won’t need to allocate resources to fix engine bugs.
A usability release would be great. Some experimental features that are almost always projects (I’d need to be in front of my computer to say which). This includes things such as better content management, UMG usability, just things to make QOL better overall.
[/]
Unfortunately there is no such thing as software with no bugs. Even relatively simple stuff, like a calculator, is impossible to make with no errors. I do understand your point though; minimize problems before moving on.
I agree with that, but see my next point.
Also agree, but that brings up the point that now we’re talking about something like the Tick-Tock method, but for software builds. We’ve talked about it before internally, but were not sure how people would react to long intervals without a release or update. Any feedback would be appreciated and I can run it up the chain.
[=;295190]
In my experience, blueprint corruptions are the killer.
Compared to text based scripting languages it’s the achilles heel. [Text omitted as this is getting long already]
[/]
Awesome feedback! I’m going to bring this to up to our lead blueprints programmer and see what his opinion is on the subject of what can be done.
Thanks again everybody! I really appreciate the ideas and opinions!
[]
In my experience, blueprint corruptions are the killer.
[/]
Thanks for the feedback, and we’re sorry it’s been frustrating for you! You’re absolutely right that the equivalent wouldn’t be acceptable in a traditional text-based scripting language. It’s also not acceptable in Blueprints!
The corruption you mentioned are usually the result of cyclic dependencies. Thanks to the work of Beach, for 4.8, we’re fairly confident we have all of these cases licked. With 4.7, we shipped with cyclic dependency fixes for all of the cases we knew about internally. That included not only our own games, but quite a few examples from the public. Every time you guys have a bug report and are able to upload a repro or your project, we use that in our battery of tests. So many thanks to those who have contributed! With 4.8, we’re back to having no known repros for cyclic dependencies. If you see any, let us know, and we can get those added to our test battery!
Unfortunately, due to the nature of the cyclic dependency beast, there may be a few more cases lurking out. As you mentioned, the structs were a big culprit. The current infrastructure we built is much more robust to that sort of failure, and your continued bug and project submission help ensure it will be.
So, while I know it doesn’t make up for the instability you’ve experienced, hopefully that will at least shed some light on how we’re trying to make it better through a combination of code improvements and testing framework will make things better moving forward.
[]
What would help us to understand exactly where to concentrate our efforts would be more information about the specific features and areas that you all feel are unstable. Does the instability come in the form of “unexpected behavior”, crashes or corruptions?
[/]
Others have already mentioned this, but Blueprints: I’ll try to follow tutorials from other people, and the end result that used to work a few weeks ago no longer works now. Specifically, I just asked in the Answer Hub about the Select node failing to list physical surfaces. Sure, that’s a very specific problem, until you realize that the only way blueprints can communicate with physical surfaces to change sound effects and particles is through that select node. For people actually trying to publish a game with this effect, I can see how this kind of thing would be frustrating beyond belief. On top of that, spawning decals don’t work at all, so I got around this with mesh particles as a temporary fix… but for some reason, mesh particles will disappear all at once after a minute or so, and I’m not sure why.
And something else that’s weird, I’m making footprints that spawn Also, I had the engine crash twice on me today for copy+pasting a WorldAlignedTexture material function in the Material Editor.
When it comes to optimization, this is something that still needs a lot of work. I made an unlit transparent decal that seems to take up 7 texture samplers. That’s 7 draw calls for one texture! The lit version has 9. Surely it doesn’t take this much texture samplers to render one unlit texture! I’m so glad batching is coming up in the new engine, but this kind of optimization needs to be EVERYWHERE: I need to spawn mesh footprints from different particle emitters, and at the moment it seems like each footprint is not batched. I ran stats on this, and with only 5 seconds of onscreen time, they’re adding an extra 18 draw calls. If it was possible to cut this down to 2, that would be great. I wanted to try keeping the footprints on for about 10 minutes, but that would require at the very least 1800 decals. This isn’t too bad for a GPU to handle, especially if the footprints are small, but unbatched on the CPU and footprints will be the only thing I can draw to the scene.
[= ;295343]
That was mostly the point of the preview builds. So the community can use UE4 and let us know what is not working for them based on their project’s needs. I like the idea of doing coordinated, community-involved bug hunts; it could be fun and I’ll run it past to get his opinion.
The “Bug Hunting” section is the feedback section right now.
[/]
The problem with using the preview builds is that it’s telling the community “Try this whole beast, not anything specifically, and let’s hope you find the issues.”. It’s a needle in a haystack. It also happens way after the developers have implemented something. Not during its development when it is crucial to have test cases. It is not focused in any sense or form. Unreal Engine is too big for a generalized approach. The preview builds are a step in the right direction, but not anywhere close to a focus test.
I also completely agree with ****. Blueprint instability has been so bad at times that it got me to learn UE4 C++ to get away from it as much as possible. Blueprint instability has also caused major issues in our project, which have given us weeks of setbacks at times when we are forced to migrate things to C++. Note that I am not supposed to program in our project, yet I’m forced to do it.
[= ;295343]
3. Also agree, but that brings up the point that now we’re talking about something like the Tick-Tock method, but for software builds. We’ve talked about it before internally, but were not sure how people would react to long intervals without a release or update. Any feedback would be appreciated and I can run it up the chain.
[/]
Tick-Tock would be awesome. So yes please.