x

Search in
Sort by:

Question Status:

Search help

  • Simple searches use one or more words. Separate the words with spaces (cat dog) to search cat,dog or both. Separate the words with plus signs (cat +dog) to search for items that may contain cat but must contain dog.
  • You can further refine your search on the search results page, where you can search by keywords, author, topic. These can be combined with each other. Examples
    • cat dog --matches anything with cat,dog or both
    • cat +dog --searches for cat +dog where dog is a mandatory term
    • cat -dog -- searches for cat excluding any result containing dog
    • [cats] —will restrict your search to results with topic named "cats"
    • [cats] [dogs] —will restrict your search to results with both topics, "cats", and "dogs"

Modifying C++ Base Class Resets Derived Blueprint's Variables to Default after Editor Compile

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:

  1. Launch 4.18.1 and create a new C++ 2D Side Scroller project

  2. Open the visual studio project from the Unreal Editor if it is not already open. I'm using Visual Studio 2015.

  3. Open MyProjectCharacter.h

  4. Add a public member variable with a UPROPERTY
    UPROPERTY(Category = "Test Variables", EditAnywhere, BlueprintReadOnly)
    int m_nTestVar UMETA(DisplayName = "Test Var");

  5. Open MyProjectCharacter.cpp

  6. Initialize m_nTestVar to 0 in AMyProjectCharacter's constructor

  7. Go to the Unreal editor and compile

  8. In the World Outliner tab select TP_2DSideScrollerCharacter

  9. In the Details tab, find the Test Variables category and set Test Var to a non-zero number

  10. In the editor, File > Save All

  11. 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");

  12. Go to the Unreal editor and compile

  13. Test Var is reset to its default value.

If the above steps do not reset the value then follow the next steps:

  1. 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

  2. Go to the Unreal editor and compile.

  3. 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.

Product Version: UE 4.18
Tags:
more ▼

asked Nov 19 '17 at 11:11 PM in Bug Reports

avatar image

Hoboic
86 2 3 5

avatar image Orakga Apr 24 '18 at 08:53 PM

I'm also nervous that I'll reset my BP parameters by accident one day. But, for me, I've found that closing and reopening the Editor does the trick.

BTW, the steps shown by others in this thread involve compiling in VS, then opening the Editor, but what I do is:

1) Make changes in C++

2) Compile IN EDITOR

3) Close & Reopen Editor

4) Be happy

I'm not sure if there's a benefit to compiling from VS instead (I keep it at Development Server setting), but so far this workflow seems to work.

I hope this helps.

p.s. I didn't mean to add this comment all the way at the top! My apologies!!

avatar image AssemblerJohn Apr 25 '18 at 04:23 AM

Yea, we already know that workaround. It is kinda stinky especially when developing. We are waiting for a proper workout, since the current workaround (that you already pointed out) really stinks.

(comments are locked)
10|2000 characters needed characters left

5 answers: sort voted first

resetting the parameters each time is caused lose time to someones who have a huge project like me. i hope this issue will be resolved as soon as possible.

more ▼

answered Mar 14 '18 at 03:59 PM

avatar image

erdalt
36 1 3 5

avatar image AssemblerJohn Mar 15 '18 at 08:59 AM

Yes, if you base your code upon C++ and not get the data from anywhere else but store it in blueprints it can be quite a project-killer. Don't forget to vote for it.

(comments are locked)
10|2000 characters needed characters left

Hey Hoboic-

This is a known issue that has been reported here: https://issues.unrealengine.com/issue/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.

Cheers

Doug E

more ▼

answered Nov 20 '17 at 02:09 PM

avatar image AssemblerJohn Nov 21 '17 at 10:24 AM

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.

avatar image Doug E ♦♦ STAFF Nov 21 '17 at 12:59 PM

Yes, closing the editor before compiling (avoiding the hot reload process) will compile the code without affecting variable values.

avatar image AssemblerJohn Nov 21 '17 at 01:14 PM

