Unity 3.51: still in beta with these bugs

[droderick]

I understand your explanation, but again, my work isn't being a beta-tester of a product which I paid more than $2000 before and it's closed-source.

I'm the client which I adquired this product, I'm not the engineer developing it. Maybe sounds a little hard, but it's the reality.

Do you really want improvements from users community? Ok, then make it free and open-source. But don't expect this behaviour will be on a commercial and closed-source product.

I'm tired of send bug reports, some of they are ignored because I didn't attach the full project. Unacceptable.

I have to report a bug, but wait, I can't query the bug tracker, maybe I'm just losing time reporting because I'm just creating a duplicate case. Unacceptable.

If I decided spend this money it's because I trusted on a robust product, what's happened is they released a new "stable" version when really is a beta version.

Furthermore, this "stable" version doesn't allow regression to your project because they are converting the full project to 3.5.

Really, not allowing regression to a previous version, in technology terms, is unacceptable and a suicide.

Errors caused by memory leaks on a commercial product is unacceptable too, and should be fixed as soon as posible with highest priority.

This last maybe is the most important and more critical.

i too agree with each point!

[rextr09]

I think Unity needs to stop adding new features to the engine and fix the basis.
I understand the whole engine system is very complex and with the big changes introduced in 3.5 version, the priority must be consolidate it as a robust product.

Totally agree!, No more new features please until it's robust enough.

[Framer]

Hi.
After we migrate to Unity3.5, in our big project, we have the same problem with performance .
And we post a ticket to unity support and bug to unity bugtracker.
We lost a half fps in our project.
We send sample project that show performance differences between Unity 3.4. and 3.5, to unity.

[_rem]

Hello,
I decided to create a new project and re-import all my "assets" one by one. After several hours fighting with broken links, "levels", "Tags", hardlinks between scripts and "gameobject", scripts and scripts, remake "ligthmaps" ... for short:
- Everything works perfectly, no "dracalls" crazy, no display problem with "the prefab Nighttime Water", great! the same performance as version 3.42.
I decided to apply "Occlusion Culling" on my "terrain" and on elements of decor, I check with "visualization" everything is OK, I "Bake".
And there, all problems begin! "dracalls" crazy, refraction of "prefab Nighttime Water" blinks, the framerate collapses ...
I delete data "Occlusion Culling" and "Occlusion Area" and everything returns to normal, I create a "webplayer" the same performance as version 3.42.
- "Occlusion Culling" not work with 3.51 (it did not work, also with 3.42 but silently)
I'll edit my bug report with a simplified project, (I found another strange big bug not easy to reproduce!)
thank you for the support.

Joachim Ante, aNTeNNa trEE : not comment on my observations ? but may be you already knew that "occlusion culling" does not work and a performance penalty?
Otherwise have your views on this issue, before I volunteered to participate your Debug application(working on a simplified project with the bug report) will be welcome !
cordially

Up ?

[virror]

I think Unity needs to stop adding new features to the engine and fix the basis.
I understand the whole engine system is very complex and with the big changes introduced in 3.5 version, the priority must be consolidate it as a robust product.

+1

[antenna tree]

Joachim Ante, aNTeNNa trEE : not comment on my observations ? but may be you already knew that "occlusion culling" does not work and a performance penalty?

No, we certainly wouldn't release a feature that we knew to be broken. All the tests I've done with 3.5's Occlusion Culling have worked quite well. So getting bug reports with attached projects that reproduce a bug is usually the only way we can track down these corner cases and fix them.

[_rem]

No, we certainly wouldn't release a feature that we knew to be broken. All the tests I've done with 3.5's Occlusion Culling have worked quite well. So getting bug reports with attached projects that reproduce a bug is usually the only way we can track down these corner cases and fix them.

OK ! thank you for the replies, I'll create a new bug report with a test project. I 'll give here, my new "case number".
I don't know edit the old case number.

[l0cke]

No, we certainly wouldn't release a feature that we knew to be broken..

Hmm, Umbra oclussion was not working since early Beta 3.0 (cca 2 years). Lots of beta testers reported it in 3.0 beta (!!!) and you made release anyway. Everybody here knows, that it was totally unusable for 19 months. I dont know which tests you made, but we werent able to get it working even on most basic things (like majority of people here).
Even now it does not work properly (it does not crash anymore during baking, but still problems - it does not turn off objects which should). In beta 3.5 testers were reporting problems too and it stayed ignored and was released....

So getting bug reports with attached projects that reproduce a bug is usually the only way we can track down these corner cases and fix them

Have you ever worked in other company than Unity? Tracking bugs without customer data is how rest of the world does it. Actually asking for client data due to bug fixing is considered amateurism of worst kind. Indeed you can find and track bug without client data. Indeed it is more effort, but absolutely possible.
But I understand, that it is far more comfortable to say "send us your data" and than discard bug as "not possible to replicate".

You are speaking about corner cases, but very often bug is replicable very easily (and in asbolutely basic function), but still answer "send us your project".

[jlevel]

Hmm, Umbra oclussion was not working since early Beta 3.0 (cca 2 years). Lots of beta testers reported it in 3.0 beta (!!!) and you made release anyway. Everybody here knows, that it was totally unusable for 19 months. I dont know which tests you made, but we werent able to get it working even on most basic things (like majority of people here).
Even now it does not work properly (it does not crash anymore during baking, but still problems - it does not turn off objects which should). In beta 3.5 testers were reporting problems too and it stayed ignored and was released....

