I’m completely at loss here. When opening my project in 4.6.1 (source build), I am greeted by a metric ton of blueprint compilation errors that didn’t exist in 4.5.1. Then:
- Compiling any blueprints will crash
- Opening certain blueprints will crash
- Trying to delete any of my Widget Blueprint assets will crash
- Simply closing the engine without doing anything will crash
I’ve been digging the answerhub for a solution and to my despair I see there are multiple show stopping bugs in 4.6.1 and it’s very likely I’m being affected by all of them at the same time. Circular references involving UMG blueprints, using event dispatchers on singletons (gameInstance, gameState, HUD), using blueprint interfaces. Pretty much anything involving blueprint communication seems broken, specially if you try upgrading a large project.
I don’t even know where to begin to reproduce this in an empty project (which is bad advice since it seems some of these bugs involve existing blueprints, not ones made from scratch). Is there a way to get someone to look at our project (it’s big and I cannot simply post a public link to it due to legal reasons)? Or should I sit out from upgrading for the next few versions and hope a future version will load my project without melting down nor making it unusable due to deprecating a bunch of blueprint nodes?
Hey pedro_clericuzzi,
We generally advise that users only upgrade copies of their projects to new versions in case there is a compatibility issue between the versions. If you need to move to 4.6.1, I would recommend trying to migrate levels and assets over individually into a new project. However, the short version is that the best way to prevent this sort of problem is to focus development in a single stable build for the long-term.
Regards,
Jonathan
I tested on a copy. However, I will have to upgrade sooner or later since I’m working on an IOS game and they’ll require 64-bit support, which is not available in 4.5.1.
All active subscribers have source access, so integrating that functionality into 4.5.1 is an option. The other option is, as I said, to ‘rebuild’ your project in 4.6.1 by porting over assets individually until you’ve recreated the project (replacing nonfunctional assets as necessary).
Porting individual assets sounds like a way to not be overwhelmed by several problems at once. I’m gradually refactoring my blueprints to get rid of the severe tight coupling which plagues my project, which should make it easier to migrate it piece by piece, but I’ll wait for 4.7 before attempting to migrate again.
Not wanting to sound rude but I have struggled with migrating to each new engine version myself.
“However, the short version is that the best way to prevent this sort of problem is to focus development in a single stable build for the long-term.”
This seems a little unfeasible. There are many fixes in each new release, some for blocking or missing functionality, and you guys are kicking out versions relatively quickly.
That would suggest anyone who started developing when 4.0 came out should’ve stuck with that stable build?
I think a better migration path should be considered than that statement
Just my 2 pence
I agree. Getting stuck with an old version, at least in the current stage where UE4 is still maturing, is quite a tall order since all development efforts (including bug fixes) move to the new version.
If we want a bug fixed we need to either figure it out by ourselves or do some detective work on the git repository to find out whether the bug was fixed or not since there’s no bug tracker for us developers and the “answered” flag in the answerhub doesn’t means the problem was fixed (I got a bunch of “deal with it” answers already). It’s even awkward to post questions about a problem when you’re working with an outdated version.
Also the people who have the most problems migrating or have to stick with an old and unsupported engine version are most likely those actually shipping games, upon which Epic will receive 5% of all gross revenue.
If new UE4 versions are being designed with focus on clean slate projects, then we need some means of updating older versions. At the very least a way to keep adding pull requests to old versions on github.
Generally, a developer who started off on 4.0 would stay on 4.0 for quite a while. If bugfixes or new features convinced them that they needed to upgrade, they would stage a migration to a newer version - probably 4.3 or 4.4 - that is known to be stable. The migration would probably take a while, cleaning up any assets or levels incompatible with the new version.
It’s only in a particularly catastrophic situation (like pedro’s) that I would suggest migrating the assets manually.
We’re aware that the migration process is buggy and hard to troubleshoot - we’re working on it. Until then, I still wouldn’t recommend upgrading an important project to every newly-released version as it comes out.