Reparenting a character blueprint to an actor blueprint

For various reasons, I’ve got a situation where I want to be able to cast characters to the base class that I’m using for other items. Because that class is just a basic actor, it obviously breaks the character’s blueprint.

I’m wondering if there is a way around this or if I’m just going to have to recreate all the logic and components that make a character a character after I reparent

And you cannot use an interface instead? If no, make your own character class that extends from the base class.

I am using an interface, but I need to get a variable that needs to be present in every actor type, hence they need to inherit it from the base class so I can cast to it.

I feel like would be easier to add that one var to the player and have it returned by the interface function.

Possibly; the interface takes the execution from the player blueprint to a component, and the component gets the variable. I suppose I could set up the logic so that there are different branches depending on whether it’s a character or some other type of actor.

Why would you need branches? We’re using an interface - that’s the whole point. No casting, no need to figure out ahead of time what we’re dealing with. The implementation on the non-base class returns a variable from a component. There should be no need to propagate anything (but you can).

You just need to use class inheritance properly. Create a parent character class (e.g. MasterCharacter). All the logic and variables are in the class. Create “Child classes” for different characters.

All casting should be to “MasterCharacter”.

1 Like

The component has to get a variable from its owner; that owner could be one of several different classes. When you get a variable, you get it from a specific class; even if two different, unrelated classes have a variable with the same name and data type, you can only choose one to pull it from. In this case, since the owner of the component could be a door, a chest, a monster, an NPC, a road sign, etc., I pull it from the base class that they ultimately all trace their inheritance to and then cast the owner of the component to it.

The base class is fairly empty besides a couple of components I made and a few variables.

Here’s the components of a character class that I reparented to this base class.

image

It stripped out the movement, arrow, and capsule. The arrow and the capsule are easy enough to add back in, but I don’t see the movement component when I click +Add.

That will not work, the character will inherit all of that. Especially the root component is problematic, it will not mesh with the CMC - as mentioned above.

Create a base class that has nothing inside (just the data you need in both classes). Items and Characters inherit from the same scene-component-less base. Override methods in both. That’d the inheritance way. But that would require you made your own custom character from scratch - this will not work with possession.


Message actors using the interface. You mentioned being familiar with them, so that will work just fine.

The component has to get a variable from its owner

A perfect use case for an interface.

  • instead of:

  • message the owner to get their name:

image

Any actor that implements this (additional or the same that you’re already using) interface will return its name. You seem to have a setup that is complex enough to utilise it.

Already have that

Is that with C++?

Test it yourself, open a template, create a new actor class. re-parent a character to that class. Now you have a base class your items, too, can inherit from.

Is that with C++?

No. In child classes:

I tried to reparent to something of the “Object” class, which has no movement or default scene root components, but it doesn’t seem to be possible.

That would not work. Why do all this? Why not message the actor as demonstrated above or have the base actor class?

Besides that, re-parenting something as complex as the character class sounds like asking for trouble. It seems a bit disconnected here, we started with actors, and now we need objects. :person_shrugging:

My advice here is: send an interface message and move on, it’s a 30s job.

Good luck!

I still have the problem that I can’t pass variables from two different classes that aren’t related to each other into the same in pin.

This is precisely why interfaces exist. Use them:

The literal solution. :slight_smile:

This is exactly the problem interfaces solve.

Inheritance is, generally, a bad design pattern. I know that Unreal has jammed its actor system into the implementation inheritance jar, but that doesn’t make it actually good.

You can add two functions to your interface:

  • GetMyValue() → Value
  • SetMyValue(Value)

Once you do this, you can just pass the interface around, instead of having to pass a class instance around. Whenever you need to read the value, call GetMyValue(). Whenever you need to write the value, call SetMyValue().

This is literally the problem interfaces are designed to solve, as @Everynone is saying.

Separately: if you re-parent your Character to just be an Actor, then it’s no longer a Pawn, and you can no longer make it a player character, make controllers possess it, and so on.
(This is another problem with inheritance – it would be better to make “can be possessed” be an interface, or maybe be implemented by having a component instead. But that ship sailed long ago :smiley: )

@jwatte. Alright, I’m still having trouble figuring out how interfaces are going to do anything but kick the can further down the road in my case.

The situation I’m in is that I have a component that gets attached to anything “interactive”: npcs, items, doors, signs, etc. What this component does is, when the player looks at it, make visible a widget in the viewport and set the widget’s text to the display name (a variable).

How can I use an interface to get the variable from any one of these classes and use it in, in this case, a Set Text (Text) node?

Each of the objects should implement the interface.
Then you can either “cast to (interface)” or just “call (interface function)” on the object.

In fact, I do exactly this in my “interactable” system.

In your case, you’d simply define a “Set Text” function on the interface, and call that. If the name “Set Text” interferes with some existing function of the same name, call it something slightly different, like “Set Interaction Text”

Okay, I got something working with interfaces. Implemented it in the BP creature and BP interactor classes. I used the set function and the return (message) function in both, then the return function in the component itself. Not sure if all that’s necessary or the most optimal way to do it but it works. However, it is noticeably slower during PIE but that might just be my potato