100% agree

[Tiles]

An example project to reproduce the bug speeds up things most of the times. So it`s not a bad think to ask for it in general. But it is very bad to reject a bug report just because there is no project to reproduce attached. And that`s usual it seems.

I have a UI bug here that is NOT reproduceable with a project. I know that it will not being investigated when there is no attachment. But it doesn`t make any sense to attach an empty project neither. And so i don`t report it. That easy.

I have another bug. My project folder has reached the size of 1 Gig now. Ever waited for 1 gig to upload to an FTP? I am just an amateur, but even i miss the time to wait several hours before i can use my pc again. Especially when i do this more often. I could of course reduce the filesize to something smaller, to reduce the problem to just the involved objects. Which would mean to spend another day of work to throw out everything unneeded ... . And so i don`t report it. That easy.

Fact is, the current way to deal with bugs produces lots of unsatisfied and unhappy users. Maybe it`s time to rethink the strategy.

[jlevel]

The actual bug system is useless and prehistoric. Why don't use something like Bugzilla? Or Mantis BT?
If there is a need of NDA on attachments just add an option to make them privates, but only the attachments. We need to search on bug tracker, add comments and see issue status.

If someone reports a lot of critical bugs then reward them. Give to him free upgrades, coupons, free beer, women, the possibilities are infinite.

Anyway, we will be ignored again and nothing will change

[Baroni]

Vote for it.

http://feedback.unity3d.com/forums/1...le-bug-tracker

[jlevel]

Vote for it.

http://feedback.unity3d.com/forums/1...le-bug-tracker

Voted

[Tiles]

I can`t vote, my ten vote points are gone. That`s another dinosaur. Only 10 suggestion points per person.

[n0mad]

Vote for it.

http://feedback.unity3d.com/forums/1...le-bug-tracker

How come I didn't know it existed ? Voted.

Also :

Have you ever worked in other company than Unity? Tracking bugs without customer data is how rest of the world does it. Actually asking for client data due to bug fixing is considered amateurism of worst kind. Indeed you can find and track bug without client data. Indeed it is more effort, but absolutely possible.
But I understand, that it is far more comfortable to say "send us your data" and than discard bug as "not possible to replicate".

You are speaking about corner cases, but very often bug is replicable very easily (and in asbolutely basic function), but still answer "send us your project".

I wouldn't be so rude as I still feel much respect for Unity's Team overall work. But I have to share the same stupefaction. I wouldn't expect such a QA validation strategy from such a big (popularity speaking) company as Unity Tech. I worked for a company which provided frontend & backend applications/tools, where framework stability was critical if they didn't want to produce up to 1 million euro public tresory loss under a month. I just can't picture QA saying to CEO : "Sorry, I can't reproduce that big bug, let's put it on a lower priority"

Of course it's harder without a precise configuration of Unity framework, but (no offense), let's remind that it is just that : a configuration of your framework, Unity.
It's not like we were hackers who just reverse-engineered your engine and rewrote some low-level functions. We're just using the tools you gave us in various ways, so if we (at least) provide a concise procedure about how to reach such a precise configuration, I can't see how it would be more "deniable" than an already configured one.

Anyway, it's quite a complex problem I admit. That's why a public bug tracker would be a good step forward.

[jlevel]

How come I didn't know it existed ? Voted.

Also :



I wouldn't be so rude as I still feel much respect for Unity's Team overall work. But I have to share the same stupefaction. I wouldn't expect such a QA validation strategy from such a big (popularity speaking) company as Unity Tech. I worked for a company which provided frontend & backend applications/tools, where framework stability was critical if they didn't want to produce up to 1 million euro public tresory loss under a month. I just can't picture QA saying to CEO : "Sorry, I can't reproduce that big bug, let's put it on a lower priority"

Of course it's harder without a precise configuration of Unity framework, but (no offense), let's remind that it is just that : a configuration of your framework, Unity.
It's not like we were hackers who just reverse-engineered your engine and rewrote some low-level functions. We're just using the tools you gave us in various ways, so if we (at least) provide a concise procedure about how to reach such a precise configuration, I can't see how it would be more "deniable" than an already configured one.

Anyway, it's quite a complex problem I admit. That's why a public bug tracker would be a good step forward.

That's true.

Let's put an example: any GNU/Linux distro or the Linux kernel itself. Which is a lot bigger and complex project than Unity3D.

Can you imagine if for any bug they say "Hey! Send me your full GNU/Linux distribution with all the packages, sources and all your data installed on your machine, or we can't debug it and it will be considered as lower priority or maybe ignored". Completely insane.

Just for this reason the use of a public bug tracker is justified.

As l0cke said, tracking bugs without customer data is how rest of the world does it.

[rextr09]

Vote for it.

http://feedback.unity3d.com/forums/1...le-bug-tracker

+3 votes from me!

[flim]

I understood why the Developer Preview section still here, because 3.5 still under development
And Unity is the only engine I know which lack a bug forum or tracker. Maybe UT afraid bug hurt sales? That is a sign of lack of confidence of their product.

[kablammyman]

+3 votes from me!

me too.

lets fix the basics unity! A good bug tracking system can be a great start to fixing the broken basics!

[jlevel]

I'm wondering if number of votes has any real effect, because if you browse each planned / started or completed project much of them has less votes, and curiously some other projects with a lot of higher votes doesn't have any response.