Compiling it inside VS manually and starting the editor after would work? Am I correct?

And is there any way to disable code hot reloading?

Thanks a lot!

avatar image Doug E ♦♦ STAFF Nov 21 '17 at 02:08 PM

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.

avatar image AssemblerJohn Nov 21 '17 at 02:17 PM

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.

avatar image Hoboic Nov 22 '17 at 04:43 AM

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.

avatar image AssemblerJohn Nov 22 '17 at 06:56 AM

Hey,

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:

  1. Open VS(from it's project list NOT UE!)

  2. Compile inside VS with the editor closed

  3. Open the editor, the changes should appear and the data is not lost

  4. 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.

avatar image Hoboic Nov 23 '17 at 03:58 AM

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

  1. Make a change to the base C++ class in VS with UE open.

  2. Compile in UE.

  3. Close UE

  4. Go to project directory TestProj\Binaries\Win64

  5. 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.

  6. Open UE

  7. A popup stating
    The following modules are missing or built with a different engine version: ...
    will appear. Click Yes to rebuild.

  8. The blueprints regain there old saved values and have the update from the c++ base class.

This lets me recover something at least.

avatar image AssemblerJohn Nov 23 '17 at 06:10 AM

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.

Let's hope that in 4.20 we'll have a fix :)

avatar image Doug E ♦♦ STAFF Nov 21 '17 at 02:21 PM

I'm not sure I understand your question. Can you elaborate on what you're trying to accomplish, please?

avatar image AssemblerJohn Nov 21 '17 at 02:28 PM

Sorry for being unclear.

  1. Thank you for the workaround, it is usable for the moment.

  2. 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 hope everything is clear now.

avatar image Mishok43 Jan 28 '18 at 09:09 PM

Any updates?

avatar image AssemblerJohn Jan 29 '18 at 08:09 AM

The issue is still 'unresolved'. https://issues.unrealengine.com/issue/UE-52220

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.

avatar image CHADALAK1 Feb 23 '18 at 11:43 PM

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

avatar image AssemblerJohn Feb 27 '18 at 08:52 AM

Yea, it's weird this is not handled. I wonder all the guys that use UE have their variables in the Blueprint side of things?

avatar image Zoin Mar 02 '18 at 06:49 PM

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:

avatar image AssemblerJohn Mar 03 '18 at 06:04 AM

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.

avatar image Zoin Apr 24 '18 at 09:16 PM

Im guessing this is without actually saving the blueprint in editor then after compiling yeah ?

So a simple restart of the editor pretty much resets the values.. I guess that actually kind of makes sense.

Still annoying though lol

avatar image Orakga Apr 24 '18 at 10:03 PM

Yeah, for the love of god DON'T SAVE IN EDITOR AFTER THE COMPILE!!

