Impossible to Upgrade

As a long time Unity user I'm well accustomed to things breaking when upgrading a project to a new editor version, but the latest situation is nothing short of absurd--so much so that all I can really do is share it here.

Our project is currently on 2019.2.17 and is ready to upgrade for various reasons. Reading the blog comments on 2019.3's release assured me it was to be avoided, so I've been equally skeptical of 2019.4 (LTS). With our project far along in production though, as per the official word, we decided it should be safer to stick with the LTS for now than go for 2020. Hopefully it's been long enough to have stabilized somewhat.

Instead, we find the upgrade broke our character selector, the console spamming messages about the Animator and "PlayableGraph being evaluated with no outputs. Playables will not be updated". We don't use Playables, so what does this even mean?

Debugging and web searching later, I finally come across this issue: https://issuetracker.unity3d.com/is...controller-is-changed-twice-on-the-same-frame

Turns out, this game-breaking bug is already fixed in 2020.2, "In Review" for 2020.1, and "Planned" for the "stable" 2019.4.
This issue is already about 2 months old, and it's only "planned" for 2019 LTS? I've seen numerous other bugs like this: fixed for the latest "unstable" beta version with no word on the current "stable" releases, with people asking "When? It's been months." and getting no response.
Also, this issue isn't even covered on 2019.4.5's "Known Issues" list, which doesn't inspire much confidence.

Another one affecting our game (https://forum.unity.com/threads/etc-mono-config-and-path-resolution-for-dylib-in-macos.814746/) has no issue tracker link, but the last word from Unity was that it was fixed in a 2020.2 Alpha and "should soon make it to 2020.1 and 2019.3". Who knows if it did, because the next person to ask for an update was ignored.

So as paying Unity users, our only option for getting our game-breaking bug fixed is to upgrade our far-into-production project to the latest alpha version.
Oh wait, we can "log in to vote on this issue". I'm sure that will make a huge difference when the issue currently has 0 votes. ;P


For icing on the cake, the code responsible for this bug is a hacky solution I had to implement for more strange Unity behavior:

Code (CSharp):

1. anim.runtimeAnimatorController = null;
2. anim.runtimeAnimatorController = characters[id];
3. anim.SetTrigger(preview);

We ended up having to set the Animator controller to null first because there was a strange bug where rapidly changing between controllers would double-trigger on certain state machines, and no combination of stop playback/reset trigger would fix it.


Ultimately I don't expect this topic to go anywhere, but as I said, sharing the absurdity of the situation is really all I can do. We'll continue with 2019.2 for now, but at the rate Unity goes, we may not be able to upgrade our project until 2020.2 is ready. Or, isn't ready, because maybe alphas are more stable than the ready releases?

 

Are you sure? Some packages from the package manager come preinstalled when you create a new project. For example, you might have Unity's Timeline module (which makes heavy use of playables) included in your project even if no one on your team intentionally installed it.

 

I personally love Unity 2019.4. It has been very solid for me overall.

It is easy to install multiple versions of Unity using Unity Hub. Install Unity 2019.4 in addition to your current version. Make a full backup of your project. Try opening your project in Unity 2019.4. It will probably go well. If it does not, you can revert back to your older version of your project in the older version of Unity.

 

As a game developer, you need to find workarounds that can get your game to market without waiting for game breaking bugs in the engine to get fixed. If you wait for bugs to get fixed in the engine, then you won't be able to ship your game in a reasonable length of time.

For example, I discovered a game breaking bug in Unity back in 2016 while I was developing Disputed Space. I shipped Disputed Space in 2017 on Steam. The bug I discovered was a 4GB content limit per scene in all versions of Unity. It was a 32 bit limit on the scene files in 64 bit builds.

Here is a thread about the 4GB limit:
https://forum.unity.com/threads/bug-4gb-limit-to-textures-in-standalone-build.441116/

This bug was easy to reproduce, and it affected a lot more people than just me. Unity confirmed the bug right away and offered a couple possible work arounds. I ended up using an additive scene loading feature to work around the bug so I could ship Disputed Space in 2017. Some projects used asset bundles to work around the bug. Either way, we all refactored our projects and worked around the bug instead of waiting for a fix.

The actual bug in the Unity engine was not fixed until Unity 2020.1. If I would have chosen to wait for a fix, I would have needed to delay my project 4 years. As a game developer, you should always report bugs quickly and then immediately find a workaround. Never wait for the real fix, because some fixes take a lot longer than you might expect.

 

This isn't unique to this game engine nor is it unique to just game engines. You can very easily run into this problem with both frameworks and the native libraries of the platform too. Learning how to work around these problems is part of your life as a programmer. I wouldn't really call it absurd either as your own works will be no more bug free than the engine.

 

Bug fixes are almost always done first against trunk or whatever the mainline branch is, then backported. Often backported fixes have to be redesigned because of differences in systems the fix touches between the branches (a system was redesigned, so now the fix for the older branch will have to be rewritten to also work with the old system).

Sometimes these merging issues aren't even realized until late in the game, after the fix for trunk is done and the developer tries adding it to the older branch and runs into problems. I've never faulted them for that, because memorization of when and what branches changes went into when you've mentally moved on from the old system 6 months ago is a big ask. Working QA for very large projects, I would see this all the time.

My suggestion would be to continue on 2019.2.17, and watch the release notes for 2019.4.x new releases until the issue number shows up.

The person who asked in that thread didn't bother to tag the developer who was commenting, so he/she probably never noticed the thread got bumped. You're free to ask andrar what the status is.

 

Given where the issue went, I can only guess that the Animator is using playables under the surface as the two messages appear to be linked. I simply meant to emphasize the confusing nature of Unity's error reporting as we've never used them directly.
And yeah, there weren't any new packages installed during this update.

I've been developing games in one place or another for almost 16 years now. I'm well aware of the need to find workarounds to engine bugs (in fact, I pointed out that the bug was being caused by one such workaround). Having my workaround destroyed by yet another Unity bug that they haven't fixed in the stable LTS release meant for safely shipping your game is part of what I find absurd--especially when the fix is on the cutting-edge "don't use this for production" release. Why stick to 2019's LTS so that nothing breaks, when in fact it's broken but the latest release isn't? And never mind the very latest; 2020.1 is at least "in review" for this bug, which means they'll (probably) get it fixed sooner than us "stable" LTS users.

Given my experience with Unity I beg to differ on the point of "your own works will be no more bug free than the engine", but that's not the point; if I find a bug I'll fix it in a timely manner. If Unity fixed theirs in a timely manner (or even planned to fix it in a timely manner) I wouldn't have felt compelled to make this post.

My partner and I were discussing this very point prior to making my post, and I certainly appreciate the difficulty that must be involved. That said, going to the latest "stable" version and finding nothing but issues that aren't issues in the non-stable version... hence my post.

And yeah, your suggestion is what we decided to do for now. Hopefully it'll work out down the road.

 

The biggest problem, IMO, is that when a bug is reported on LTS, it gets fixed in the latest beta branch first, and then later is "considered" for backporting. I get the impression bugs are never actually fixed directly in the LTS branch:

1) QA gets bug report for LTS
2) QA tries to repro the bug in the latest beta
3) QA cannot repro de bug
4) Bug is marked "fixed in latest beta" and LTS users are SOL (unless they pay tens of thousands dollars for a source license).