4.7 -> 4.8 conversion quality assurance insufficient

General Feedback & Requests
1

Not sure, but maybe it is possible to keep a better eye on backwards compatibility between versions.
I just spent three entire days retuning my project, that I worked on for many months, after switching to 4.8.
It is really big, and it takes a lot of time to discover things like ‘generate overlap events’ and so on being switched off after conversion for some actors.
Effectively, you have to do an entire beta-test again to discover any potential conversion flaw with a conversion like this.
Not to mention physics being completely different.

I perfectly understand why the Ark Survival guys were still on 4.5.
It is really high risk for a large project to update with sloppy conversion stability like this.
If it is like this, you have to run the entire beta tests again, all basic things, because you can not rely on clean conversion.
I know you are just a small company and other engines have more testing people and developers at hand, but please be more careful next time.

3

I get where you are coming from and not trying to be offensive but switching to unity because a new UE4 version breaks compatibility… doesn’t make any sense man! :D… you can always stay in 4.7 (that’s kinda what you are supposed to do when your game is far in development), or are you are saying that 4.8 has a magical new set of features that every game absolutely needs to be further developed?

Besides UE4 has a much more rapid development cycle (every UE4 release is HUGE, from what I have seen it doesn’t even remotely compare to unity) which means you get tons new features each time (but with the added risk of breaking compatibility).

But don’t get me wrong, I absolutely agree that this is a problem and Epic needs to be more careful (like a LOT more careful) with backwards compatibility and properly document any potential compatibility-breaking changes, give us alternative code, examples, how should we go about this now etc… for example lots of internal changes were made with physx, destructibles, overlap events etc. and there is literally no details about any of that in the 4.8 changelog! :stuck_out_tongue: not cool… the changelog is in many cases more like “titles” of the changes rather than actually explain the actual changes.

The behavior on one of my games changed completely because of couple of changes and took me forever (well okay not that long ;)) to understand what runs different and why.

I mean thank goodness for and his transition threads which can help with some of that (I seriously have no idea what the community would do without this guy at this point :p) but this shouldn’t be the responsibility of the community though… at least hire the guy or give him a grant or something :rolleyes: just saying.

4

[=MaZi1;315841]
Not sure, but maybe it is possible to keep a better eye on backwards compatibility between versions.
I just spent three entire days retuning my project, that I worked on for many months, after switching to 4.8.
It is really big, and it takes a lot of time to discover things like ‘generate overlap events’ and so on being switched off after conversion for some actors.
Effectively, you have to do an entire beta-test again to discover any potential conversion flaw with a conversion like this.
Not to mention physics being completely different.

I perfectly understand why the Ark Survival guys were still on 4.5.
It is really high risk for a large project to update with sloppy conversion stability like this.
If it is like this, you have to run the entire beta tests again, all basic things, because you can not rely on clean conversion.
I know you are just a small company and other engines have more testing people and developers at hand, but please be more careful next time.
[/]

Hi

