Search Unity

[Bug] Unity 2018.3.x is broken. I can't find the exact reason but something got broken

Discussion in 'Editor & General Support' started by Xtro, Feb 11, 2019.

  1. Xtro

    Xtro

    Joined:
    Apr 17, 2013
    Posts:
    608
    This bug needs urgent attention. I have been upgrading my project to the latest Unity version over the years but this bug prevent me to upgrade any further. If this is now fixed, I'll be forced to stay on 2018.2 forever.

    I didn't report this issue immediately when 2018.3 first came out because I thought it was completely broken and somebody would notice it and fix it since it was too obvious. But it looks like even obvious bugs gets ignored in between all other million-zillion bugs of Unity :(

    Bug report: https://fogbugz.unity3d.com/default.asp?1126037_01k7qoofcod4ufk9
    Issue tracker: https://issuetracker.unity3d.com/is...-objects-in-the-scene-when-saving-the-project

    Unity 2018.3.x is broken. I can't debug the problem and find the exact reason but something got broken

    1) Open this project in 2018.2.20.
    2) Open the scene in "Development" folder.
    3) Click the "save project" option in file menu.
    4) See there is no problem.
    5) Open the same project in 2018.3.x (any x version)
    6) Open the same scene.
    7) Click the same "save project" option in file menu.
    8) See that some scene objects disappear.

    Now... Those scene objects are marked as "dontsave" by my window framework. My window framework creates those objects (such as window frame) during runtime.

    For some reason, on Unity 2018.3.x, my framework loses the references to prefabs of those objects and it can't re-create hence, they disapper from the scene.

    I couldn't find why those prefab references are lost. It may be related to ISerializationCallbackReceiver.OnAfterDeserialize not being called properly when saving the project. I am not sure. I can't find the exact reason.

    Please see these videos:

    1) 2018.2.20 works fine
    https://drive.google.com/open?id=1A7nHC8NiPc6QX2qzkRLSOUWq9c108Rhz

    2) 2019.3.4 is broken
    https://drive.google.com/open?id=16572ZBBDMOl-oUs9gtV9YZJPPVAoUhzJ
     
    Last edited: Feb 11, 2019
  2. bobisgod234

    bobisgod234

    Joined:
    Nov 15, 2016
    Posts:
    1,042
  3. Xtro

    Xtro

    Joined:
    Apr 17, 2013
    Posts:
    608
    Looks like it was working fine on 2018.3.0a11.
    I'll test my case on that version to confirm.
     
  4. Xtro

    Xtro

    Joined:
    Apr 17, 2013
    Posts:
    608
    Looks like this is fixed on 2018.3.6 but actually it's not.

    I'll send a new bug report with the new state of this bug.
     
  5. Xtro

    Xtro

    Joined:
    Apr 17, 2013
    Posts:
    608
  6. Joe-Censored

    Joe-Censored

    Joined:
    Mar 26, 2013
    Posts:
    11,847
    I love your bug titles, but you should consider choosing titles which describe the nature of the specific problem so they get quickly assigned to the right people. :)

    Sorry I work in QA during the day. I don't know how it works specifically at Unity, but in general bugs with non-descriptive titles or lacking concise descriptions of the issue right at the top, those are the bugs that get stuck in limbo for a long time until someone gets the time to read through it, understand it, and send it to the correct team. Bugs with titles that describe the problem immediately get sent to the correct feature team without even having to open them, so are more likely to get addressed faster.
     
    Last edited: Feb 16, 2019
    angrypenguin likes this.
  7. Xtro

    Xtro

    Joined:
    Apr 17, 2013
    Posts:
    608
    I use proper bug titles when they are real bugs. When a Unity version is broken, it's broken. I can't make any better titles :)
     
  8. Xtro

    Xtro

    Joined:
    Apr 17, 2013
    Posts:
    608
    I know that they released an unfinished version including the new nested prefab system before the year 2018 ends just to be able to look like they didn't miss their deadline. Oh yea they did.
     
  9. Joe-Censored

    Joe-Censored

    Joined:
    Mar 26, 2013
    Posts:
    11,847
    I'm just saying, the person who is the point person for allocating bugs is not going to know your bug needs to be sent to their prefabs team until they read through it entirely. If Unity works like many companies, that means the point person will ignore your bug right now, go through all the other bugs they have waiting, and if/when they get the time they will then open your bug and read through it. That could be the same day, or a month from now, when it gets sent to the prefabs team. Until then the prefabs team will be unaware of the issue unless they already discovered it in house.

    This issue seems really important to you, so I'm surprised you didn't title it with something like "Files disappear and Nested prefabs break on player build" which would probably sit waiting to be sent to the correct team for a very short period of time.

    /Rant :p
     
  10. Xtro

    Xtro

    Joined:
    Apr 17, 2013
    Posts:
    608
    You may be right but I know from experience that, when I report the bug via latest Unity version, included a full project and included a video proof, they process the bug report quickly. That's quick enough for me right now.

    Also, I like to be sarcastic to the face about big mistakes like this with my punny bug titles.
     
  11. Joe-Censored

    Joe-Censored

    Joined:
    Mar 26, 2013
    Posts:
    11,847
    Yeah I know, the problem is though how it usually works at midsize+ companies is the person who initially gets the bug report actually isn't someone who will be helping with solving it. They may not even be all that well versed with the product's technical side, often more involved with customer relations than development of the product. When they get the bug their job is to simply assign a severity and assign it to the right team. The QA members on that team will be the first people to actually try to reproduce that issue.

    Here's a scenario I've seen several times. A clearly described in the title bug gets filed, it gets assigned to my team the same day the customer filed it, it gets reproduced within a few days of it hitting our new bug list, I talk to the developer I know who is currently working on that part of the code anyway, and he goes "oh dang, on it" and squeezes in a fix for it that goes out in the next release a few weeks later.

    Then 2 months later another bug comes in with no title or description about its issue, but has a filed date of 6 months ago (in its history I see it has been assigned to another unrelated team, then sat a month, and reassigned to my team). I look through the repro steps and think "hmmm this seems sure familiar" and go back through my own history and find the bug from 2 months ago, and sure enough it is the same issue for the same version, but filed 4 months earlier. It ends up getting closed as a duplicate of the 2 month old bug, and even though the issue was reported quickly, my team wasn't aware of the issue until 4 months after the first instance was even filed, just due to the field people not directing the bug to us in a timely manner, but they had no idea it was supposed to be sent to us because they didn't understand what the bug actually meant.

    Sucks but that is the reality of QA and customer reported issues. :(
     
    angrypenguin likes this.
  12. Xtro

    Xtro

    Joined:
    Apr 17, 2013
    Posts:
    608
    I understand the scenario you provided. Thank you for very detailed example.
     
    Joe-Censored likes this.
  13. Xtro

    Xtro

    Joined:
    Apr 17, 2013
    Posts:
    608
  14. Xtro

    Xtro

    Joined:
    Apr 17, 2013
    Posts:
    608
    The second bug is fixed in 2018.3.8.