2021 LTS is so buggy that we will definitely switch in the future

Everyone in the team, artist, programmer, networking, environment artists .. are all very frustrated with the terrible state of 2021 LTS. Especially the programmers say that they can barely work with all the glitches and domain reloadings and auto savings, broken build pipelines and whatnot.
2021 HDRP is also still very glitchy. For weeks we couldn't work on prefabs even.

Everyone is so riled up that they want to switch in the future now, after we spent years building up all our structures.

For a LTS version this is just unacceptable and feels like we are testing an 2023 Alpha build.
Stay on 2020..

Edit: Jesus christ
Now we try the 2021.3.7 version and they knowingly push a patch which just disables your game Interfaces.
We try .7 to desperately get some fixes for this mess of a LTS version and then it just knowingly breaks the UI. Who the hell pushes a patch with such glaring issues onto LTS. What is going on at Unity..

• Known Issues:
  uGUI: Broken mouse pointer input coordinates in GraphicRaycaster for certain window sizes in Build when run in windowed mode (UUM-7893)
• uGUI: UI becomes not interactable after deactivating and reactivating Canvas (UUM-9258)
• uGUI: UI Elements are no longer rendered when deactivating and reactivating the Parent GameObject (UUM-9248)

 

Can you post links to the surely numerous bug reports you‘ve sent to Unity over the past year?

 

Well, you need either get skilled, or train your programmers.
For example you can disable auto saving. Your programmers should be aware of that.
Otherwise you waste tons of time on this alone.

Your team should be responsible for testing your project upgrades, before moving everyone else forward.

It looks, like lack of expertise in different areas is affecting your team productivity.

 

While all true, I still have to put at least some of the blame here on Unity for breaking auto-save. If your product has regressed so badly that your auto-save now has caveats this either means it should be disabled by default or else not released until it is resolved.

At least, unless this is talking about something like Rider, where I don't think they really can be held responsible for Unity's decisions, and ship with very aggressive auto-saving on by default. That's really nobody's "fault" and definitely an unfortunate situation where the only way out is to get bitten and then turn it off yourself.

 

The auto save case is designed for new developers. New developers were complaining quite often for years, their code, or the project haven't been saved. If I recall correctly.

Now, once more experience dev, looking for improved work flow, need to learn to disable auto-save then also remember to reload changes, i.e. using ctrl+R. Then this to become habit. This way dev has full control for example, when code is reloaded.

Unity did right thing here, to enforce auto-save by default.

Once changed, you don't need to think about it, even when upgrading project. Yet if disabling auto-save is such a big issue alone, I wonder how the rest of development is going. As this should be least of concern for more experienced devs.

It is like trying developing project without source control.

 

I don't understand why teams will upgrade existing projects to new versions without testing it out first.

This doesn't just apply to Unity but all your software, tools, and dependencies. Would you set all your SDKs and third party libraries to just auto update?

 

Yeah, i've heard a thing or two about that, but it seems that everyone has different issues.

Very true.

 

The OP tested it and does not like it, how else would he know about the regressions?

I think there are some valid concerns and needs to be taken serious, and not say you are holding it wrong ( like steve jobs did when the phone had an antenna problem )

 

What exactly is auto-saving and what are the issues with it?

I know of only one thing that autosaves, and that isn't even Unity-specific. Rider does it. Every time I tab out of Rider, it saves my changes to scripts. And I love it because while it takes 2-3 seconds every time I switch to Unity and in rare cases it is annoying ("hey, I just wanted to look something up damnit") most of the time it SAVES me from testing something I hadn't saved or going extended bug-hunting even though I just fixed it, and next thing I UNDO my fix because it CLEARLY hasn't worked.

The time I wasted on those scenarios easily outweigh the few seconds every time I switch into Unity. I'm talking about 10-100 minutes wasted per occassion (!) vs 10 minutes a day total waiting for script compilation.

I'm not aware of any other auto-saving features in Unity. In fact, when I google for "Unity autosave" this post is what comes up on top.

Btw, I was working with teams before and it's quite convenient to blame something that annoys you to the tool you are using, or top level management, or the government, etc etc etc.

