Hey dude, for some reason I got an email ping after you linked my thread, so I might as well respond: I never got nativization working, it is buggy and probably not what you’re looking for. Not only that, but about 1 year later I ran into another issue with Blueprints where the project crashed at startup because of an issue related to the nativization issue.
I luckily solved that second issue and I think that was why nativization never worked, so let me try to explain real quick in case you are having the same issue. When you load a Blueprint, the engine creates “reference graphs” about what other Blueprints that specific Blueprint needs to know about. Say you have class A that is the world, Class B that is a campfire, and Class C that is the player. Now, you probably want the player to be able to sit near the campfire, so you might have a function that refers to the campfire in some way (Check what’s looked at → Cast to CampFire). In the same way, you might want the campfire to check for the player whenever someone steps on it (Cast To PlayerCharacter on Overlap) and hurt the player accordingly.
Now this is me taking a chance based on what went wrong for me, but I think with this little endeavour, you have now created a “cycle in the event graph”, as CampFire refers to PlayerCharacter and vice versa. To check this, open the Blueprint, go to Asset->SizeMap. This is what the engine needs to keep in memory in order to keep an instance of this Actor loaded. If you see two things referring to each other: Congratulations, you’ve found an issue that you should immediately stop doing in the future! The SizeMap should optimally ONLY show its own variables and not a huge cascade of references.
So how do B and C talk to each other? The answer is Interfaces. Interfaces don’t give a ■■■■ what the other object is, they call a function but only if they are on that object. You can create interfaces in both Blueprints and C++. They can also have return values, and if so they show up as functions. For example, create an interface for damage, and one function DealDamage: Input float DamageDealt, output bool DealtDamage. Go to PlayerCharacter->Class Settings->Interfaces → Add the DamageInterface to the character. Set up so when the campfire detects an overlap, it simply sends a message via the interface called “DealDamage”. For the CampFire, create an interface called PlayerInteraction or something and define in the Campfire what happens when it is interacted with. Also define that when the function returns true, that means we found something we can interact with, and do what is needed in the player character. If you’ve gotten to this point, you might be able to do the nativization, but more importantly: You won’t run into the wall I did where your project crashes at startup! (a much more serious issue)
Let me also clarify that this persist as long as there is any reference at all between these blueprints. A single local variable in a function creates a connection in the reference graph. these can sometimes be a pain to find and patch, so the earlier you get rid of this habit the better.
With all this in mind… I should also mention nativization is pretty buggy on its own, takes an incredibly long time to compile, and also can vastly affect performance (my loading times between levels tripled with nativization). It is not a replacement for writing proper C++ code. unless you’ve gotten very far on your game, I’d suggest trying to convert as much as possible to C++ base classes, then make the Blueprints child Blueprints off of that.
In short, if you got to this point, please check that you aren’t about to run into the issue I just had! Chances are you can’t use Nativization in the way you were hoping, but this is as far as I got and what I did to circumvent my issues. That’s all I can say, hope this helps in some way!
My original thread where I solved this issue: