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

News & General Discussion
1

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)
11 Likes
2

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

5 Likes
3

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.

4

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.

5

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.

2 Likes
6

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?

2 Likes
7

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

Very true.

8

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 )

3 Likes
9

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. :roll_eyes:

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.

3 Likes
10

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.

4 Likes
11

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.

1 Like
12

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

13

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.

14

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

15

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:

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.

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.

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 :slight_smile:

15 Likes
16

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.

17

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.

18

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.

19

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.

But hey, at least its been worked on.

1 Like
20

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

3 Likes