Case in point: compile times skyrocketed in one project. So over time we applied a couple things that helped half the compilation time: using the new (back then) assembly definitions (they also helped clean up the code), moving code that infrequently changes into DLLs, moving 3rd party code into Plugins and/or AsmDefs, removing unused assets from the project, changing the scene structure so that they can be tested individually, losely coupling the UI via ScriptableObject variables/events, and so on.

It takes time to not waste time but it is almost always less time than going to keep on wasting more and more time.

 

No, the bug is that the Auto saving is broken and triggers on any code change despite being turned off.
So any letter you write is saving and compiling without asking if you click on unity for anything.

Im not going to list all the dozens of issues that appeared with 2021
Yes we tested it beforehand, certainly not enough and yes it was our mistake of trusting Unity with a year old LTS version too much, but more and more issues are becoming visible over time.

Some specific bug is not the point, the entire state of the 2021 LTS is just unacceptable.

 

It feels LTS versions have been taking a long time to stabilize after being bug ridden messes at release starting with 2019.4 (which took so long Unity reduced the number of yearly Tech releases from 3 to 2 to keep their schedule somewhat under control).

Personally I don't bother even testing the latest LTS until it has hit 20 releases or so. 2021 is at what, release 7? That's too soon.

 

2021.3 yes is only number 7 at time of this post
it starting to stabilize now after 2021.3.4 with update into api 12.1.7
HDRP is nice but URP seams to still be struggling in that they release a number of major changes all around the same time

based on the history from 2020.3 your about correct in 20 releases
for 2020.3 it started to get nice in and after 2020.3.18

 

I think I have similar concerns as OP. New software is not reliable even when it is released as "stable" or "LTS". 2020.3 is in a nice place right now and I suspect 2021 will be similar after it hits the ".3"

However, unless you have a strong requirement to upgrade (security fix, no longer support current hardware, etc) there shouldn't be much urgency to upgrade. And definitely don't put an entire dev team on a new major version without a significant amount of testing, especially when you have a ton of workflows and tools depending on it. A lot of those "bugs" and "glitches" could be discovered just playing around in a new project and importing test assets or running some of your own workflows on it.

 

Agree
however if talking about HDRP the jump up into 2021 is good as unity improved compile time significant that the work is so much faster I would dread having to work day after day again in 2020..

URP maybe a different animal and seams a bit further behind than HDRP
its too soon to say .. looking ahead 15x URP its undergoing major changes again and perhaps this will roll back to LTS in future mid cycle we can hope

 

I see where OP is coming from, and I know the game him and the team are working on and it's some impressive stuff.
Honestly an LTS that underwent multiple patches is expected to be fairly stable. Will never be perfect, but it just shouldn't have this many issues.

And people thinking it's someone's fault if they don't report bugs, sorry but that's just BS.
We shouldn't be doing unity's job, we help, but it's not our job. We have enough to worry about.

I've given up on sending bugs, I'm tired. I have a long list, Some are still not fixed, some are postponed, and the rest are fixed or 'wont fix' for whatever reason even though it's an accepted bug. Usually it's "too much work", or planned rework in the future.

I reported a tessellation issue, and it's wont fix because they intend to rework things related to how it works in the future which will also fix this bug, but they gave no ETA at all, so maybe 2023, maybe 2024, or even further away.

Seeing how URP still has no TAA, I'm not holding my breath. Does unity not have QA? How the hell do some seriously BASIC, and easy to find critical bugs go through with zero reports? When I tried tessellation in HDRP I found multiple issues and reported them, all accepted. How did it go for so long without internal reports? How is it that I'm the only one to have reported it. HDRP's userbase is small compared to built-in/URP, and so many bugs go unreported by it's userbase. It shouldn't be our job to do QA for unity.

I'm being overly negative but honestly I just can't be bothered to report bugs anymore, unless it's a massive issue.
Every time I have to create a fresh project, setup an easy to reproduce project for the bug and send it over. Because if you don't provide a reproduce project, good luck ever getting it through QA.

