Why do some of my blueprints get reset?

Hi pzea,

What values should I be looking at, what should they be set to and what are they resetting to specifically. I took a look through some of your animation blueprints, however thus far I’m not seeing any errors. What do I need to do specifically to reproduce this on my end?

Hi ,

bug with values being reset isn’t something that I can reproduce. It’s just something that happens from time to time. I’ll start editor up and then realize that values on my monster characters, M2 and M3 for example, have their variables reset. For example M2 has a MaxHealth value of 95. This would get reset to 100 along with other Base Stat variables being reset. All of animation sequence variables in character would get reset making character not work at all.

What does happen every single time I start editor or every time I make a decent amount of changes to MonsterBase blueprint, is that Animation Blueprints of M2 and M3 get bugged out until you recompile them.

This is what I see when I start editor and press play. As you can see, monsters on left and right have big heads. Also both of them will not have any idle or walking animations.

This is what anim blueprint, M2_AB, looks like when I open it. head is big because it’s not properly reading growthscale variable from pawn. It’s also not animating.

Here is what it looks like after I compile anim blueprint. head is now scaled correctly and it is also playing its idle animation here.

In-game, you can see head is scaled correctly and animations are all working. monster on left still has issue and that will go away when I recompile its anim blueprint. I can also recompile parent blueprint that they both share which will fix both of those monster’s anim blueprints at once.

This bug occurs because M2_AB and M3_AB are both anim blueprints which are children to Monster_AB which is parent animation blueprint. reason that monster isn’t bugged is because it uses Monster_AB as its anim blueprint.

From your response though, it seems you are not experiencing this bug since you said that everything worked fine right away. Wonder what’s going on. I hope these images helped explain problem.

Hi pzea,

I am still looking into this error. Unfortunately animBP reset has been difficult to track down, variable reset bug has not reproduced on my end as of yet, even after multiple crashes. If you come up with specific repro steps while I am looking into this error, please comment with steps here.

I also have this same issue. Unfortunately, I’m not going to be able to upload a copy of project, it is way to huge at this point and I have a limited bandwidth internet plan.

Some structural details are:

  • Base c++ class called ‘ItemBase’
  • Child blueprint ‘ItemMaster’ based off ItemBase with added variables, for example ‘IsStackable’
  • Child blueprint base of ItemMaster called, for example ‘BasicArrow’.
  • BasicArrow is Stackable, so its default IsStackable set to True, which is not a default.

So on occasion, with no crash being necessary, this value gets set back to False without cause or explanation.

But this happens with many blueprints and numerous settings. Which becomes difficult to manage with over 50 items and about 20 settings that will randomly reset themselves, effectively breaking game, and then about 45-60 minutes going through and setting each value back to what it is supposed to be. About 100 additional items need to be created from this as development progresses.

But most horrible part is that sometimes when creating a test packaged game, these values can get ‘reset’, making entire packaged game unusable.

I wish I had more info to give, but there is nothing in logs or anywhere else I can see how/why this is happening. I’ve cleared caches and intermediate files/directories and like, to no permanent fix.

biggest problem is that this happens intermittently. Is there any info you could provide or things for me to check that I could maybe somehow intercept or log when it occurs that I could get some further info that you could use to track down this intermittent yet definite issue?

  • I don’t have any specific steps to reproduce issue, other than to be sure to subclass way I described above
  • Happens in v 4.9.2 I haven’t reproduced in a clean project, but I don’t see anything so unique about my project that it wouldn’t happen in a
    clean one
  • I’ll try to upload some logs next time it happens, but I’ve looked through them myself and there is nothing to indicate any issue there, they are all pretty clean

Thanks for any input you might have on this issue!

Hi ,

Have you been able to get this to occur again? If so, could you upload logs so I may take a look?

Hi pzea,

We have not heard from you in several days. I am marking this as answered for tracking purposes. If you are still experiencing this error, please comment back with updated reproduction steps.

hello , i suffer from same bug in two of my project, one project was made with ue4.8 and new one made with 4.10

here is my answerhub topicanswers.unrealengine.com/questions/388113/child-actor-properties-placed-in-level-are-reset-t.html

we need to fix this, how can i help you?

this impact child blueprint placed in level, and i have tons of child blueprint placed… :frowning: so when editor crash and value are reset… i have to redo all value this is killing me, really ! i want to cry

i comment this because i suffer from this problem too, in two of my project:

hello , i suffer from same bug
in two of my project, one project was
made with ue4.8 and new one made
with 4.10

here is my answerhub topic
Child actor properties placed in level are reset to default on editor crash - Programming & Scripting - Epic Developer Community Forums

we need to fix this, how can i help
you?

this impact child blueprint placed in
level, and i have tons of child
blueprint placed… :frowning: so when
editor crash and value are
reset… i have to redo all value
this is killing me, really ! i want to
cry

Hi ,

I’ll be happy to look into your answerhub post. I will post on it once I have read over what you’ve read. I will re-mark this one as answered for tracking purposes.