Direct Answer To the Question:
So the BlueprintNativeEvent property is used to tell the Blueprint that a given function is optional to create within the Blueprint editor. If the given Blueprint function named, “function()” was called and it had no implementation, then the Blueprint would use the C++ class implementation named, “function_Implementation()” instead.
I think that BlueprintNativeEvents are a way of allowing Blueprints to override their C++ class implementation. For example, if you wanted to have two Blueprints based on the same C++ class there function named, “function()” could have two completely different blueprint implementations, but if you choose not to give them unique implementations then they could fallback to using the C++ class implementation.
Overall, I hope this makes BlueprintNativeEvents more clear . Although if you would like to see a more fleshed out example I would recommend checking out this link at C++ and Blueprints | Unreal Engine Documentation . The given link provides a complete example of transferring pure c++ code to becoming a Blueprint ready class.
Why Blueprint Native Event Are Useful (Extended Answer):
Firstly, I want to say that the question of, “Where can I use it?” or “When is this useful?” is often a long and complicated answer. Although I will do my best below to answer your reply to my original answer, but if the subject is still unclear after reading this extended answer I would recommend creating another question on this forum and I can answer you there if you link the new question as a reply to this answer. Without further ado here is my extended answer:
As a game programmer, one wants to give their game designers the most control possible over the design of the game while still having a solidly programmed system.
So for this example, let’s say a game making team was making a tile based game. The design of the game demands that when these tiles are stepped on by the player they all do something, but the game programmer only wants to have to call one function named, “OnOverlapBegin ()” (for the purpose of this example).To expand the example, let’s say that one tile will light up when its stepped on, another will teleport the player, and the last one will only do the base functionality (which for this example will be activating the sound that the player makes when stepping on the tile).
Now all this functionality could very easily be made into several unrelated classes. Although it would be much nicer if all of it was based on one C++ class and a couple of blueprints. In the base C++ class one could create a tile class. This tile could contain the following code in the tile.h file:
UFUNCTION(BlueprintNativeEvent, Category=“Tile Functions”)
void OnOverlapBegin(class UPrimitiveComponent* OverlappedComp, class AActor* OtherActor, class UPrimitiveComponent* OtherComp, int32 OtherBodyIndex, bool bFromSweep, const FHitResult& SweepResult);
void OnOverlapBegin_Implementation(class UPrimitiveComponent* OverlappedComp, class AActor* OtherActor, class UPrimitiveComponent* OtherComp, int32 OtherBodyIndex, bool bFromSweep, const FHitResult& SweepResult);
The OnOverlapBegin() function would have no implementation created and that would be left to the designers to create in the Blueprints. In the OnOverlapBegin_Implementation() function the programmer would create the base functionally described above to activate the sound of the player walking on the tile.
Later when a Blueprint is created from the tile class the designer could create a “LightUpTile_Blueprint”. The designer or programmer could create the functionality to light up the tile by adding functionality to the OnOverlapBegin() function within the Bluprint Event Graph. Additionally, the designer or the programmer could also create a “TeleportTile_Blueprint” the same way. Lastly, if the team wanted to create a simple “GrassTile_Blueprint” that made a grass sound when it was walked on by the player. All the team would have to do would be to create the Blueprint and add the assets. This is because the C++ functionality for the OnOverlapBegin() function would be triggered instead (which was programmed to activate the given sound file of the tile when it was walked on).
Overall, this makes the process of adding new functionally easier while still adhering to inheritance and good object oriented programming practices.