Some of my reports go months without a single reply, without QA checking it, so developers don't even know IT EXISTS.
And then some of unity's own internal QA don't seem to understand HDRP. I have to explain basic HDRP settings to them.
I guess even QA isn't enjoying SRP life.

a few of the bug reports I sent:
- Unity Issue Tracker - Shadow artifacts when Filtering Quality of Shadows under Lighting in HDRP High Fidelity settings is High (unity3d.com)

When setting shadow filtering to high, you will get some seriously annoying artifacts on meshes. The smoother the shadows, the more evident. And if you don't use cascade blending, it becomes much worse. This doesn't exist for medium quality shadow filtering.
It's fixed for area lights but that's it, not directional/punctual lights. Thus it's now postponed until the other light types are fixed.

- Unity Issue Tracker - [HDRP] Noisy top shadows when using 'High' Filtering Quality with Tesselated Meshes (Lit Tesselation) (unity3d.com)

I reported this a long time ago, finally fixed. Just not sure how this got this far without anyone reporting it, or unity themselves finding the issue. It exists all the way back in 2020.


- Unity Issue Tracker - [HDRP] Shadows pop in and out when tessellated geometry is culled (unity3d.com)

This one is a big issue. Still not fixed, although the developer responded to me in my fogbugz report and helped me find a workaround, which I do appreciate, but it forces me to use shadergraph, can't use the lit shader. Also somehow not detected by QA.

Not all of it is doom and gloom, some issues are fixed fairly quickly and QA responds within 2 weeks, but the inconsistently is what's painful - and unity's QA feels lacking.

It's like unity's management doesn't care much about HDRP/URP, even the team is smaller then you'd think.
If I go on a rant about URP this post will take over the next page, so I'll stop myself here

 

See, that's the thing for me too. I see bugs that are marked as "fixed" and they persist, or they're fixed for a couple versions and then end up back as regressions later on and I just have to wonder "well then what's the point?"

I understand the difficulties of working with complex code bases like a game engine but it becomes a pretty major annoyance if one of the things I'm checking for in new versions is seeing if a bug that was solved once is magically back again.

 

I think the "LTS" label is misused, When the whole TECH+LTS system was introduced, it was explained that the LTS version was a rebrand of the latest TECH version when it was considered stable enough.

But in reality what has been happening is that the LTS versions get released with quite more issues than the last TECH release they were supposed to be. For example, Unity 2019.3 TECH was super buggy at release but managed to turn the ship around after several version. But when 2019.4 LTS dropped, it was full of in-your-face, show-stopper issues that didn't exist in 2019.3, as if it was a brand new TECH release.

Now, it's "normal" for minor versions to introduce bugs, since in software development fixing a bug always carries a risk of creating others. But the recurrent drop in stability in the transition from TECH to LTS hints that the transition process has problems and needs to be re-evaluated. It smells like a "everyone pushed their changes all at the last moment" situation.

 

Was it?

There are multiple ways in which a code base can be "stable", and a lack of bugs is just one of them. The only "stability" which an LTS branch actually promises is a lack of change with regard to features. Back when the LTS thing was announced I think that we all just expected that after a full year of dedicated effort a particular version should be fairly bug-free by the time it gets renamed, and back then it usually was.

But renaming it from TECH to LTS isn't going to make bugs magically go away. And having fewer bugs than its associated TECH branch is only going to happen by virtue of getting further effort and patches So if an LTS comes from an especially buggy TECH origin, then it's going to start off in a similarly buggy state.

Regardless of how we think it should be, if we're thinking pragmatically when we switch to an LTS branch it probably has to be about one of two things:
1. we want feature stability; and / or
2. we need that 2 years of support on a fixed version.
As for bug stability, all we can really do is hope that it's a byproduct of those two things. The catch is that the longer we wait for the bug-free type of stability, the less time is left on that two year support clock.

It kind of makes one feel that batching major changes into major versions and supporting them as specific products had some pretty major benefits. It also has its downsides, but at least major new features had very clear targets to aim for which were attached to concrete decision points and deadlines, rather than dragging on as some big ticket items have now been doing for years, no doubt in part because they need to integrate with other big ticket items which also don't have clearly defined fixed targets.


