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âŚ