(that's what I was referring to when I said I'm afraid I'll reset it by accident, permanently ^^)

avatar image norlin Mar 11 '18 at 06:57 PM

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.

avatar image toxicg0d Mar 20 '18 at 05:57 AM

Can we get an update as to whether this is going to get resolved or not? This is causing huge workflow issues for me. Thanks.

Edit: What version of Unreal is not suffering from this bug?

avatar image AssemblerJohn Mar 20 '18 at 07:12 AM

Don't forget to vote, the issue will be prioritized. Let's hope that it will be fixed, since yea, it's a project buster.

avatar image arrpeatwo4 Mar 30 '18 at 01:34 AM

I can confirm that I'm seeing this issue too on 4.19. I've voted for the issue, but the response of "it may not be prioritized or fixed soon" is disconcerting at best. Using C++ base classes and exposing variable to blueprints is the Epic recommended workflow for development, and having to close the editor for each compilation to prevent the Hot Reload from hard resetting all values on every instance seems a bit more than cumbersome. Frankly, this seems like a major issue.

avatar image AssemblerJohn Mar 30 '18 at 05:03 AM

Yes, it quite major, I'm amazed too that this is not handled. However with the current state at epic (AAA game canceled and such) I'm not sure this is prioritized.

avatar image arrpeatwo4 Mar 30 '18 at 02:28 PM

Just for reference, it may be worth following, and adding comments to the official AnswerHUB bug that's related to the ticket number the Staff Member referenced. It'll consolidate complaints and responses so that this issue gets the attention it deserves. Here's the thread:

https://answers.unrealengine.com/questions/716906/warning-reference-will-be-nullptred-bug.html

and the original thread that the reporting user started:

https://answers.unrealengine.com/questions/716269/warning-reference-will-be-nullptred.html

avatar image AssemblerJohn Mar 31 '18 at 05:55 AM

Isn't this officially followed too?

avatar image arrpeatwo4 Mar 31 '18 at 01:13 PM

I'm not sure, I found this thread via a Google search (it happened to be the top hit). However going through the bug report, I was only able to see the issue that I linked above. I could be wrong about this, but that's what I found in my brief search.

(comments are locked)
10|2000 characters needed characters left

FYI, the fix will make it into the 4.20 release, but the community staffer (Steve Robb) posted Epic's software fix for us to implement in his answer to resolve the issue on the current version.

Here is his answer:

https://answers.unrealengine.com/questions/716906/warning-reference-will-be-nullptred-bug.html

more ▼

answered May 15 '18 at 03:57 PM

avatar image

arrpeatwo4
171 2 3 7

(comments are locked)
10|2000 characters needed characters left

Still present in 4.21, from what I can tell. I voted for the issue (it is still marked unresolved) although at this point I'm not sure if that will get the job done.

Wouldn't this be one of the most important things to fix? In essence you can't develop with C++ in a productive manner. Wasn't the point of UE4 for everyone to develop in C++ so as to increase productivity? It seems to me hot-reload was developed specifically for this purpose.

I'm also experiencing another issue that might or might not be related. When hot-reloading components created in C++, has anyone experienced every instance of the component class becoming "linked" into one and the same? It would seem they all are the same instance, and some kind of archetypical instance at that. The yellow "revert" arrows disappear and changing one component's properties changes that property on all components of the same class, as well as the base value of that property on components of that class that are newly created or that have been created after the most recent hot-reload. Saving appears to actually persist this "linkage" across editor sessions.

more ▼

answered Nov 24 '18 at 12:46 AM

avatar image

Nicate
21 1 4

avatar image Nicate Nov 27 '18 at 02:22 PM

I have submitted a bug report for my additional issue. It might be related in some way, but it's hard to tell.

avatar image Nicate Dec 06 '18 at 04:27 AM
avatar image AssemblerJohn Dec 08 '18 at 09:23 AM

I could not find the issue you have submitted. Maybe it was merged with the existing one?

avatar image Nicate Dec 08 '18 at 04:18 PM

Looks like AnswerHub included the trailing period as part of the URL, lol. I'll try and fix it.

(comments are locked)
10|2000 characters needed characters left

For anyone who this is still annoying, after waiting for 3 versions of unreal, I decided to try and track it down myself :)

My fix is here: https://answers.unrealengine.com/questions/716906/warning-reference-will-be-nullptred-bug.html

Fairly new to unreal, and quite busy so not sure what the right procedure is for getting the fix in - hopefully they monitor those?

Anyway, hopefully that helps people

-Chris

more ▼

answered May 11 '18 at 11:42 AM

avatar image

chriscummings
76 1 2

avatar image AssemblerJohn May 11 '18 at 03:15 PM

Thanks for the diligence man! However I'd like it to have a little bit of 'time stress testing' like a few weeks before rolling it in. We never know what uncommenting that piece of code might do. Did you encountered any problems till now?

(comments are locked)
10|2000 characters needed characters left
Your answer
toggle preview:

Up to 5 attachments (including images) can be used with a maximum of 5.2 MB each and 5.2 MB total.

Follow this question

Once you sign in you will be able to subscribe for any updates here

Answers to this question