I have a gameplay management class I’m creating that doesn’t actually have a physical entity in the world but that is needed to manage actors that do. Should this inherit from UObject or UActor?
At first I was thinking it should inherit from UObject, since it doesn’t really have a physical location in the scene, and UActors must have a location. However, when I tried that, I found that I couldn’t instantiate my class from blueprints – the only way I can find to instantiate custom classes is to spawn actors, but you can’t spawn a UObject.
So for now I’m making it an actor and just giving it a B.S. default location. This seems non-ideal, though. Is there a way to instantiate UObjects that aren’t UActors in Blueprints? And are there any other considerations here I’m missing? Thanks!
I guess maybe I could write a C++ function that’s blueprint callable that instantiates a UObject for me? That seems a little funky, though.
UObject is the base object class. Essentially all it is is a blank object which can be manipulated with blueprints and network replication.
AActor is the class for anything which you want to exist in the game world. One of the main features of AActor over UObject is the Tick() function, which gets fired once per frame. An AActor also has properties such as a location in the world, the ability to receive input, and various other things you can take a look at here.
Other very viable option for manager kinda classes is inheriting from AInfo class. It represents something between Actor and Object but can be present in world and it’s transform does not matter. It is useful for stuffing management related components that should be spawned when you load scene. I find it quite useful in this respect.