4.11 Child blueprint variables resetting to parent defaults
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 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.
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.
(Edits for spelling and grammar.)
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
answered May 10 '16 at 07:15 PM
Sean L ♦♦ STAFF
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.
answered Feb 07 '17 at 03:43 AM
Follow this question
Once you sign in you will be able to subscribe for any updates here