Well, that’s it folks. Major bugs you’ve reported are now sliding into the “won’t be fixed” basket. I had my major bug (530015) confirmed as fixed… in Unity 5. Pretty sad since it first broke in 4.0.1 over a year ago.
Are your major bugs all fixed?
Well, that’s it folks. Major bugs you’ve reported are now sliding into the “won’t be fixed” basket. I had my major bug (530015) confirmed as fixed… in Unity 5. Pretty sad since it first broke in 4.0.1 over a year ago.
Are your major bugs all fixed?
Maybe you missed it, but they did say that if you find a bug that’s been marked as fixed has not in fact been fixed you should report it again as a new bug.
I don’t see any mention of Unity 5. Where did you get that info?
Quite a few of mine were, yes.
If yours aren’t, please re-submit them and re-post in the issue tracker, then post a link here, I’ll give you all my votes.
Waz is correct, this bug is being fixed in 5.0 (which our QA communicated to him by email, emails communication attached to bug reports generally will not show up in the public tracker).
This bug being fixed in 5.0 makes a lot of sense as 5.0 is getting a complete PhysX update, with a complete reimplementation of Cloth (neither of which would have been reasonable to “backport” to 4.5). Also, while I understand that everyone has different priorities, I don’t really see what makes this is a “major” bug. You have a workaround of not using optimized meshes with skinned cloth (which you described in your report yourself), so it should not be blocking you for anything. And I don’t think there will be a noticeable performance impact by turning off this optimization for a few single mesh instances you need for clothing either.
Isn’t there a “fixed in a future version” tag for bugs? I though that it was there…
The User has to buy version 5 now to get a bug fix ?
I kinda had a feeling this might be the case. PhysX’s old cloth implementation was kinda all over the map and was fragile in even the most controlled of settings.
Yes. As I explained, that bug is fixed as part of a major subsytem updated. Back porting it is not feasible here. And, even if that was not the case, no, we don’t back port all bug fixes regardless of severity to all old versions. That is simply not a realistic approach to software development and releases.
It was marked wrong in our bugtracker. I have now marked it and it will show that tag in the future.
I just want to ask one thing.
In some other threads it was said that one should not upgrade the unity if one is in the middle of the project/close to release. Then here you’ve said that not all bugs are backported. When I’m using the not-up-to-date version and encountered bug that will be no backported, it could be showstopper for me, what should I do? I’m not talking about some minor fixes. But some bugs that may exist for a long time etc.
Also I would be interested in your policy of backport/suppor of the last major version. Majority of project (mainly libs, but also standalone apps) I’ve been using supported the last major version for bug fixing. That is if the current major is 4.X then the 3.Z (where Z is the last minor version) should be supported for the bug fixing at least for the 4.X lifetime. Then I could be sure that if some bad bug happens it could be solved relatively easy and not to upgrade to the next major version which could bring some other problems.
Thank you
There is no generic answer to this. In then end it is up to you to evaluate if the need to have a bug fix is worth taking the risk of updating - that decision has to be made on a case-by-case base. But, it is a good idea to always make a backup so you have the option to revert should things go terribly wrong.
When 4.x was released, we announced that we would keep supporting 3.x with critical bug fixes for a specific amount of time (I believe it was one year, but not sure). We have released several post-4.0 3.5.x releases in that time. “Critical bugs” are not things like the issue discussed here, though, rather issues like “iOS player builds won’t get approved by new App store requirements”. I’d imagine we will have a similar setup for supporting 4.x when 5.0 is out.
I thought we said something about this at GDC when we announced 5.0. We will indeed be doing support for 4.x after 5.0 ships just as we did support for 3.x after 4.0 shipped.
As the other commenter in the issue tracker reported, this is just that way in the minimum reportable case. In my real case, it’s totally broken. SkinnedCloth doesn’t work, and hasn’t since Unity 4.0.0. I have tested it every release. The optimized mesh point was to show you exactly how to reproduce the problem with the test case.
Yes, your priorities are different to mine: you need the next version to be awesome, while I need the current version to be awesome, I understand that. It doesn’t change the frustration of waiting a year to be finally told “nope, won’t fix, it had to be rewritten”. I hope you can at least understand Hope frustrating that is.
Except this was a regression in a minor patch release of Unity. I’m pretty sure it worked in 4.0.0 and broke in 4.0.1, though it was a while ago so I could be wrong. Certainly it worked in the last Unity 3 release and all worked fine until the first time I touched my SkinnedMesh with the SkinnedMesh editor in Unity 4, though it may just have worked because it still had correct data from Unity 3.
Thank you!
Yeah, and I’m saying that PhysX cloth through the entire cycle that Unity was working with was incredibly prone to just outright breaking and never working again unless you made sure the conditions it was used in were almost always the same. It’s one of the reasons we really weren’t seeing a whole lot of cloth simulations for things other than flags in games made even outside of Unity.
It’s one of those regressions where it’s a little understandable, unfortunately.
What version of Unity doesn’t pass iOS store? I’d heard below 4.2 was problematic, but I published an app with unity 4.1.5 and it passed first try no problem…
I’ve taken the time to report a couple of bugs in 2014. I’ve taken the time to create and send sample projects, and steps to reproduce. These bugs are listed as Open. Now that 4.5 is out will they ever be addressed?
Andy
Without being able to comment on your specific bugs - 4.5’s release without them fixed does not mean they will not be addressed - and this goes for everyone. Whilst it is tempting to start a thread like this due to frustration with a part of Unity that affects you directly, ultimately the dramatic nature of the title of the thread is misleading - Sorry Waz, no disrespect, but people are following your lead here as you’ve a long history in the forum. I understand your frustration - I myself have longstanding parts of Unity I know are caught in a mid-rewrite-verus-fix scenario, so I appreciate that in your shipping project it’s even more frustrating.
The fact is, we have a 4.6 release coming, plus 4.5.x and 4.6.x patch releases being maintained by our developers and our new Sustained Engineering Team, all of which means there are opportunities to fix your bugs before 5.0 - if it’s a feasible fix that makes sense and is not part of a new system as is the unfortunate circumstance affecting the OP.