I’m experiencing an issue in 4.18.1 which causes blueprint variables to reset to default values in the editor when the base C++ class’s header file is changed with by adding a comment. The following steps always reproduce the issue:
Launch 4.18.1 and create a new C++ 2D Side Scroller project
Open the visual studio project from the Unreal Editor if it is not already open. I’m using Visual Studio 2015.
Open MyProjectCharacter.h
Add a public member variable with a UPROPERTY UPROPERTY(Category = "Test Variables", EditAnywhere, BlueprintReadOnly) int m_nTestVar UMETA(DisplayName = "Test Var");
Open MyProjectCharacter.cpp
Initialize m_nTestVar to 0 in AMyProjectCharacter’s constructor
Go to the Unreal editor and compile
In the World Outliner tab select TP_2DSideScrollerCharacter
In the Details tab, find the Test Variables category and set Test Var to a non-zero number
In the editor, File > Save All
In MyProjectCharacter.h, add a comment above the m_nTestVar’s UPROPERTY //A comment UPROPERTY(Category = "Test Variables", EditAnywhere, BlueprintReadOnly) int m_nTestVar UMETA(DisplayName = "Test Var");
Go to the Unreal editor and compile
Test Var is reset to its default value.
If the above steps do not reset the value then follow the next steps:
Add a second variable, m_nTestVar2, in MyProjectCharacter.h and initialize it to zero in the constructor as well. The exact same thing as m_nTestVar
Go to the Unreal editor and compile.
Test Var is reset to its default value.
I’ve tried these step in 4.16.3, and the issue does not exist in that older version. The variables always retain their blueprint value regardless of the number of comments and new variables I add the to base class’s header file.
Is 4.18.1 exhibiting the intended behavior or is this a bug? If this is intended, is there a way to retain the 4.16.3 behavior? 4.18.1 is not usable for me due to this issue.
This is a known issue that has been reported here: Unreal Engine Issues and Bug Tracker (UE-52220) . You can track the report’s status as the issue is reviewed by our development staff. Please be aware that this issue may not be prioritized or fixed soon.
Would there be any workaround? Like compiling form VS without any hotreloading or something? Since this is a pretty bad buster if you have to work with C++ extensively.
Yes, compiling from Visual Studio with the editor closed should work for you. There is no way to disable hot reloading. Hot reload is the process the editor uses to update code changes with the editor still open.
Great thanks a lot! But other people developing with a C++ back/end have encountered this right? There are a ton of games out there that depend on C++ rather than blueprints.
Thank you for the workaround, it is usable for the moment.
In my game (a RPG) we have a lot of NPCs with a C++ base class called ‘ARPGNPC’. Any time that I modify the base class all the blueprints that depend on that class get their data reset, and for a lot of NPCs that is very bad. I am sure that other people developing games usually use base C++ classes and have the same problem? And that would mean this problem is, maybe, higher on the priority list?
Anyway, another workaround would be storing per-NPC data for each of them in a separate database and load the info at runtime, so that it is not dependent on the blueprint settings. But again, that would mean adding the extra database layer instead of simply using the built-in blueprint system, and would mean more time/effort from the side of the programmers, and that is why I hoped for a unreal team fix.
I have just tested this, I made modifications to my C++ NPC class (added some field ‘bIsLoosingDataAgain’) and I’ve re-compiled with the editor and the data was not lost.
I’ve followed the steps:
Open VS(from it’s project list NOT UE!)
Compile inside VS with the editor closed
Open the editor, the changes should appear and the data is not lost
If you didn’t opened VS from UE you can’t press the compile button inside the editor or if you do no data is going to be updated. You have to restart the editor each time
I find this workaround quite cumbersome, tiring and hacky. I’m sure the guys at fortnite, paragon or senua really did not work like this.
Thanks for the responses. I tried compiling with the editor closed, then re-opening the editor. The derived blueprints did not contain any of the updates made to the c++ base class, in this case a new member variable. Proceeding to compile in the editor still reset all values, as expected, but did update the blueprints to have the new variable.
Is the part of the editor/engine responsible for updating blueprints accessible from github? If so, would you know which source files I should look at? If it’s not going to be fixed anytime soon I wouldn’t mind trying to fix it myself… or make it worse.
Currently the only feasible workaround is stay at version 4.16.3, which is not ideal in the long run.
Thanks for listing those steps. I was indeed opening VS from UE, which was one of the issues. The other was that my solution configuration was set to DebugGame Editor, which does not delete the old hot reload files, instead of Development Editor.
I’ll definitely forget to close the editor before compiling in the future.
Edit:
Found a workaround for accidentally compiling with the editor still open. For this example, I’m compiling for Win64 with the project name TestProj
Make a change to the base C++ class in VS with UE open.
Compile in UE.
Close UE
Go to project directory TestProj\Binaries\Win64
Delete the hot reload files in the naming format UE4Editor-TestProj-6760.dll UE4Editor-TestProj-6760.pdb.
The -####, in this case -6760, indicate its a hot reload file. Do not delete the normal files in the naming format UE4Editor-TestProj.dll UE4Editor-TestProj.pdb.
Open UE
A popup stating The following modules are missing or built with a different engine version: …
will appear. Click Yes to rebuild.
The blueprints regain there old saved values and have the update from the c++ base class.
Well, it still implies the fact that you will have to open/close the editor and for a lot of C++ tweaks this can become cumbersome and you have to build 2 times.
It’s quite important, I wonder how other people using C++ with UE solve this, since for me it’s a key-feature. Maybe people have custom DB-s loading that data.
I have this issue as well. I would really prefer to be able to not have my values in BP from compiling in C++ to empty/default themselves. It’s been an annoyance for some time now in 4.18
Have you guys test 4.19 to see if its fixed there ? - I just noticed this issue myself, and even though I am still in the very beginning of my project, I’d see this becoming a major hindrance if someone forgets to close down the editor while compiling having all the properties reset to its default values if you’re using a lot of blueprints deriving from that class
Personally I like to keep my variables in C++ as I find it easier to manage there D:
Same here. The issue still seems to be unresolved, even though I think it’s quite important. I wonder every studio out there manages their variables in the blueprint side? I’d find it rather odd.
And yea, don’t forget to go to the issue and vote for it.
OMG how this is not resolved yet! Hopefully I have noticed the issue and was able to restore my blueprints from the version system, but it’s a blocker issue, actually.
