I made a simple 3D game with C++ and I got some question : Do I have to destroy a blueprint link to a C++ code every time I change the C++ code. I explain
I made a 3D character with this instruction : AutoPossessPlayer = EAutoReceiveInput::Player0 on C++ . That mean I can control the character and not the camera. I create an Blueprint object from this C++ code and made some stuff.
Now I decide to remove this control so I remove the line above about the AutoPossessPlayer, I build the code and now I should be able to move the camera and not the player but this modification is not active. So I destroy the blueprint and create another one and now the modification is active.
So my question is : Do I have to destroy the blueprint every time I modify my C++ code and if not how can I update my blueprint object with the modificaion on C++ side ?
Sometimes hot-reloading simply won’t work, no matter how much you try.
Then you have to close/re-open the editor.
This is something Unity is miles ahead of UE4’s workflow because of .NET/Mono layer.
Ok it’s an editor issue,
Thanks next time I will will avoid to destroy my blueprint entities
This issue is causing me a lot of headach , here is how I do in my projects
Go to your Blueprint->Class Setting and select you c++ parent class again , then compile
This is definitely an annoyance, though minor. If I make a change in C++ and then go in to my blueprint, I will see the little arrow button telling me that the blueprint value is different than the parent, and I can reset it by clicking it. I haven’t dug into the source on this one yet, because as I said it’s only a minor annoyance, but I’m guessing it is because the blueprint is saving its state for all values, even the ones you haven’t overridden manually and are inherited from the C++ class, so when the underlying code changes, it does the diff ‘correctly’ because it only knows the current blueprint state and doesn’t have any way to understand how they got set. Switching to saving only overridden data would fix this, but I bet there are implications for blueprint performance for that.