4.11 Child blueprint variables resetting to parent defaults

The error:

Child blueprints variables resetting to their parent’s default values upon opening the editor. The type of variables affected include floats, Booleans, vectors and enumerated variables (however the list is not exhaustive as not every variable type is used). Variables which are not inherited from the parent are not affected. It’s worth noting that the parents are custom blueprints and not default classes.
Only blueprints with custom blueprint parents which are placed into the level are affected by this issue, blueprints which are spawned into the level are unaffected.
The variables reset to default upon opening the editor.

It is import to note these variables do not reset to their parent’s defaults whilst the editor is in use, but only after closing and reopening it. Re-opening the level file will not cause it either, only closing and reopening the editor.

For us this is resetting our spawners, we have multiple different types of spawners but they all inherit from a generic spawner class that creates the variables for the maximum number of agents to spawn and the rate at which they are spawned. The generic spawner class also controls the actual spawning functionality, the children override the spawning function and add extra controls and behaviours to it.

The cause:

The cause for us appears to be editing and compiling the player blueprint, which is the pawn for our single player gamemode.

The process for replicating the error is as follows:

  1. Edit the Player Blueprint.
  2. Compile the Player Blueprint.
  3. Save the level.
  4. Close the editor.

The values in the variables which get reset can be set before or after the player blueprint is compiled, as long as the level itself is saved after the compile of the player blueprint the error will occur.

Editing the player blueprint, then saving it without a compile, saving the level and then closing and reopening the editor will not result in the error, even though the blueprint is automatically compiled upon reopening the editor.
I want to reiterate that this error only occurs upon reopening the editor and not upon opening the level (to test this I ran through stages 1 to 3 for replicating the error then opened another level and then re-opened the level I had just saved, the values were unchanged; when closing and reopening the editor the values in the level had reset to the parent’s defaults). This also only occurs for levels saved after the player’s blueprint has been compiled and not before, it occurs regardless of whether the level was open at the time of compiling the player blueprint, opening and then saving a level after the compile will result in the error.

Other tests:

Since the player blueprint is the pawn for our single player mode it occurred to me that maybe editing other blueprint that are part of the GameMode classes might also cause the error. I replicated stages 1 to 4 for the custom GameState, the PlayerController and the HUD blueprints, none of which caused the error. I also tested the GameInstance this also did not cause the error.

The game also has a spectator gamemode, so it occurred to me that running through stages 1 to 4 for the spectator pawn might also cause the error, it did not, even when the spectator gamemode was set as the current gamemode.
I also run through stages one to four on the player blueprint whilst the game mode for both the world and the project was set to the default and the error still occurred.

As the player blueprint inherits from the Character class I also ran through stages 1 to 4 on the enemy character (there’s only one in the game so far) as they also inherit from the Character class, this however did not cause the error. The enemy character actually inherits from a generic enemy class that inherits from the Character class, I tried editing both the generic enemy and the child enemy character blueprints, both of which failed to cause the error.


I’m at a bit of a loss really. Whist I know where the cause is and now how to replicate the error (it has taken two days of solid bug hunting to narrow this down), there doesn’t appear to be a specific link as to why this is the cause. Editing and compiling other blueprints in the game don’t appear to cause the error. At first this appeared to make sense as the player blueprint is the pawn for the gamemode which the level was using, but editing other pawns for other GameModes when they are in use failed to replicate the error.

In short there’s bug which is causing blueprints which have a custom parent blueprint and are placed into a level to reset to their parent’s default values when the player blueprint is edited and compile and then the level is saved, and the editor closed and reopened.


  • The player is spawned into the level by a PlayerStart Actor.
  • The project started as a UE 4.7 project.
  • The issue first became present when we updated the project to UE 4.10.0 and still persists in UE 4.11.2.

(Edits for spelling and grammar.)

It seems you stumbled upon a known yet unresolved bug:

Hi ZoltanE,

I have actually seen you’re original post before, I found it after we first started experiencing this issue; I had planned to post the content above as a reply to that post, but I couldn’t find it again yesterday at the time of posting.

I have a few other points to note about this issue as well.

  • I attempted mgreg’s solution by placing the parent of the affected blueprints into the level, this unfortunately did not resolve the issue.
  • The game does not need to be run in PIE to cause the issue.
  • The issue continues to be present in UE 4.12.0 preview 2 and I can still replicate the error by running through the 4 stages listed above (under the cause).
  • The issue only appears to be affecting blueprints with a custom blueprint parent which are placed as persistent actors in the level; and doesn’t affect blueprints with a custom blueprint parent which are spawned into the level at run time.

Currently we only have one blueprint placed in the level which inherits from a custom blueprint parent. When we have others I will post up whether or not the error also affects these.