Separately, I definitely share frustration with Unity's handling of reported issues lately. I keep hearing back about them, which seems like more than most get, but I only remember one in the last few months being taken on board for a fix. For everything else they've claimed it can't be repro'd, or argued about whether it's actually a bug ("by design" only fits one definition of what a "bug" is) or, in one case for a major issue with a major feature, said a fix wouldn't be provided until (IIRC) 2022.1 TECH due to the scope of change required to fix it. I had another case like that a couple of years ago where the support agent stuck around for months helping to find a solution, but not this time. Just confirmation in a forum thread that a fix wasn't coming unless we wanted to move to a then-alpha version of 2022, otherwise we'd have to look for our own workarounds.

It's not stopping us, and we're still better off overall using Unity than not, but sheesh, cases like that stick out.

 

Yeah, 21 LTS is bit of a mess, but its not that bad tbh. Our main issue - UI stops working correctly when canvas gets disabled / enabled. Its somewhat related to the sorting order, so if you override & set it manually - it will work. But at the same time manually setting order - its a recipe for the future problems.

2021.3.5 doesn't have this issue, 21.3.6+ just plain breaks your UI.
https://issuetracker.unity3d.com/is...vating-and-reactivating-the-parent-gameobject

But hey, at least its been worked on.

 

Yeah, amazing how a company with 5000 employees sometimes manages to even work on their main product. Truly admirable.

 

Would it be more optimal if Unity has the same version pattern like Unreal? Every incremental build is considered stable for production with only 3 or 4 hotfixes if needed. New features and bug fixes would outweight regressions.

 

Was it?

https://blog.unity.com/technology/n...ng-the-tech-and-long-term-support-lts-streams

 

Even assuming it's a significant contributing factor, changing a numbering scheme won't magically result in features and bug fixes outweighing regressions.

 

True, but i suppose that the point @Neto_Kokku was making is that LTS needs to actually stand for its name.

 

Holy S***

We just downloaded 2021.7 to try get some relief and suddenly our UI just turns off
Im looking at the patchnotes again and see this



How did this go live. Now our UI is just dissapearing.
Who puts a "fix" patch live with such a huge glaring issue..

 

Unity bug department rn

 

Okay, but that still doesn't say anything about stability. Just that it's the previous TECH release getting extended support. LTS stands for Long Term Support not Long Term Stability. Any claims to stability are what we've been placing on it ourselves. I know I'm just as guilty of doing it too in past discussions.

 

It does. The name does not mention or imply stability.

 

I know that. My grief is that you don't often see multiple blocking issues get introduced between minor versions, but on a fresh LTS it's been pretty much a given. It feels like a larger amount of code changes gets pushed into the fresh LTS compared to what goes between minor Unity releases.

But again, it could also be because more developers wait for the LTS and skip TECH releases (specially those with ongoing complex projects and longer dev cycles that need to play it safe). Since Unity has been relying too heavily on user reporting for QA all those bugs that show up in the LTS could actually have been there all along, waiting for a poor sod to trip on them and have their work be disrupted enough to warrant a bug report.

 

To a degree I'd say LTS is what you should chose when you start a project now. By the time it's launch time, it is realiably long term stable.
Don't switch Unity version in the last third of your project... Fairly sure people with Unreal and most other engines don't do that either.

 

That's demonstrably not the experience people are having.

It's pure luck that my own current project picked 2021.3.5. It's behaving well for us, but likely it all comes down to what parts of the engine a particular project pokes more than others.

 

LTS 2021 is only out for about 3 months. No dev is thinking about release now if they started with 21 as I suggested.

 

If you don't expect it to work reliably 3 months in, then what exactly did you mean when you called it "reliably long term stable"?

Or, in different words, is nuking peoples' GUIs after 3 months your idea of "reliably long term stable"?

Edit: To clarify, I'll happily forgive mistakes when they're handled well, and anyone looking at upgrading stuff should likely have done enough of their own testing to spot this (edit: actually, I can easily imagine edge cases where it could slip through). But this is the second LTS release with the same issue, so I think the question raised about what's going on is a pretty reasonable one in this case.

 

