After 4.8, my project ‘work distribution’ went from | 40% working on game / 60% figuring out workarounds for bugs | to around | 70% working on game / 30% figuring out workarounds for bugs | so in my case it’s getting better, but there’s still a lot to do with stability and bug fixing. I get ~5 crashes a day by doing basic things like opening blueprints or dragging them into scene. Of course i report everything via post-crash window and i report any bugs that i can recreate to AnswerHub, but this 4.9 bugfixing, stability & optimization focused release is a really important thing. ‘Good stability and little bugs’ is also a feature. I hope Epic will understand us in this case 
[=;318426]
History shows that adding new features tends to break existing code… So why not go all out for adding features for the rest of this year and maximize stability in 2016?
[/]
You would end up with a completely broken Engine nobody would use for production. 1000 features which bail out every 5 minutes are completely useless. Till 4.7 I spent about 80% of my time on detecting and workaround engine related limitations and bugs. Because of all the Issues I haven’t even attempted to work with 4.8 yet, as 4.8.1 was just released I will now try to dig a bit deeper. If you want to dedicate 6 Months to just throw features in, you should have a very stable release first, so people may use this for production - I don’t see UE4 at this point at the moment.
So I do forward the demand for a stability release, there are of course very high priority “core features” which are missing for long, and should be implemented as well.
The idea is good altho i find way less bugs in ue4 than before. I would like to see more focus on the 2D tool set. Skeletal animations could be very important part of many people’s next game.
Fix the current bugs before adding more bugs!, please, think that it can Save a lot of our time finding workarounds.
I also fully agree with the OP (and many others in this thread) that UE4 really needs a stability release rather than super-fancy cutting-edge features every single month. It’s great to have awesome graphics and stuff, but what good are all these shiny features if basic tech does not work?
Also I don’t understand the bug fixing policy at Epic. There are some bugs that have been reported months ago, Epic replies with something like “Thanks for the bug report, bug UE-xyz has been recorded, we’ll get back to you.” And nothing happens. Why isn’t Epic just addressing those bugs? Here are some examples:
- Custom mouse cursors have been buggy for months, and HW cursors are not even supported yet
- Reimporting FBX models does not work without issues
- Gameplay Developer Tools (GDT) do not work on non-US keyboards (see end/bottom of that link)
This list goes on and on, just have a look at the answer hub and this forum for more examples. Obviously not every bug is a game breaker for anyone, but some of them are more than just annoying and need to be fixed, no matter what.
And that brings me back to my original question: What is the bug-fixing policy at Epic?
- Why would I need procedural foliage systems if I cannot even reimport FBX models?
- Why would I need advanced EQS for my AI if I cannot even use basic AI debugging features?
- Why would I need fancy rendering capabilities if I cannot even render a custom (hardware) cursor?
I really do like UE4, and I want to use it. We have committed our to UE4, and it would be a disaster for us to switch to another engine at this point. However, having to spend half of our dev time to find, identify, report and work around bugs is really bad for our mood. It doesn’t make our devs want to work with UE4, which is quite sad 
TL;DR – We fully support the idea of something like a “maintanance” release in 4.9. The most sophisticated and shiny new features are of no use if the basic features don’t work reliably or at all.
Second that!
You run too fast from feature to feature with rather short legs, that is not enough employees.
At this point, such a release would really make sense. Or the answer hub never relaxes to less than 1 question per minute.
Same here with UE-16448answers.unrealengine.com/questions/234834/nav-link-proxy-smartlink-functionality-doesnt-work.html
NavLinks are something what was here and working since first version and now it is broken. It is gamebreaking bug for me, so I need to stay with older version. It is probably some minor bug in code and just because of that I need to skip version 4.8 because Epic includes mostly only crash fixes into hotfixes. I can just hope that there will not be some other gamebreaking bug in 4.9 because I would need to skip that version too…
From what I see 4.9 will be common build and it will not be just about super stable build, so maybe it is good to start requesting 4.10 as super stable build with fixes only. (4.10 is much better name for special update, heh)
Anyways, I enjoy UE4 and I hope you hear as and find some solution.
I really really want to see Light Propagation Volumes in production stage with 4.9 version. Epic! Please please, do this for us! Please, let the lightmap go to the past
I have already expressed support for this idea, but there is another example of current ‘not-so-good’ state of UE: Just in my case, two game breaking (the first one resets many variables after packaging, the second one crashes game every time) bugs that I’m waiting to be fixed. In both cases many users encountered these bugs, and in both cases I’ve created a simple repro-demo project, so I hope it will help to fix it soon. So currently I’m blocked for packaging my game (at least I can work on other game elements) - and the only thing I can do is wait, keep my fingers crossed, and send some good energy to Epic, along with bug reports 
[=;334577]
I have already expressed support for this idea, but there is another example of current ‘not-so-good’ state of UE: Just in my case, two game breaking (the first one resets many variables after packaging, [URL=“Animation crash [Demo project included] - Character & Animation - Epic Developer Community Forums”]…
[/]
Could not you just explicitely set the variable to at the beginning of your code/blueprint rather than relying on the default tab? That’s how I do it at the beginning of code/blueprint, there is one big Do Once Macro that initializes every variable and I put numbers/names in there and not in default.
[=;334625]
Could not you just explicitely set the variable to at the beginning of your code/blueprint rather than relying on the default tab? That’s how I do it at the beginning of code/blueprint, there is one big Do Once Macro that initializes every variable and I put numbers/names in there and not in default.
[/]
The one is just an easy example I have a typical object-oriented structure of classes, for example Unit <— Human <— Bob (‘<—’ == ‘derives from’) . I have a lot of NPCs like, so setting unique name, statistics, texture/model variations, etc. of every NPC through Begin Play would be… Not so efficient, but ofc it could work as a workaround, so thanks for the hint. Same class structure for Skills, Items, etc… The way it should work (and it’s intended to, but currently there is this bug) is to easily set variables in Defaults (so you don’t even have to open BP graph, BPs like that open in data-only mode) for every new child class.
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.
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.
That makes sense but somewhat misses the point. There simply isn’t a stable release (by most reasonable standards) of UE4 available. Big teams (like for ARK) would stick to one release but no doubt make their own branch of the engine source, which would include merging in bug fixes from newer Epic releases as needed. Most small teams don’t have the time or expertise for that, so the reason people feel they need to upgrade is because it’s the only way for them to get fixes to major existing bugs. Not because they just want all the new features.
This won’t change any time soon if Epic continue to add so much with each release without merging bug fixes back into an earlier release version.
double post
[]
This won’t change any time soon if Epic continue to add so much with each release without merging bug fixes back into an earlier release version.
[/]
Quality have improved a lot with 4.8, there was also a complete twich event with Epic devs talking about their new methodology about bug fixes and releases branches.
Big releases is needed , Unreal 4 is on the AAA competition arena, they must enhance the engine as much as possible each release unlike Unity that is not targeting AAA level.
You are working with a professionnal AAA engine that is not static and progressing quickly, perhaps you should ask yourself if some engine tagged “indie” with slower releases like one per year would be more appropriated for you.
[]
perhaps you should ask yourself if some engine tagged “indie” with slower releases like one per year would be more appropriated for you.
[/]
is inappropriate condescending nonsense
[]
There simply isn’t a stable release (by most reasonable standards) of UE4 available
[/]
agreed with this
4.8 was a huge step in the right direction, still a long way to go though
[=Galeon;335833]
Big releases is needed , Unreal 4 is on the AAA competition arena, they must enhance the engine as much as possible each release unlike Unity that is not targeting AAA level.
You are working with a professionnal AAA engine that is not static and progressing quickly, perhaps you should ask yourself if some engine tagged “indie” with slower releases like one per year would be more appropriated for you.
[/]
You’re right, it’s a business and they need to stay competitive, but on the other hand, it shows how much AAA standard has degraded nowadays: Now “professional” and “AAA” means “less stable, full of bugs, but with a new, shiny paint”.
… Just a thought.
[=Galeon;335833]
Unreal 4 is on the AAA competition arena, they must enhance the engine as much as possible each release unlike Unity that is not targeting AAA level.
[/]
Fair enough, only Epic have made it very clear with their recent decisions regarding where they are taking the engine, that they want to make it as widely available as possible. Given that, it seems reasonable to expect that they’d make a decent effort to have a stable release build that small teams can rely on without having to modify the engine source. I’m not against new features, I just think that they could be kept in the master branch a while longer, leaving more time to fix bugs in the release branch - those who need the new features most likely have the resources to maintain a source build and merge them into it as they see fit.
[=;335796]
That makes sense but somewhat misses the point. There simply isn’t a stable release (by most reasonable standards) of UE4 available. Big teams (like for ARK) would stick to one release but no doubt make their own branch of the engine source, which would include merging in bug fixes from newer Epic releases as needed. Most small teams don’t have the time or expertise for that, so the reason people feel they need to upgrade is because it’s the only way for them to get fixes to major existing bugs. Not because they just want all the new features.
[/]
Fully agreed on that.