Changing values in base class (C++) does not propagate to child Blueprint

Development Programming & Scripting Blueprint
, , , ,
1

Whenever I change a value in my C++ base class where I previously created a Blueprint child object for won’t update in said child Blueprint. This can cause very confusing and servere bugs when for example you enable replication in your C++ class, but it won’t actually replicate since your BP still has the old value.

2

Are you hot reloading? Or do you close the editor before compiling?

I also encountered such behaviour where changing components in C++ doesn’t affect the blueprints derived from it.

3

I think it happens in both scenarios, but yes I mostly do hotreloading. Can’t give a clear yes/no on that.

4

Do a full recompile (Rebuild Project) with the editor closed.

5

Hey Tom-

What type of variable are you trying to change in code and where in the code are you changing the value? I was able to create a class with a float variable that was set in the constructor. After creating a BP of the class I was able to change the value in the constructor which showed up in the blueprint after a hot reload. Are you setting the value at another point in the code class?

6

In my case it was setting bReplicates = true in the base class.

Class layout: C++ class (value changed here) > C++ class > Blueprint (did not update)

I added them in the constructor. The thing is that after hotreload the values were the original in the Blueprint, but they did how the “revert to default” option. So the engine knew it was no longer considered the default, yet it kept the original value which was supposed to have changed.

I hope that makes sense.

7

The problem here is that the blueprint should have taken on the new C++ value and it didn’t. What I tried to describe is that it seems that the blueprint had overwritten the value internally even if they are the same value before the change, so on the hotreload the blueprint believes it shouldn’t have to update itself, because we explicitly assigned a value in BP already (which is not the case) - Hope that makes any sense - it’s just a hunch on what I thought might be going on.

8

If you set a value in C++, in the constructor, it becomes the default in the Blueprint, so when you change the value in C++ the Blueprint will reflect that value if you set this as the default option in the blueprint, (the yellow arrow at the right must not appear).

9

You are right, I understand you now, if you only hotreload the code, the Blueprint will have the same selected parameter values as before, but its default will be the one you set on C++.
-If you set bReplicates=true on C++ and hotreload, the Blueprint will have selected the value you had before, but true will be its default. It will have a yellow arrow at the right of the toggle box.

If you compile the C++ code and open the editor, the values you have set on the constructor will be the selected on the blueprint as well (If you have set the parameter to its default).
-If you set bReplicates=true on C++ and compile from the code editor the Blueprint will have its value ‘Replicates’ set to true too.

So all of this changes will be reflected once you compile the code, not just hotreload it.

10

Hey -

I was able to verify that the default value of a boolean variable does not update when the default is changed in code. Since this behavior is inconsistent with the behavior of other variables types such as float I have entered a bug into our internal tracking database (UE-13304) for further investigation.

Cheers

11

Hi , I seem to have the same problem with floats as well (trying to change some simple camera defaults). I’ve tried both hot-reloading and doing a full recompile but no dice. any tips?

edit: I should add that creating a new blueprint based on the same class will take the changes, but existing ones will hold on to old values

12

Hey -

Just so I know I’m understanding correctly you’re saying that changing the value of a float in the class constructor does not update in a blueprint after a hot reload? Which version of the engine are you working in? Can you explain how your class and camera is setup in code. Do you see the yellow arrow indicating that the shown value is not the default value?

13

I realized after I posted this that changing a simple UPROPERTY float works fine, but trying to change a camera value, something like this:

CameraBoom->SocketOffset = FVector(0, 50, 0);
CameraBoom->TargetOffset = FVector(0, 0, 50);

does not work. This makes sense to me, I just didn’t realize it at the time

I am using 4.7.5

14

,

This seems to be a problem for a number of items not getting propagated to child blueprints. Just a few I’m coming across right now (but have had many more), StaticMeshComponents, rotations, scales, locations. Its almost as though the constructor is only ran once and never again in the child blueprint. I would create a new bug report but I am assuming it is same problem and would be relevant to UE-13304.

15

Hey -

This is an issue with hot reloading. If changes to code aren’t reflected after a hot reload, closing/reopening the project should update the blueprints with the code changes properly.

Cheers

16

Hi ,
Thanks for the response. Can I ask if this is this just an accepted reality or is the issue being worked? I asked because if this is just the way things are we are going to need to change our entire workflow. I can’t imagine this being the way things are expected to work or there would be little value in hot-reloading. The worst part is that it sometimes works as we can’t fine tune things because we never know if we need to reload the entire project or if we can hot reload. If it never worked then ok we can have a defined workflow that while not great we can rely on. Since it sometimes works we will tweak a value, no that value doesn’t look right, tweak again, again, then finally realize it isn’t loading our changes and then reload the project. Or worse yet think a change you made is fine and you check it in then your college opens the file up and you realized you messed something up and you don’t know where you messed it up.

17

Hot reload is intended to be used to speed up the compile process. I’ve entered a new bug report (UE-24892) to address certain values not updating properly on a hot reload for further investigation.

18

Thanks for the info and the bug report number.

19

I have seen that the issue UE-13304 is already solved but I still have a similar issue.

Specially with UTimelineComponent and the UFUNCTIONS that I bind.

20

Hey Bullyproof-

Since UE-13304 is already resolved, it’s likely that your issue is something different. It would be best to create a new post with as much information and details as possible to help us investigate your issue separately.