We have been archiving the project twice a month since 10th September 2015. Opening the first archived version - in UE 4.9.2 - I was unable to replicate the error by running through stages 1 through 4. However updating a copy of that project to UE 4.11.2 I was able to successfully replicate the error.

It’s also worth noting that our spawners were completely rewritten in the last couple of months, so the blueprints affected in the updated archived build are not the same as the ones being affected now. But they do have similar behaviour i.e. they both spawn actors into the level.

The repro steps are great, I hope they will help Epic to track down the issue.

Hello Jules86,

Thank you for providing this additional information. Based on the issues linked in ZoltanE’s post that was provided, it seems that these are related. I will update the report with your information. This issue (UE-22557) is still being investigated by our developers.

Have a great day

Hi Sean,
Anytime, we’re glad to help. If we find anything else regarding this issue I’ll add it to this thread.

All the best.

I would like to voice that this is a huge issue for me as well. I have a parent class that has dozens of children, and they keep resetting. It is costing me a LOT of time. Please see if this bug fix can be expedited if possible. Serious issue for me and my team.

Thanks, Epic team!


This issue appears to have been resolved internally, and the fix will be available in a future release. If, after the release of the next version, you are still experiencing the issue, please reopen this thread and we can continue to investigate.

We are building the engine from source. Is there a change list we can integrate to get these fixes?

Thank you.


You can track this issue here: Unreal Engine Issues and Bug Tracker (UE-22557)

The fix was merged in as a part of a large group of fixes, which you can find here: https://github.com/spf0227/UnrealEngine/commit/73c6bbc883bbe773394a8e544333d04ddd4e1fc9

Have a great day

This is still happening in 4.12.

This is still happening in 4.12.

Hey Joe,

I just attempted to reproduce this in 4.13 P3 and got nowhere. Here’s what I did; you can tell me if I need to update my repro.

  • Made a Spawner BP class that spawns exploding spheres at a rate of 1/sec.
  • Made a child of that Spawner BP (Spawner_Child) that simply overrides the rate to 5/sec.
  • Just the child is in the level.
  • Restart editor.
  • Made edits to player, compile, save, restart editor.
  • Add/remove the BP from the level, restart editor
  • Add many copies of child to level, restart editor

Nothing reproduces a failure back to 1 spawn per second.

Also, UE-22557 is listed as fixed as of 4.13, not 4.12. It looks like we had a stack of fixes for BPs go in within that timeframe.

Here is the link to the issue so you can track it: Unreal Engine Issues and Bug Tracker (UE-22557)

It looks like we haven’t been able to reproduce it in 4.13, so give it a shot there and let me know if it’s still occurring.

It looks like this is now marked as can’t reproduce?

I am getting this (or similar) issue in 4.14
Specifically, a bp_actor_component has a (boolean) variable; bp_derived derives from bp_actor_component, then the bp_player_controller has two instances of bp_derived. One of these instances has the variable set to true. the other set to false (the default).

I think I found a culprit for why it is getting reset - or at least how to prevent it getting reset. In bp_actor_component (the base class) - I noticed that the variable does not have the ‘Editable’ flag set. Setting that seems to load the flag to the value I want, regardless of other steps (pie/compile/package/etc)

Some additional extremely odd information I noticed:

Open the editor. Diff against depot (bp_player_controller). Result: Components → No differences detected. Clicking on the actual component shows pre/post as True (not default)

Close Diff. Open bp_player_controller history. History is as expected: value is True, back to the checkin where I last fixed this issue occurring, then false to where it showed up.

Open bp_player_controller. Compile. Close bp_player_controller. Diff against depot. Result: Components-> variable changed value! This shows the local as true, and the depot value as false! (where they both showed true, above)

Going back in history shows the variable as false all the way to the creation of the component instance.

This probably just has to do with the implementation of the diff tool, though. Hopefully the ‘editable’ flag is what is important here, and I won’t see the problem again. Is this the intended usage of this flag? What would be the more appropriate feedback if that flag is not set, and designers toggle these flags in child blueprints? Any idea why it is intermittent, regarding whether the flag ends up getting reset?

I was unable to recreate the issue in a new project / new blueprint, but I didn’t spend a huge amount of time on it. This particular BP sequence has many editable vars, a few non-editable, most of which were public.


@VictorRachels: For whatever it’s worth, I get vars resetting on Blueprints regardless of whether they were Editable or not. Latest version.

I noticed you reset this to answered. Could you follow up on this? It’s still reproducing in 4.14, and the UE22557 is marked as CNR.

Could you provide the full set of repro steps that you are following to reproduce this in 4.14? If it’s different than the steps on the original ticket, we’ll need to get a new one entered. Issues will be marked as Cannot Reproduce if the original set of repro steps no longer causes the issue to occur, so this could be the case with this particular issue.


I get this issue into 4.15, and also in older versions, since a longer time. And it is much anoying to get all values resett