Would be nice if there were a feature locked version that focused solely on stability, after that they could start adding features again but if they find bugs in the stable one they patch it even if the newest version is a couple updates ahead (sort of like how microsoft will still update windows 7 even though 10 is around the corner). I don’t know how feasible this is developer side just a thought.
In all this noise I would like to express my strong wish to have a much more stable tool to work with.
Currently we are finishing a Unity project, the next one could be UE4 based, but so far I am wary of the current state of the editor. I had 2 crashes with 4.8.1 last evening on a very simple test project (3 actors and 3 blueprints).
So at this point stability seems to be a very real issue.
I don’t know if this has been mentioned on the thread, but here is a pretty game-breaking bug that prevents my team from moving to 4.8 at all. So hopefully it will get fixed in 4.9 or sooner. It basically makes blueprint default values useless in our packaged project, forcing you to set the default values one by one using Set nodes instead.
This one is another bug that is present since 4.8 and breaks the game for people who are using solid black backgrounds (makes it grainy). Personally, I find the ‘new’ bugs that were not present in the previous versions the most annoying. 
[=Conkerballs;335652]
People should know that it is not a mandatory thing to update to the newest engine every time it comes out. If you find a certain version is the most stable for your project you should continue to use that.
As you guys are saying as a genuine thing you prefer stability over new features. Epic is offering this, don’t update. Copy your project to the new version have a test, if its not viable revert back to your old project.
Do you think games like ARK would update to the newest version every time? Nope, they would stay on what was the most stable version for their game. Understand Epic’s model is, release to the public (We are the best debugging tool to epic) and subsequently patch and bug fix the bugs you find. Obviously they stomp the majority of bugs in house first.
If you want to make the future versions of UE4 stable, bug reports need to be submitted for these ‘Massive’ amount of bugs people are having. We owe it to the engine as users.
[/]
While it is 100% true that you don’t have to update, the issue is that after one hotfix, past engine versions are no longer supported in the sense that when you ask for help on answer hub the answer is “It’s fixed in the upcoming version” or something similar. I recognise that for game dev shops that have multiple people, they can just patch the bugs they find for themselves and stay on a single engine version till they release. Some of us don’t have the resources to fix game breaking stuff ourselves so we have to rely on the updates epic provides which means porting our work to new engine versions.
[]
This one is another bug that is present since 4.8 and breaks the game for people who are using solid black backgrounds (makes it grainy). Personally, I find the ‘new’ bugs that were not present in the previous versions the most annoying.
[/]
What do you plan if you keep having blocking bugs ? Why not staying with your working version prior to 4.8 ? (they did the same with ARK game)
[=Conkerballs;335652]
People should know that it is not a mandatory thing to update to the newest engine every time it comes out. If you find a certain version is the most stable for your project you should continue to use that.
As you guys are saying as a genuine thing you prefer stability over new features. Epic is offering this, don’t update. Copy your project to the new version have a test, if its not viable revert back to your old project.
Do you think games like ARK would update to the newest version every time? Nope, they would stay on what was the most stable version for their game. Understand Epic’s model is, release to the public (We are the best debugging tool to epic) and subsequently patch and bug fix the bugs you find. Obviously they stomp the majority of bugs in house first.
[/]
problem is many features come as experimental (or even just come broken) and don’t get usable until the next major release(es). you can only ever lock yourself from new versions if you find a version that has all the features you need in the scope of your project and if in that version all those features work properly in addition to stability. I’m sure there’s not a release that fits this criteria for the majority of people. the engine is just not mature enough.
if you lock yourself to a version it basically this means that if something is broken for you it will remain broken
some new features are also critical or important to have and cannot just ignore them. even ARK needs to update to 4.7 because of the foliage optimizations.
[=;335597]
I would really like Epic to optimize the engine as well. Currently, foliage rendering is still lacking, shaders are too expensive, and overdraw is a huge issue when using foliage.
[/]
Agreed, I hope they do something about this instead of constantly adding new things
[=;338409]
even ARK needs to update to 4.7 because of the foliage optimizations.
[/]
Actually they don’t. That’s the beauty of the whole github versioning system. They can stay on 4.5 / 4.6 (or whatever their original version was) and just implement the changes they need.
[=CodeSpartan;338299]
I don’t know if this has been mentioned on the thread, but here is a pretty game-breaking bug that prevents my team from moving to 4.8 at all. So hopefully it will get fixed in 4.9 or sooner. It basically makes blueprint default values useless in our packaged project, forcing you to set the default values one by one using Set nodes instead.
[/]
Yeah, I’ve mentioned about this one on the previous page - well, all we can do is wait and keep our fingers crossed.
[=;338537]
Yeah, I’ve mentioned about this one on the previous page - well, all we can do is wait and keep our fingers crossed.
[/]
Yeah, that is true.
But even though I know that you are right, it is exactly this “waiting and keeping fingers crossed” can become quite discouraging sometimes
[=;338472]
Actually they don’t. That’s the beauty of the whole github versioning system. They can stay on 4.5 / 4.6 (or whatever their original version was) and just implement the changes they need.
[/]
backporting features? that’s much easier said than done.
if they’re on 4.5 or 4.6 maybe it’s not that complicated, but the more time passes between your version and the current one backporting stuff will become more complex or even not doable
[=;338557]
Yeah, that is true.
But even though I know that you are right, it is exactly this “waiting and keeping fingers crossed” can become quite discouraging sometimes
[/]
Indeed… BTW, it would be nice to have some kind of public bug tracker to be able to see the progress of fixing certain bugs. For now, all we have is a magic number… And some fingers to cross 
I also agree on a stability focused upgrade. Every time I try something new with the engine I somehow manage to crash it without any information on what went wrong. Lately I’ve been trying to learn how to use the online subsystem, but whenever I try to find a session twice in a row it crashes without telling me why. I also tried the MoviePlayer system, but that has strict requirements on what it supports which was a total hassle to figure out. I also finally found the option to separate the keyboard and first gamepad for players one and two respectively under Play->Advanced Settings when really it should be under Project Settings -> Input.
During this hypothetical stability focused upgrade, teams with no major bug fixes could instead focus on the sorely lacking documentation for major engine features.
[=;338565]
Indeed… BTW, it would be nice to have some kind of public bug tracker to be able to see the progress of fixing certain bugs. For now, all we have is a magic number… And some fingers to cross
[/]
Yes that would indeed help a lot. Epic has promised that a few times already, IIRC even in this thread …
So I met Golding at Develop last week and we had a chat about stuff like this. The first thing he mentioned (which I agree with), was that locking features makes zero sense. It’s practically impossible to have all of Epics engine team focus on stability. There is no feasible way to achieve that, especially when you consider that most of the Engine team have their own specific areas to focus on and delving into other parts of the engine could create more problems than it would solve. It’s also incredibly inefficient in the long-run, because there’s no reason to fix old buggy code if you have the ability to replace it with fresh new stuff. For example, there will never be a hardening pass on Matinee, because Sequencer is in the timeline and will eventually replace it.
The second thing that mentioned was that the process for Epics releases has changed somewhat since it first started. It used to be that a release date was set and if stuff could be crammed in, it would be - hence we had a lot of hotfixes in the Early days. 4.7 was quite a bumpy release with a total of six hotfixes because it followed the same release strategy.
Since , that has changed. The combination of people requesting focuses stability and the ever-increasing bug tracker means that they now try to put a clamp on features a month or two before the intended engine release, and do some hardening on the old and new features and make sure that the amount of bugs in the goes down instead of up.
This is the right way to go, spend the majority of the time iterating on the Engine, harden it towards the release date. It hopefully also means less crunching for the engine team and more releases like 4.8, which so far has been really good (only two minor hotfixes so far, with no major issues that force anybody to wait until 4.9 or get Master, unless they want to play with new features). There is ALWAYS the option to go and fix the engine bug yourself if you really can’t wait - something you don’t get with any other engine on the market.
Obviously don’t go harassing the G for info on this, I’m just the messenger of the messenger
Thanks for this information. Nobody will be harrassed, more feedback is always welcome 
So in my personal opinion what bugs me most is that some bugs are not being fixed for months or even a year, even though multiple people report it (see many of the examples in this thread). I understand that the dev team at Epic is not interested in a full feature-freeze and just bug hunting for months. However, there are things that are more than just cosmetic issues, but still they are not being addressed.
My view is that while Epic works on new features every release, they have to take their time to fix those many open bugs, some of them are quite severe. What I said before is still true for me: I don’t need most sophisticated new features, if I cannot use the old ones!
[=Galeon;338386]
What do you plan if you keep having blocking bugs ? Why not staying with your working version prior to 4.8 ? (they did the same with ARK game)
[/]
Prior to 4.8 if the player had an uppercase russian or polish letter in their PC name (about 40% of people from Russia and do), the game would crash every time when connecting to your dedicated server. That’s one of reasons why we want to port to 4.8, and yes we are staying with 4.7 for now.
[]
Yeah, I’ve mentioned about this one on the previous page - well, all we can do is wait and keep our fingers crossed.
[/]
Seems like it got fixed :Danswers.unrealengine.com/questions/245367/variable-reset-after-packaging-demo-project-includ.html
As outdated versions don’t receive any bugfixes (even critital ones), upgrading is usually the only option.
And : I really don’t know why the number of released hotfixes should be an indicator for the quality of the release. In 4.8 VR Support is completely broken (and was left in this state). Leap Motion support? The same. Why is simply not releasing fixes for critical bugs introduced in a new major version a good sign in any way?
Hotfixes are a good thing. The really annoying things are horror bugs which were fixed weeks ago internally, but are simply not released.