Announcement

Collapse
No announcement yet.

[SURVEY] There's A Really Really Terrible Bug Where Child Blueprints Get Their Variables Reset

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

    Originally posted by JoeWintergreen View Post
    These days I sidestep this problem by using data tables, which everyone should be doing anyway. Do it!
    For me it happens if I reference my class in a data table. Somehow it just appeared for no reason and then suddenly disappeared just to come back few days later.

    I feel like if you can't repro it then you should refactor it. Clearly the data we lose is still here in the uasset, it's just not loading properly. But who am I anyway
    Last edited by rincewindk; 03-02-2019, 04:58 PM.

    Comment


      I also lose data many many times, it's the most annoying thing. You carefully set some transform only to find out that you lose them after a compile, a restart or whatever. Shame this still happens in the otherwise fine engine.

      Comment


        Just throwing in my voice that this nasty bug has effected me too.

        Comment


          Hey gang,

          First, I just wanted to surface some fixes in this area. This thread dates back to 2017 so the list won't be exhaustive, but here is a summary of work I did in the 4.21/4.22 timeframe:

          4078822 - During reinstancing we started reusing the subobjects that were already contained in a uobject, this fixed a wide category of bugs involving data loss in nested objects (UE-59135)
          4433763 - Added a call to resolve some object instances that were loaded as placeholder values that were not always being resolved (UE-62928)
          4454677 - Fixed loss of attachment information when repeatedly compiling blueprints that have compile errors (UE-64816)
          4525227 - Fixed for issue during reinstancing that could cause attachment information to be lost (UE-66020)
          4516935 - Removed some legacy compilation logic that could cause ClassDefaults to be overwritten - the only known repro of this data loss bug involved nativizing blueprints (UE-65011)
          4703596 - Fixed logic error in reinstancer that resulted in new versions of objects often not having their references updated, resulting in lost object references during compile (UE-68249)
          4746847 - Included the old version of the 'ClassDefaultObject' in the reinstancing map, so that references to this object are updated during reinstancing rather than cleared, done at the request of a licensee (also required 5696482, a change slated for 4.22.1 hotfix)
          4815337 - Fixed crashes and data loss that occur when reloading a blueprint that has child types already loaded (UE-58685)

          Other engineers have contributed fixes in this area as well! Please reach out if you even think that you have a way to reproduce a data loss issue - a new thread here, on answerhub or in the BP forum is an efficient way, but if you have sensitive assets a private message to myself is a great avenue.

          Fix velocity in this area has been trending downward after some unfortunate regressions related to the blueprint compilation manager so internally we think we've made strides on the editor data loss front. Our best practices may contribute: in general we try to avoid deep UObject hierarchies (both in terms of subobjects and class hierarchy) and strive to avoid strongly coupling assets at all, mainly because it slows down refactoring and iteration.

          We definitely understand that it isn't always possible to nail down a repro so feel free to continue discussion here, but also keep in mind that as the above list indicates you may be encountering similar but ultimately different bugs. Don't be shy about starting new threads or messaging me with your repro.

          Edit: also I'll take the chance to plug this bug submission form
          Last edited by Dan.OConnor; 04-17-2019, 08:32 PM.

          Comment


            Thanks Dan, I really appreciate you taking the time to update us in the thread!
            Personally I've been less affected by this in recent years since it pushed me toward more data-driven approaches where the data I was losing before is now no longer stored in the class itself, and I use inheritance less in general. Basically hiding my data in places where BP bugs couldn't clear it lead me to discover better ways of doing things.
            Impromptu Games|dev blog|twitter|itch.io store|Patreon
            Impromptu Procedural Ladders|Impromptu Procedural Handrails|Impromptu Procedural Stairs
            |Impromptu Fire Propagation|InFlux Example Game|Impromptu Vector Field Painter

            Comment


              I was just building a new project, where I was using inheritence from a base BP class, and had this crop up. Didn't know about it before. But The child instance I have in the scene which has a bunch of exposed variables, seems to be resetting them.

              Comment


                My actors are completely being reset as of 4.22.3. Pawns, Door Blueprints they are all reverting to 0,0,0 for their location and rotation you can view it occurring randomly on my devs twitch stream we'll go in to load a level and the actors are completely all gone and reset to a new position. The new position always be 0,0,0 this is completely new
                Last edited by Dark583; 08-04-2019, 05:15 PM.
                Cepheus Protocol
                recruitment@halcyonwinds.com

                Comment


                  My particleSystem are being reset as of 4.22.3. If i manage to reproduce this random bug, i will open a thread here.
                  Last edited by zincr0; 08-05-2019, 04:18 PM.

                  Comment


                    4.22.0, source built. Ran into this bug for the first time. An edit of a blueprint(namely deletion of 1 unused event) that has several child actor BPs, triggered reset of templates on all of them.

                    Comment


                      I was running Unreal 4.18 until I encountered this bug on my personal project. I migrated all my assets to 4.23.1 In hopes that the newer version would be more stable but I still ran into the issue after a single day of dev. The bug manifested itself after relaunching the engine but has also been encountered previously mid session. All variables on child have been rolled back to 0.

                      Running into such a major issue makes me wonder how we actually deal with that in larger productions (I use unreal at work). I would guess a solution for that already exist in bigger studio. Have you ever reached out to devs to know if they encountered that? I don't see how a major production could live with such a bug.

                      Hopefully this gets resolved at some point.

                      Comment


                        I also always get a specific Blueprint (and all its Children) reseted, every time i close the Engine. This is super frustrating, when you have to redo your Items over and over.....

                        Comment


                          I've manage to get a repro rate of 100% with specific steps.

                          The bugs is due to the map and not the actual blueprint itself on my end.

                          Once the child is placed inside the problematic map saved and relaunched its variables get reseted to 0.

                          But as long as the child is not placed inside the corrupted map the issue doesn't happend on save and reload.

                          Gladly the map that was corrupted was a simple showroom where I tested mechanics and the amount of work lost is manageable.

                          I hope this helps other who encounter the issue.

                          Repro steps:
                          Open project MR_Potato_423
                          Load map L00_ShowRoom_01
                          Create a Bp child from BP_Creature
                          Name it BP_Creature_Test
                          Inside BP_Creature_Test change the static skeletal mesh material to Crycrow_evo01
                          Save all
                          Close the engine
                          Open unreal
                          Reload the project
                          Place the BP Inside the world
                          All variables have been set back to 0

                          Comment


                            I had the same problem on UE 4.24. One of the components in the blueprint would loose all properties on editor restart. Also, when changing properties the editor would not see it as a change that requires re-saving the blueprint. The component was written in C++ and the blueprint derived from a C++ class (inherting from UObject).

                            I found the solution for my case - it was caused by circular dependencies. The problematic component had a UPROPERTY field - pointer to its owning actor, which was initialized in BeginPlay(). So the actor would reference the component, the component would reference the actor and it repeats from there. The problem was occurring for all instances of the blueprint in the level and for the blueprint asset itself.

                            So I advice you all to check for such unnecessary UPROPERTY pointer fields in your classes. When you're sure that the pointer is valid and will outlive the component and requires no serialization - there is no need for UPROPERTY. A raw pointer is fine. Btw, a good warning from UE would be very useful.

                            Comment


                              Originally posted by DanielKrakowiak View Post
                              I had the same problem on UE 4.24. One of the components in the blueprint would loose all properties on editor restart. Also, when changing properties the editor would not see it as a change that requires re-saving the blueprint. The component was written in C++ and the blueprint derived from a C++ class (inherting from UObject).

                              I found the solution for my case - it was caused by circular dependencies. The problematic component had a UPROPERTY field - pointer to its owning actor, which was initialized in BeginPlay(). So the actor would reference the component, the component would reference the actor and it repeats from there. The problem was occurring for all instances of the blueprint in the level and for the blueprint asset itself.

                              So I advice you all to check for such unnecessary UPROPERTY pointer fields in your classes. When you're sure that the pointer is valid and will outlive the component and requires no serialization - there is no need for UPROPERTY. A raw pointer is fine. Btw, a good warning from UE would be very useful.
                              Just a heads up, the proper handling of this use-case is to use a TWeakObjPtr, not a raw pointer.

                              Comment


                                Originally posted by DamirH View Post

                                Just a heads up, the proper handling of this use-case is to use a TWeakObjPtr, not a raw pointer.
                                Yeah, but in that case even TWeakObjPtr is not needed. That's what I meant by "will outlive the component"- no need to be afraid that the owner will get deleted before the component.

                                Comment

                                Working...
                                X