UPROPERTY value keeps resetting on every compile

I’m on 4.20.3.

I have a property exposed in C++ as follows:

UPROPERTY(EditDefaultsOnly)
TSubclassOf<AProjectile> ProjectileBlueprint;

This C++ class is inherited by a Blueprint class where I set this value to a AProjectile Blueprint class. The problem is this value resets to “None” every time I recompile, and I have to go into the Blueprint and set it again.

I’ve tried fixing this multiple by recreating the variables, and components, using different tags, moving it to private/public, but it always resets on every compile even if nothing changed in code.

Is this intended or am I doing something wrong?

1 Like

This does happen. After some research the general consensus seems to be that it won’t happen if you close the editor before compiling.

Also, if i recall, this usually happens if your c++ class is derived from object.h

That is pretty much a “permanent bug”.

2 Likes

I see. Does this happen for all versions of UE4? Seems to be a huge drag to be making sure I have the editor closed before compiling, and then having to reopen the editor again.

1 Like

Yes.

Also happens randomly with blueprint classes that are children of other blueprint classes, though no definite answer on what triggers that.

I typically set my variables in a Data Table and initialize them in my construction script or onBeginPlay. It’s a real pain and semi-complicated process.

It’s a known issue with TSubclassOf variables unfortunately. I raised this a while ago and it’s been on the Issues forum since 4.17… apparently it’s no longer occurring in 4.21

Feel free to bump this thread if needs be.
https://forums.unrealengine.com/unre…uled-for-a-fix

The issue isn’t specific to TSubclassOf. Whenever you change a header file while the editor is open, all exposed uproperties of the class revert to default.
UE-52220 has been around for more than a year and it’s first thing I look for with every update.
I don’t know how epic devs work without hotreload because it really destroys productivity.

Is there any way to disable hot reload or is that moot at this point? How has everyone been able to develop with this bug up to now?

Seems like this is a workflow killer or a massive headache unless everyone is just avoiding exposing properties for blueprint totally.

1 Like

Seems like it’s pointer UPROPERTY()'s that get reset then - I haven’t experienced much of that.

You wouldn’t disable hot reload, you just have to restart the project from visual studio. My projects always open pretty quickly, and I haven’t ever trusted hot reload anyway aside from making small CPP changes so I don’t really feel the effects of it.

Live++ works relatively well and it’s way faster. Only works so long as you don’t make changes that require UHT to run though.

What version are you on TheJamsh?

I’m actually also experiencing other non UPROPERTY values being reset like static meshs, and physics properties. It’s such a time waster to have to hunt down reset values every time there’s a recompile with the Editor running.

4.19 / 4.20 here - but in all honesty I rarely ever use hot reload - only when I’m tweaking or fine-tuning properties. Half the time I find it’s quicker to restart the project and load up a test map then wait for HR to finish :confused:

What kind of iteration times do you get with Live++ ?

This is still definitely happening as of 4.21.1 (Version: 4.21.1-4613538+++UE4+Release-4.21). All I need to do is close and re-open the editor and the TSubclassOf variable is reset to None, every time. It doesn’t matter if I clean out binaries/intermediate, rebuild project files, etc. prior to opening the editor.

Doesn’t happen to me if I close and re-open the editor - but I have still seen it happen with Hot Reload.

If it’s happening on close and re-open only then that’s a new bug.

Problem is still here unfortunately :frowning:

SOLUTION!!!

Just wanted to share that I seems to have resolved this issue.

When you are making changes to not inherited components and facing issues similar to described above (Component does not save meshes, textures, materials, Projectile classes, etc.) you need to READD problematic component - AND (!) compile blueprint (class) on every step.

First time I tried it - it did not work for me because (I think) I have missed second step (Compile after deleting problematic component)

Also I have switched to 4.22 - this issue was still present before I have took steps above.

Take care everyone, and happy developing!

6 Likes

@arhiDavid Thanks! Your technique solves the problem :slight_smile:

1 Like

@arhiDavid Thanks mate

1 Like

Excuse me sir, i’ve tried your method but unfortunately this doesn’t work when packaging the project to windows, it gives the “PreSave: Null Widget Tree” problem
thus my solution was just putting default values in the cpp side using the
FObjectFinder method, if someone has a better solution please let me know so we can evolve our code to be more elegant and sufficient. :slight_smile:

1 Like

@arhiDavid Many thanks bud.

1 Like