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

    #46
    [MENTION=18585]akka[/MENTION]:

    You're genius! With your method I'm able to reproduce the bug 100% of the time! Hopefully Epic can confirm this and handle this issue finally. Thanks for your effort

    Best regards,
    Daniel

    EDIT:

    It seems to work even without the "GetAllActorsOfClass" node for me.
    Last edited by polygon; 05-22-2017, 04:09 AM.
    Daniel Mihajlovic |Freelance 3D Artist | Showreel

    Comment


      #47
      Hi akka,

      Thank you so much for posting this repro! I was able to finally reproduce the bug and I've been testing in different version.

      I was able to reproduce this in 4.15.2 and 4.16 Preview 3. However; I wasn't able to repro this in our internal version of 4.17.

      In his Forum post, Michael N explains the overhaul that was implemented that he believed should fix this issue. Thanks to your repro, we can confirm that it is indeed fixed for this use case. Hopefully everyone will see similar results when this version is released.

      I posted this on the AnswerHub thread as well.

      Cheers,

      TJ

      Comment


        #48
        Originally posted by polygon View Post
        [MENTION=18585]akka[/MENTION]:

        It seems to work even without the "GetAllActorsOfClass" node for me.
        Weird, I tested again and I definitely DO need to get all actors of class FirstPersonCharacter, although casting to the First Person Character blueprint reproduces the bug as well.

        Originally posted by TJ Ballard View Post
        I was able to reproduce this in 4.15.2 and 4.16 Preview 3. However; I wasn't able to repro this in our internal version of 4.17.
        Good to hear! I had to come up with a workaround to the issue but it's not ideal so I'll wait and see if it's resolved for me in 4.17.
        Last edited by akka; 05-22-2017, 04:17 PM.
        texturemax.com | @texturemax
        Marketplace: 100 Splatter Decals | 200+ Grunge Decals

        Comment


          #49
          Originally posted by akka View Post
          Weird, I tested again and I definitely DO need to get all actors of class FirstPersonCharacter, although casting to the First Person Character blueprint reproduces the bug as well.
          Thanks for testing this on your end I've done some more experiments and came to the following conclusion:

          You're right: It does NOT happen without the "GetAllActorsOfClass" node. In my initial test I did the repro exactly like you recommended. After that I disconnected the node instead of deleting it and the bug still showed up altough the node was disconnected. Then I created the whole setup from scratch without the node and the bug did not occur.
          So I think the blueprint gets corrupted as soon as the node is plugged in and stays corrupted even if you disconnect the execution pin. Pretty strange thing.

          And yep, I also can confirm that the bug happens if you use a cast node (Get Player Pawn -> Cast to FirstPersonCharacter)

          [MENTION=4891]TJ Ballard[/MENTION]:

          I'm just curious about the reason for this bug. Can you share some information why this happens?

          Best regards,
          Daniel
          Daniel Mihajlovic |Freelance 3D Artist | Showreel

          Comment


            #50
            Originally posted by polygon View Post
            I'm just curious about the reason for this bug. Can you share some information why this happens?
            +1... It'd be helpful to know if Epic have just sniped a fix to this specific case.
            Or whether this will catch all or some of the other bugs that were highlighted?

            Comment


              #51
              Hey polygon and franktech,

              We created a JIRA internally to figure out exactly why this was happening and make sure the compilation manager truly fixes it. We hope to have more info to share soon.

              Comment


                #52
                Hey everybody,

                It looks like 4.16.0 release version may fix some of these errors. It seems to have fixed the repro akka provided above. If anyone has time, please feel free to test it there and let me know what you get.

                If it's still happening, then we will likely have to see if the compilation manager in 4.17 fixes the issues.

                Comment


                  #53
                  I'm soooo glad I found this thread. Not because it's helpful for me in the moment, but this BUG caused me days worth of grief and SOOO much wasted time when adding a game mode to a large project recently. Worked fine in the editor until reopening the level. All of the BP's in the level were various children of a parent with a bunch of config vars that would change their behavior. Packaging the game and opening the level... all the bps would be reverted to parent's default! I'd spend two hours customizing each one in the level to function how it should... and bam all undone. After two or three times I got wiser and just edited one or two for testing.. never got a resolution (but i did make a workaround)

                  I reported the issue in answerhub and cited previous chains of people having the issue. But of course I ended up with the standard (maybe understandable but extremely frustrating) response of "if you can't reproduce it in a fresh project we can't help you". Well my last comment on the thread was "well I can't repro it in a fresh project... but its 100% a bug and its in the editor not in my code." Then its just been lodged in my brain as one of those annoying things that eat at you.

                  So I'm glad something is getting done about it finally. The repro steps I've seen above don't match my issue.. I didn't have a get all actors node and wasn't using a template of any kind.. but the issue is probably still the same. I've added ridiculous macros and pipe them into "begin play" that essentially just have every variable SET node i need to customize at runtime and then it sets them all on begin play.(setting in the editor panel doesnt resolve, i tried) Silly work around, and if you want to use const script to do this customization in the editor and see the updates real-time you're SOL.

                  Reference to my thread from a couple months back just as an FYI:

                  https://answers.unrealengine.com/que...en-reopen.html
                  Snap-In Systems: <<< CLICK
                  | Inventory (Battle Royale) |Smart Select Box | Ready Game Modes | Handy Macros | Gun Weapon System |Simple Mesh Outliner |

                  Comment


                    #54
                    We had a similar issue:
                    The skeletal mesh property of a Child BP would be reset to empty upon saving and closing the editor.
                    Reparenting to the c++ parent fixes the issue.
                    The weirdest part of the issue was that the uasset itself would not change.
                    Occured in 4.15.

                    Comment


                      #55
                      This is happening to my project in 4.16.2.
                      If I take all references to the parent, out of the animation blueprint , the children get the reference to the animation blueprint back on restart.
                      Same blueprints in a new project work fine.
                      I got this bug after a crash, when I was setting the animation blueprint in the child.

                      Comment


                        #56
                        Something similar happened to me with 4.16.1
                        Without changing anything related to the Blueprint in question, one of three pretty much equivalent child Blueprints lost its skeletal mesh reference every time I restarted the editor. The sibling Blueprints were fine.
                        The hierarchy was C++Class->BlueprintClass->BlueprintClass.
                        The reference viewer revealed that a Redirector had a reference to the Blueprint. Weirdly, even after deleting and recreating the Blueprint, the problem persisted until I deleted the Redirector.

                        After deleting the Redirector and the Blueprint and then recreating the Blueprint, the bug no longer occurred.

                        Maybe this is helpful.

                        Comment


                          #57
                          I've found that references to the child character breaks the childs mesh or animation reference or changed default settings(even in a new blueprint with no circular dependency).

                          I can , however, reference the children in an array in the parents blueprint(the only blueprint that will allow a reference to them) without this happening.

                          So my workaround is to pick up this array from the parent in the gamemode at runtime, and use it as a reference to the children . Seems to work so far.

                          Comment


                            #58
                            Originally posted by Praseodyl View Post
                            Something similar happened to me with 4.16.1
                            Without changing anything related to the Blueprint in question, one of three pretty much equivalent child Blueprints lost its skeletal mesh reference every time I restarted the editor. The sibling Blueprints were fine.
                            The hierarchy was C++Class->BlueprintClass->BlueprintClass.
                            The reference viewer revealed that a Redirector had a reference to the Blueprint. Weirdly, even after deleting and recreating the Blueprint, the problem persisted until I deleted the Redirector.

                            After deleting the Redirector and the Blueprint and then recreating the Blueprint, the bug no longer occurred.

                            Maybe this is helpful.
                            Yep, I think the bug is somehow related to the redirectors or at least can be caused by some redirector problems. Will the redirector system be improved in the upcoming releases? They seem to do some quite strange stuff from time to time ("Ghost" folders after deleting assets, empty and unused .uassets after deleting items from the content browser and so on)

                            Best regards,
                            Daniel
                            Daniel Mihajlovic |Freelance 3D Artist | Showreel

                            Comment


                              #59
                              [MENTION=14681]polygon[/MENTION], did you turn on 'show redirectors' and fix up the redirectors? Tiny 'ghost' .uasset files in a folder are redirectors that haven't been fixed up yet.

                              Cheers,
                              Michael Noland

                              Comment


                                #60
                                The 4.17 preview 1 build is available in the launcher now: https://forums.unrealengine.com/show...e-4-17-Preview

                                It includes a significant number of bug fixes and improvements to Blueprints and has resolved several repros for data loss we've gotten. There's no guarantee that your case will be fixed (many different issues have similar symptoms), but I'd recommend giving it a try *on a copy of your project* both to see if it works better for you and to catch any potential regressions before 4.17 final goes out (we did change a lot of things ^_^).

                                Note: You may see an increase in warnings or errors as part of 4.17; there will be more info in the upgrade section of the full release notes, but the summary is that we now catch and warn on various problems that either silently failed in previous releases or worked only intermittently (e.g., in uncooked but not in cooked builds). These warnings are much less likely to affect BP only projects or recent BP + C++ projects, but in long-running BP/C++ projects, there will almost certainly a be a few warnings about missing BlueprintType or BlueprintReadWrite, etc... Related to this, we also introduce the concept of orphaned pins which make refactoring issues easier to catch and recover from. As an example, if you rename a parameter on a function in BP 1 that was called by BP 2 and save 1 but don't save BP 2, then close and reopen the editor, BP 2 will now report an error about a missing parameter with the connection to the old pin preserved, rather than silently dropping the connection on the ground.

                                Cheers,
                                Michael Noland

                                Comment

                                Working...
                                X