I am getting this in 4.13.1
I believe I have a repro. Will test with a clean project if I can find the time.
Here are my repro steps:
Make a UObject class and CreateDefaultSubobject that inside an Actor, such as Character. Have it be instanced. Use DefaultToInstanced if you like
Make another UObject class and CreateDefaultSubobject inside the UObject class you made in step 1. Have it be instanced. Use DefaultToInstanced if you like
Make a EditDefaultsOnly property inside the UObject class in step 2, maybe to an AnimMontage or something
Make a blueprint of that Actor in step 1. Set its property that you created in step 3
Make a child blueprint from the one you made in step 4. Note that it has inherited the property correctly
Save and then Close the editor
Open the editor. The property in the child blueprint from step 5 will be zeroed out
Also note that instances must rely on GetArchetype() to obtain the correct value of that property that was set by a human in data… at least this was the case with ones that came from a dynamically spawned Actor, such as an NPC that came from a spawner
This pattern is specifically the one we use for our StateMachines, which are UObjects that contain embedded UObject states with EditDefaultsOnly properties
I have attached a minimal repro project here:
[link text][1]
MyActorArchetype is the base Blueprint class from the C++ MyActor class.
That works fine.
Repro Steps:
MyActorArchetype_Child is a Blueprint derived from MyActorArchetype. Note that the FText MyProperty in it is blank.
Set it to defaults, compile the blueprint, and save, then close the editor.
Result:
A) When you reopen the editor, that FText field is blank again within the child blueprint. Its inherited value got lost.
B) In addition to loss of values within child blueprints, instances of the parent blueprint class, which is not inherited from any other blueprint, will have uninitialized properties and must rely on GetArchetype() to find the serialized values that were set by humans in data on that archetype.
Expected:
A) For inherited child properties of an instanced UObject to persist between editor sessions when embedded inside another instanced UObject
B) For properties within instanced UObjects to serialize into every other instance when embedded inside another instanced UObject.
Additional Notes:
i) Property values will not get lost if you set the child archetype’s property to something that does not match the parent’s.
ii) A workaround solution is to not embed UObjects within UObjects but instead, have the embedded UObject be sub-objects of the outer Actor (maybe outer component, too, but did not test that)
I’m not sure if this error and the one from polygon’s answer are the same bug we are having. Maybe the cause is the same, but i’m not sure. But it’s also very serious.
(You may be confused because the issue’s name says “duplicating”, but don’t worry, it’s just one of the ways this bug appears. It’s exactly the same issue that resets the properties when you reopen the editor.)
I shut the editor down last night after playing with AI. I also remember doing a few changes to one of the events on the weapons. Opened it up again this morning and all the children of the base class weapons have lost their data!
The weapons have all gone back to the values as set in there parent class, which is nothing.
The more weapons I have the more I have to toil to fix this. Am I expected to set every variable for every class every time the editor restarts? How does somebody even complete a game using this engine?
There was a comment I read ages ago about how somebody had to spend a good portion of time fixing things whenever they started the editor. I’m now in the same boat.
This original question is from 22 June 2015 - It’s now 03 November 2016 and this hasn’t been fixed… Come on Epic!
I don’t know why this is marked as solved too. But at least the issue is tracked now, you can upvote here: Unreal Engine Issues and Bug Tracker (UE-37428) and follow my tips below to avoid the issue while it’s not fixed.
This should not be marked resolved. This is driving me crazy in 4.13.2. I keep losing all of the configuration of blocks within my knock-down-the-blocks levels. I have repeatedly had to reconfigure all the blocks in my levels for no reason! GRRRR.
's workaround steps have worked for me so far. Compiling a blueprint that has configured instances in the currently-open level is dangerous! My simplified workaround (based on 's info below) is 1) Save level before working on blueprints, 2) After working on blueprints, restart engine without saving level.
Prototyping productivity is really crappy now, what with the need to shut down and restart the editor between every blueprint change.
I voted for UE-37428. I’m sad the target fix is 4.15. That’s a long ways away. Seems like blatant data-loss would be hotfix-worthy.
@AdamDavis gave some really good low-level finds in the parent comment. Has that been passed on to the developers?
Sounds like he found the symptom on the reading-in-of-the-data. Now we just have to find what is writing the incorrect FieldName out in the first place, eh?
So I have the same issue, I gues… 4.13.1 How to reproduce7 Eample - I have a child actor with an array of actors. it is puplic array. So I have to set all variables manually. but when i do any changes in the parent blueprint. my manually set variables come to none. I will keep searching the method to set actors befor game starts… but if this will help you to improve the bug…
Since two months I’m trying to understand this, to make better bug report but with no result. This issue occurs on realy simple basic c++ and BP actors. There’s nothing problematic in code.
Unreal, please help. This is realy serious problem and my work with this is realy hard if even posible.
Here is my fix that has worked so far in V13, using Blueprints. I am running tests to see if it will stick, but as people have observed, the reset seems to be random.
I have children derived from a base class. The blueprint is a pick up that can have the static mesh and variables changed in the editor, including variables that are sent off to the player’s UMG hud, an inventory, and audio.
I copy all the logic in the Parent blueprint’s construction script. Then, in the child’s constriction script, I paste the logic between the “Construction script” node, and the “Parent Construction script” node. How is that for a confusing sentence? But the fix has worked so far, and I can live with the extra work.
No, didn’t work after several restarts. I guess I have to make individual classes for each pickup, until build 4.x. I still love UE4 anyway, its still in dev, keep up the great work! -Ian
Here it is a month later, and the problem seems to have resolved. I have a pick up which casts to various blueprints, and needs to be configured with custom attributes, and they have “stuck”. The mission cube here can be configured the whole range of variables, casting to other BP’s and the UMG hud. So…stick with it, everyone who has this issue.
To reiterate; “I copy all the logic in the Parent blueprint’s construction script. Then, in the child’s constriction script, I paste the logic between the “Construction script” node, and the “Parent Construction script” node.” That is my fix. Does this defeat the purpose of a child BP? Partially I suppose, but since the issue is only for random cases, maybe its worth the loss of identical logic in Parent and child…
To reiterate; “I copy all the logic in the Parent blueprint’s construction script. Then, in the child’s constriction script, I paste the logic between the “Construction script” node, and the “Parent Construction script” node.” That is my fix. Does this defeat the purpose of a child BP? Partially I suppose, but since the issue is only for random cases, maybe its worth the loss of identical logic in Parent and child…