The name doesn't, but the description below it does... That said, stability doesn't mean it wont have any bug, but (I guess) it's just that it wont have new feature, which usually comes with a lot of bugs and other instability...

 

... and the maximum of two small numbers is still a small number.

Plus, indeed, see earlier discussion re: what "stability" can mean.

 

"Long-term support (LTS) is a product lifecycle management policy in which a stable release of computer software is maintained for a longer period of time than the standard edition." unless Unity has its own definition...

 

Our two biggest issue we have reported on June 2nd.
The Recompile After Finished Playing bug was set to "Under Review" 3 weeks ago, otherwise no reaction.
Our other big issue was Decal Projectors triggering error spam when exiting prefab edit mode with decals in it.
We ranted about it in the forums and the HDRP team picked it up & fixed it on their side within 2 weeks, the fix for this has not been publicly released yet. Fortunately they wrote in the forum how to fix the package yourself.
It is clear that the actual devs themselves are doing a great job, however the overall release system has huge problems.
Using the forums to get critical issues sorted so far has been much more time effective.

Given that it takes months to get simple bugs officially sorted out (Decal Projector issue is literally 4 lines of code and was fixed within days), starting a production on a version that has < 1 year support is a giant risk.
On the other hand, using the current LTS essentially forces you to work with what should be an early beta version, where every other release is completely broken, case and point UI bugs in 2021.3.7.

In our case our full release will be somewhere around 2020 deprecation date. If we are still on it and run into any kind of issue (for example we haven't completed console port yet), we are screwed.

 

Interesting... I've found 2021 LTS to be the most stable in a long time. But I'm on 2021.3.4 so there is that

 

Create a list of custom struct or class and notice how the collection Inspector is completely broken and unusable for collections with multiple items. A major bug they introduced in 2021.3.3 and didn't fix for 2021.3.4, then back ported the bug to 2020.3.35 and finally managed to address it in 2021.3.5. Not sure when they fixed it for 2020 but I'm not upgrading past 2020.3.34 right now due to this nonsense. Needless to say this made the engine completely unusable on our end, as we manage a lot of data this way.

EDIT: Image courtesy of forum user pkessler94

Spoiler

 

This one is infuriating to me. I've basically started writing an entire custom inspector framework to get around this.

 

Oh yeah I remember that issue. I just did what i needed to in the debug mode if i remember.

 

You know, this is one of the cases where community could take over.

Because unity is extensible, it is possible to make better gui and release it as MIT. Instead of waiting for a fix...

 

Sure, we could do that, but the thing is... we shouldn't have to? I don't have the time or energy needed to juggle both working on my own projects, doing contract work, and also shoring up my internally used code to release as open source, especially when this behaviour is a regression on Unity's part.

 

This is also not the first time this regression has been reintroduced as a reoccurring bug. Unity is a multibillion corporation, it should not be on the community to test and fix their engine for basic things like list inspector. This is a thing an intern could've caught, so I wonder what Unity's QA department is doing or is it replaced by automated tests that pass with flying colors because the console is clean.

But perhaps QA has some friction with the change of the bug reporting platform, so things are less stable than usual until they catch up. I just got a response to bug I reported back in early June.

 

Is your work related solely to this issue in particular or are you reworking the Inspector as a whole?

Or they could release it commercially and hope for Unity to pick it up and acquire the project from them, considering all the purchases Unity has been making lately .

 

I know what LTS means, if you check my registration date you'll even see that I've been here longer than Unity has even had a named LTS branch. That does not, however, change the fact that there are regressions in performance and functionality in both LTS and Tech across a number of areas.

 

One area I wish could be improved involving backporting is communication in that we commonly see a fix get backported however in some cases it does not get applied to every api version within a LTS cycle. The process of backporting from observation starts in the highest api withing xx and takes weeks and in the past, even months for it to trickle down to lower api’s .. in some cases, it gets stalled or stuck for weeks and then just stops never getting all the way down in lower versions with the same cycle

the problem is communication in we don’t get any update logs about backporting and old change logs don’t get updated to include new changes

just some recommendations that could help mitigate communication gaps