Components Vs Actors

Dev: Jacob Zhu

This week a lot of effort has been put in trying to convert the proximity enable logic of the Actor that detects a player, and spawns AI from a pool, and transfer it into a component that an existing Actor can use, instead of being an Actor itself. Through numerous trial and error and reading from the source code, I soon realize that due to the heirarchy of calls within Unreal Engine, data containers dont get populated in the same order (if it relies on existing data already created in the game) in components as compared to traditional actors.

This means that trying to use Unreal Engine's version of a map, which is TMap, leads to errors when trying to compile, if the logic of intializing it is copied 1 to 1 from the exiting Actor to the new ActorComponent.

A potential solution I can think of right now for next week is to try to rewrite the base class of the actor so that all such logic is included into the house Actor instead creating a separate component for it. Another is to strip the tracking and storage of data out of the ActorComponent class, and instead call a reference to the house Actor to manipulate the data stored there, when checking what to spawn. This should lead to a more complete package as a whole to allow for randomization to take place.