Unfortunately, this is something that is always a possibility when converting between engine versions and is why we highly recommend sticking with a single version unless you need to update to a more stable build or the new build has features that you need to work with. There is a possibility of corruption between engine versions, workflow changes may occur, or new bugs could potentially be introduced that can cause an unknown number of errors. Upgrading every version in a main project is always a risk with software that is under active development. If you do convert to the next version, always ensure that you make a copy of your project as opposed to converting in place to ensure that, if there is a problem, you have a way to backtrack to a stable point. Additionally, please make sure to report the bugs on the answerhub (http://answers.unrealengine.com) so we can address them as quickly as possible.

[]
4.8 Is what finally drove us away from the engine for the type of game we are creating. It had a slew of bug fixes and features that were necessary for our game, but would require us to essentially re-do 6+ months of work. The inconsistencies between PIE, AMI, and the cooked version were just to insane.

Unreal seems like it is a perfect choice for larger titles that have the resources to lock into a version, and a team that can pull bits of the repository to fix what they need. It also seems like if you are sticking to the “Unreal method” for physics and pawn interaction, PIE/AMI behave correctly.

Unreal is not acceptable for any other type of smaller game that breaks those rules, nor is it really all that great for 2D. We ended up switching to Unity, and bypassed our progress in Unreal within days.

Edit: Please know, I am a huge fanboy of Unreal and Epic, it really bugs me to say this. Unreal is a wicked awesome tool, it just wasn’t right for our needs. Epic is epic.
[/]

I’m sorry to see you go, , though we certainly understand that you need to use the tool that is best for your project. Hopefully we’ll see you in the future when the engine better suits your needs. Is there anything in particular that were trouble spots for you or that you think we could do better? We’re always willing to hear suggestions on what we can do to deliver a better overall experience!

5

Sometimes you have to update for key features, for example 4.8 allows for the first time to ship in 64bit.

I agree that the change log should contain more explanations. It is only a titles collection - for example PCM for physics.
I know this comes down to the developers. If they do not do it, all the non-dev guys are helpless. Some time ago it was mentioned that you have ‘Epic Fridays’ where everyone can do/try what they want. Make those really epic and make all developers write docs and code examples of what they do! See Unity API code snippets in their doc.
I am a bit afraid UE4 will never reach such a well documented state, because I do not see the time coming where you slow down a bit between versions and take your devs for a few weeks to actually document what you are doing.
Unity and other engines employ much more people, so it might be easier for them, but in your case it makes little sense to add and add with many users who potentially make a game that brings you revenue actually shying away from updating. I would happily pay a subscription fee to see more resources and a better documentation as a result. Anyone who goes for a revenue generating and larger game would. I am sure the ARK guys would. Documentation and stability/reliability is what makes the difference between freeware and paid-for software after all.

6

The problem with the advice of “stick with 4.7” is that this is a fine recommendation if 4.8 isn’t a big deal… But what about next month when 4.9 comes out? Or two months later when 4.10 comes out? What if one of THOSE engine versions finally fixes a bug you’ve been trying to work around?

Unless 4.7 is totally perfect for your project (and let’s be honest, that’s the case for approximately 0% of users) it’s a huge mistake to hold off upgrading because when you finally DO, ALL of those accumulated break-and-fix moments occur at the same time, and the whole process becomes infinitely more painful as a result.

So that’s easy talk to talk but it doesn’t change the reality of more or less needing to upgrade if there are any major bugs or important features even remotely visible in the pipeline for the future.

8

Thanks for the list , really interesting to read!

I guess UE4 is just not yet a good choice for a 2D game. Epic is working on improving the paper 2D stuff, but Unreal Engine was never really designed to be used in 2D games in the past I think, so it might just take some more time until UE4 is nice to use with 2D.

I did never had really big problems with the conversion from one version to another. There were some issues, for example my AI worked in 4.7 and stopped working in 4.8, but only because I relied on the behavior tree to continuously runing after unposessing the pawn and posess a new pawn. In 4.7 it worked and in 4.8 it did not, but as always I wrote a bug report and until now I never have gotten no assistance on bugs from epic. So after 1 or 2 days Miezsko explained to me that this is actually intended and that it worked in 4.7 was wrong, but he will add a bool to tick to get the old behavior. Until this is added I can just workaround it, some hours of work, but not days or weeks, and the workaround works fine now for me. When it comes to AI, Mieszko is always there to help, he is awesome :slight_smile:
Another problem from 4.7 to 4.8 was that updating Instances stopped working, but after some hours I found out that there is just one wrong default bool which I have to tick and then everything worked again.
The worst issue I got with 4.8 is that destructible meshes now can’t get hit by a trace in the frame they were spawned, which worked fine in 4.7, I have not yet found a solution to workaround it, delaying the trace one frame should work. The bug is only the worst new one because it will probably not getting fixed because destructible bugs are backlogged, so introducing new bugs which won’t get fixed is of course a problem.

But all of these problems were reviewed by Epic really fast on the answerhub, I generally never experienced that Epic ignores bug reports. Some bugs never seem to be get fixed, but they always get looked at from Epic on the answerhub within some days. You can look at my profile on the answerhub, I have around 50 bug reports there and even more where I not myself asked the question but continued the discussion in existing threads. I always got really nice support from Epic.

So I can’t really comply too much, although I have already done it enough in various threads :wink: Yes UE4 is buggy and I absolutely hope they will do something like a 4.9 which is mostly only focused on stability. I also really would like to pay 20$ a month for supporting Epic. But I have not noticed any difference in the support from before GDC 2015 and after. Support from Epic was always really, really, really good. There are so many really great guys working at Epic and helping us, this alone is already enough for me to not even think about switching to Unity.

I just hope I will ever be able to ship a game with UE4… At the moment the problem is just that I sometimes feel as if more new bugs get introduced than getting fixed. One single bug can be enough for not being able to ship a game, because it breaks stuff that is just needed. At the moment there are still at least 4 of these bugs in UE4 which makes it impossible for me to ship a game. One of these is that my game just crashes after being packaged, but that’s most probably fixed in 4.8.1. Another one is flickering trees, I can’t ship a game with trees which flicker once a second. Another one is the drastically decreasing performance after a certain amount of destructible meshes is reached, and another one is artifacts coming from drawing lines in UMG. This will also be fixed in 4.8.1. So the ones not getting fixed are flickering trees and destructibles, and both are “backlogged”, so it might take 2 years until these are fixed. So I might need to wait 2 years until I can ship my game. Yeah, that’s a problem, and that’s why I hope for 4.9 being a bug squashing release.

9

[=;316678]
and another one is artifacts coming from drawing lines in UMG. This will also be fixed in 4.8.1.
[/]

Nope, I told you it was 4.8.2 on AnswerHub :stuck_out_tongue:

10

Yeah thanks , does not matter whether 4.8.1 or 4.8.2 :cool: The only important thing is that it get’s fixed :slight_smile:

11

[=;316655]

We would spend DAYS wrestling with the physics system, only to find it acted completely different once compiled, and completely different from that once cooked.

[/]

I am pretty sure they attempted multi-threading with 4.8, but not very successful.
As a result, the physics are completely backwards-incompatible now.

See here about PhysX 3 and multithreading/performance
https://www…com/watch?v=ZtcAOQv9GWs
(starting 38:00)

Unity got it working, but they have Anthony. Epic does not have Anthony, so there are a few guys trying, but with less success.
You can see ‘asnyc’ everywhere in physics related tabs now in 4.8 and it refers to the asynchronous scene, i.e. multi-threading.
I just switched off everything that is new in the physics tabs to have it half-way working. For example, if you constrain two bodies, and one is in async, then they fall apart.
Even with all new things switched off, spring forces are different and all that.
They should not release something in that state. It is not release ready, if you convert 4.7 -> 4.8 and your project is completely blown apart.

[=;316655]

I want to pay! Damnit, it means a better engine, I WANT TO PAY. Epic, I want to give you my money. I want to feel like I have the right to complain about issues, but our team ends up keeping it internal and trying to play whack-a-mole with the bugs. Those that can’t afford $20 can’t afford to develop a game. The minute Epic went free with Unreal, the support I was getting vanished.

[/]

Same here! Maybe make a basic support subscription or similar, along with the free non-support version.

I can not say for sure, because there are many variables involved, but the moment Epic went 100% for free, could as well have been the beginning of the end for them and a bad lomg-term management decision.
There are for sure huge numbers of beginners attracted by this. They will ask huge numbers of questions and will completely flood the Epic human resources (see answer hub madness -> it is not going to stop). The result is a really stretched thin Epic. As a result of that, there will be less quality. The thing is, the huge number of beginners will not generate revenue, and teams who potentially make it to steam or wherever will go away because there is no basic reliability/stability in the engine anymore and/or you have to battle with very basic things that come essentially on a silver plate and as one-liners in other engines.
I think it all comes down to company size and what you can do with it. Epic has only 100-150 employes, Unity ~500, Crytek ~ 500 and AAA companies many more. This is why you could bypass 6 months of UE4 in 7 days in Unity, TheBritain.
Essentially, with such a small number of employes, you can not stretch as thin as Epic is doing. It will backfire.

12

made a good post there, all stuff worth taking on board! A lot of it like the Large API that Unreal has and the use of Visual instead of Mono or other compilers probably isn’t stuff that’s easily fixable, but in terms of use-ability there’s a lot of good info there that can be used I think.

I have to say I agree on the sentiments of the File Management system. The redirectors are horrible to work with, especially when your project is maintained with Source Control, you end up with hundreds of 1-4Kb files left behind every time you delete or move something, which isn’t helpful. The only way around it is to go into explorer and (carefully & painstakingly) delete the files manually, then re-open the Engine and fix all the reference errors. Usually, that’s quite a long process.

In terms of Comment 15 - what part of the Spawn Pawn system is the problematic part? I’ve not had too many issues with it so far in honesty - though it was difficult to set-up a reliable system for spawning players as DIFFERENT pawns. Eventually got it working but not in the way I’d like. Unreal Tournament has a system for that now, but UT’s source isn’t very well documented or commented so it can be hard to follow at times.

In terms of the issues of updating between Engine Versions, that should really just be expected. The problem with keeping backwards compatibility for everything is that you end up with a messy codebase with a mixture of the old and new, and even bigger Engine sizes. It’s just not worth it, and that in turn also decreases engine stability as well. It’s far easier for dev teams to spend a month upgrading their project should they have to.

I keep having to say this to people, but you should NEVER instantly upgrade your working project when the Engine releases a new build. Always wait for the first hotfix at least, and when you do it, create a Branch in your source-control provided of choice and upgrade slowly. When you’re happy that the game is stable, move everybody over to work in that branch. This isn’t anything unique to Unreal, this is pretty much industry standard. Otherwise, you’re effectively stating that you trust 100+ engineers that know nothing about your project, to make a huge upgrade to your codebase.

I also don’t believe Epic would switch back to a subscription model now that Free has been done. A lot of people who feel entitled to all these free tools would start kicking off and boycotting it (meh, good riddance) - but the main reason behind going free is to just get people using the Engine. The more freelancers and indies use the Engine, the more big studios will eventually have to front the money for the proper engine licensing (24 hour tech support, in-house engineers etc). Of course, a lot of those studios are actually developing their own engines as well. Ubisoft, EA, Naughty Dog etc. all have their own tools respectively. Anyway I could start raving on about that aspect of the industry but that’s for another topic…

I didn’t have an issue with the £19 a month either, it was still a bargain either way.

13

I agree it’s not reasonable to expect continuing backwards compatibility between versions. The problem with saying we should just lock in to an existing version for the remainder of a project, though, is that as yet I don’t think there has been a sufficiently stable release. As was said above, most of us don’t have the resources to fix bugs or shortcomings in the engine ourselves. So people are effectively forced to upgrade in the hopes that the latest release will sort out the issues that are preventing their project from working; not because they just want to take advantage of new features.

If there was an engine version where all major issues with its core features were resolved to a reasonable point, then I think people well into their project would happily stick to it. But as has been said many times, this is never going to happen when every major release comes with a slew of new features which will inevitably introduce new issues and knock on effects with existing features.

Rather than designate a version as a bug fixing release, I’d suggest Epic designate a version as a stability oriented one and continue to focus on stabilising it even as it is superseded by subsequent versions. I think that’s the only way we’ll get to a stable version while still allowing new features to be constantly added to the engine for those that want them.

14

[=MaZi1;316923]
I think it all comes down to company size and what you can do with it. Epic has only 100-150 employes, Unity ~500, Crytek ~ 500 and AAA companies many more. This is why you could bypass 6 months of UE4 in 7 days in Unity, TheBritain.
[/]

Really? How can this be? :confused: Why does Unity have 4 times as much people working on compared to Epic? I thought it would be the complete opposite… I mean, Unreal Engine 4 is far more advanced than Unity (Unity is not really called a AAA Engine), Epic is also working on 2 games and not only UE4 while Unity only works on their Engine, Unity uses a ton of middleware for everything while Epic tries to make most features completely themselves (so that they can share the source), and generally UE4 is advancing faster than Unity as far as I can tell. What are Unity’s 500 people working on?

15

[=MaZi1;315841]
Not sure, but maybe it is possible to keep a better eye on backwards compatibility between versions.
I just spent three entire days retuning my project, that I worked on for many months, after switching to 4.8.
It is really big, and it takes a lot of time to discover things like ‘generate overlap events’ and so on being switched off after conversion for some actors.
Effectively, you have to do an entire beta-test again to discover any potential conversion flaw with a conversion like this.
Not to mention physics being completely different.

I perfectly understand why the Ark Survival guys were still on 4.5.
It is really high risk for a large project to update with sloppy conversion stability like this.
If it is like this, you have to run the entire beta tests again, all basic things, because you can not rely on clean conversion.
I know you are just a small company and other engines have more testing people and developers at hand, but please be more careful next time.
[/]

I’m doing the same thing. I took a look at 4.8 and my game had several issues. Being so far into development and looking to release in August, I believe I’m going to stick with 4.7 because when switching, there could be an issue that creeps up when only certain actors interact with each other. I did notice that the physics change some too. Again being so far into the game, these things change the whole feel of the game once levels are designed around specific settings. Love the features but I think I’m going to have to wait til my next project to utilize the new engine features. Converting from 4.6 to 4.7 wasn’t to bad for me. I do believe that UE4 is at a point where you can take a build and stick with it and develop with the tools available. There’s plenty to work with.

16

[=;317213]
What are Unity’s 500 people working on?
[/]

Look into TheBritains post. He did in 7 days what took him 6 months UE4. That’s what they are working on.
Unity is coding their engine for users, not for themselves. It takes resources to not just code something, but also prepare it to be user-friendly and to be served on a silver plate.
In UE4 you sometimes think it is the opposite with things like: ‘Sorry, but we are busy with our games. Here is the source code, fix it yourself… go away’
The source code availability is nothing more than that.

19

The problem with staying on a single engine version till release is that bug fixes are pushed out in later versions and the answer you generally get on the answerhub is ‘this has been fixed in version x’. SO yes, you can stay on whatever version you started with but for all intents and purposes it’s no longer being supported as soon as the next version comes out.

There was a thread on here a while back with talk of doing bug fix oriented releases every so often, I’m not sure what became of that but in general there’s got to be a better approach than the current one because it’s really a catch-22 for small devs right now.

20

I had issues upgrading my products to 4.8 also. One of which is waiting for a bug fix before making the upgrade. New bugs are the worst, it feels like going backwards. But I know that it gets fixed in time. Just have to be a bit patient (for those that can).

Setting up animations for 2D is a pain(when you have many, many). I basically had to make a custom actor called “Animation Master” that handles all of the character animations a bit like a state machine. The cool thing is that I can now just drag and drop my flipbooks in there and easily have many unique characters this way. And setting up the sprites wasn’t an easy feat either. Though now with the help of the property matrix and a bit of know how, it goes pretty fast(Still very tedious).

I still haven’t had problems finding specific frames in my animations though. For example, when I run and I start shooting, I can set the new run/shoot animation at the same frame that the run animation was in no problem.

Really interesting read/comparison. I am confident that UE4 will only get better in time especially where indie developers are concerned. It’ll get there.
Glad to hear that you got back on track with your project though, I’m looking forward to trying this Pony Smash :smiley:

21

Here is another reason to upgrade:
I just wanted to continue and none of my 4.8.0 projects opened Editor windows anymore. In the taskbar the editor windows showed up white with a small UE4 logo in the middle - nothing more.
I just removed 4.8.0 and now I see only 4.8.1 is available. Great! God knows what is going to happen again! I could really bite into my keyboard right now. You guys really know how get the best out of people. Phew, this is really not cool…
Here is something for the kite flying ‘upper management’ of your 100 something people ‘I am for free’ enterprise.

https://www…com/watch?v=8To-6VIJZRE

22

[=]
Here is another reason to upgrade:
I just wanted to continue and none of my 4.8.0 projects opened Editor windows anymore. In the taskbar the editor windows showed up white with a small UE4 logo in the middle - nothing more.
I just removed 4.8.0 and now I see only 4.8.1 is available. Great! God knows what is going to happen again! I could really bite into my keyboard right now. You guys really know how get the best out of people. Phew, this is really not cool…
Here is something for the kite flying ‘upper management’ of your 100 something people ‘I am for free’ enterprise.

[/]

Hi

Hotfixes are designed to address specific bugs and crashes that are affecting large numbers of developers, and do not introduce any new features or functionality to the engine version itself. This is not a full version release but fixes to known issues in 4.8. Here is the hotfix information page if you’d like to see what is in this hotfix:

4.8.1 Hotfix is live! - Announcements - Epic Developer Community Forums!

If you run into bugs or crashes, it is best to post these on the answerhub so we can assist you more in depth with the error. You can do this in the bug reports section of the answerhub at http://answers.unrealengine.com, as we do prioritize this section over other areas of the answerhub.

23

Here is a nice example of how to make things much more difficult and error prone, especially in upgrading, than Unity.

I just got another one of the ‘failed to find variable property’ errors in 4.7.
Googled and one of the replies on answer hub was this:

‘Is your Helathbar a component, or an Actor?
Trying adding a ChildActor Component, and then set it’s Actor to your Health Bar. When using it, get the ChildActor, get it’s Actor, then cast it to your health bar.
Also, did you try dragging off from your HelathBar component onto the graph?’

The reply is like: from start take a left, then a right, then a right. Here is the path in Unity: from start take one step forward.
6 months vs 7 days! 100 employees vs 500 employes.
How can you publish an engine that is so twisted to users?
I mean you try and you are nice people and everything, but I need a break here. Do not take it personal or something.

25

Semi related question…

I noticed that 4.8 brought an A-pose skeleton for epics standard skeleton, a bit of a pain with retargeting stuff from old projects, but on that note, are animation packs and characters being sold on the marketplace going to remain T-pose?

Another question, if anyone has tried (I haven’t had the time) Does the new epic A-pose skeleton have better compatibility with Mixamo characters? I know the T-pose was not very good!

A bit lost now, as there is both T-pose and A-pose stuff floating around, no longer a single standard skeleton.