Newbie question, but I hope I’m misunderstanding something here, because I’m currently a bit at a loss.
Everyone (literally) have said for years to not use child actors, because it’s buggy, so ok, that’s sadly ruled out then…
But now I discover that actor components can never be re-attached to other actors, and must be destroyed and recreated instead, which then disqualifies any BeginPlay usage, etc…
So how do people move, for example, items (with active on-going behaviors) between the ground, an actor and the inventory… is it (like too often with Unreal) something that can only be done with C++ or is it an actor when on the ground, a component when on an actor and just a struct when in the inventory?
In essence, three different implementations that all represent the same thing, and their usage depends on where it’s currently located? To me, that sounds terrible!
Actually, I haven’t even tested if components can be attached to components yet… (I wanted modular behaviors that I can attach to items.)
I’m going to assume you are picking up an item in the game, adding it to inventory, then dropping it. Once dropped it can be picked up by you or another player.
The approach I use is to have simple no data (ID → data table) or low data (struct info) items in the world that are spawned by the server. When players pick them up, the server destroys, updates the players inventory (actor component in controller). On drop the server updates inventory, then spawns the low/no data item back into the world.
For physical items, say weapons. I spawn and attach skeletal mesh actors.
@eobet
Can you give references as to whom/what said that child actors are buggy?
Seems like total BS to me / just people incapable of doing things properly.
As far as how you should do things you infer correctly.
You don’t need stuff loaded in unless it’s used.
Say a crossbow, is an attached phat asset when not in use but needs to display on the character.
But an actual blueprint when equipped.
Likewise, most inventory items are just information until equipped and used.
As a general rule of thumb, If the information isn’t needed, it shouldn’t sit in memory…
Sorry, I’ve had it clarified today that child actors are fine, but child actor components are all sorts of screwed, so now I know the distinction.
Also, I was told about attaching and re-attaching actors themselves to other actors, instead of components, and I think I can make that work (and crucially for me at least, this is reflected in the world outliner, which I find very important in order to visually see what’s going on behind the scenes in the game):
So yeah, I think that was the missing puzzle piece!
(Just to elaborate further… that item actor reads the static item data from data tables, which include soft class references to item effects which are actor components, that get attached to the item actor whenever that item actor itself gets attached to the player and destroyed when the item actor is attached to the ground… which fingers crossed will work out fine!)
I was looking at creating an inventory slot for a vr character (modular) and noticed that if I make it from a scene component I can’t have any subobjects on there without spawning them on begin play. I also have no preview to work with.
If I were to make this as an actor then I can’t include it in a blueprint of the character either, it’d have to be a child actor component or spawned in on construct to some arbitrary slot or something.
If I were to make a component in c++ I’m not sure I can have hierarchies in there either. This seems super strange as the workflow to have nested components in a component object makes perfect sense to me.
