Blueprints within blueprints...

Hey all, I’m new in here so please be nice :rofl:

Anyway, I know the answer that a blueprint cannot be placed inside of another blueprint.

But here is my way of thinking, and if there is a way of accomplishing this easily i would appreciate some pointers.

So, in simple terms, I want to create a reusable actor that has its own code and triggers attached (blueprint actor.)

One of the examples I wish to use this for is a ‘Power Node’ for which power lines will be connected. There are also many other similar ideas but I will use this as a simple example.

Ideally many different actors will use the power nodes, buildings, machinery and tools etc. A simple class that can just be reused throughout, with its own mesh and assignable values etc etc.

I cannot just create this and attach it inside another blueprint, so, what is the best way to make such a reusable actor in this way? I would like to be able to target the mesh directly when using a wiring tool or whichever method I choose to create the wiring connections.

I’m sure there is a simple answer, but it doesn’t come to mind.

reusable code is the best way to go when it comes to performance and also speedier creation. So that I don’t have to rewrite, or copy paste a load of code per actor that requires the same interaction, what would be the best approach?

I am sorry if this is a repeated question answered many times, I have ran a search, but maybe the terminology I used to search by wasn’t adequate to get the correct posts in return.

Any help would be appreciated and thank you in advance.

Stewart

Hey @High500! Welcome to the forums!

This would be the time to use a component! You’ll want to create a component that can be attached to actors that will call on its owner BP’s static mesh to do what you’re wanting, etc. and can be attached to as many actors as you wish :slight_smile:

2 Likes

Try to use Child Blueprints

2 Likes

Yeah, you can. Kind of - a Child Actor Component can hold another actor. And any actor can own many CACs. But CACs may not be the best due to performance reasons and they can become unruly at times.


Perhaps actor components are a better choice. But not just actor components, consider overriding more specialised comps instead, and encapsulate behaviour inside them:

Another example:

The pins on those cube actors can be made out of components that support inheritance. They can have their own variables, methods, dispatchers and the entire logic that drives them, and also looks up what other components attached to the same parent are up to.

2 Likes

Many thanks for the quick response.

I am actually using actor components at the moment to accomplish (partially) this task. but it is a code only object and does not have an associated mesh (i’d like to drag and drop the entire mesh with code to another blueprint actor).

I have used reference objects which is a little backwards and means me creating the mesh attaching it then reference the mesh in the component.

It works but not as cleanly as i would have liked whence the question, I am still learning though and as i experiment it maybe this is the answer.

So thanks again!

Stewart

I will look into the Child Blueprints, interesting i never came across this!

Thanks

Stewart

Thanks Everynone, Ok i wont lie and say i understand ALl you have said, but the overriding of some other component might be the answer.

Is this doable in blueprints only mode or do i have to do some C++ for this to work?

Thanks

Stewart

Ok the wording of this isn’t what I expected. Its inheritance from a base class which whilst it is a work around, i may need more advanced inheritance for each base object, meaning i would have to create many inherited base classes depending on each say building type. Ie say i was to build an ore processor, then advanced ore processor then refinery all inheriting from its base, i would also have to inherit from the power node base class at the beginning of every single powered object.

It would work, but im not sure how messy this might become depending on the number of steps. especially if the base power class is updated and is incompatible with some of the sub classes as there may be cause for different interactions with the power nodes (dont mean there will, but a possibility)

Still its food for thought!

Thanks

Stewart

Very. There is a project attached in one of the examples.

re: other answers - inheritance will be a part of this, too as components fully support it.

2 Likes

@High500 Child Blueprints really might be the way to go.

You could do:
Building (Put a base “power node” function “Powered” in this so all can use it below)
Children of Building: Ore processor, barracks, tower (use powered as normal)

Child of Ore processor: Refinery: Override “powered” to increase productivity 2x

You can modify how it’s used with minimal code vs redoing all of it each time.

Think of it like a “tech tree” used in a ton of games, where you get the benefits of the above, but in this case you can disable/modify inherited pieces and add new ones as you wish.

2 Likes

Ok ive just had a look, interesting, the logic behind the snapping system is very relevant, adding code inside the inherited static mesh and adding it to the blueprint looks alot cleaner way to go for me.

I will experiment further thank you all!

Stewart

2 Likes

Yeah im not dismissing it, its a very solid way to go, im just trying to think ahead to any possible issues that may arise modifying the base power node class, especially as it may have mulitple nodes an become over complicated (as i always do :rofl:)

But i will experiment with different ways, some will have input power, some output and some both.

Plenty here for me to play with to be honest and this maybe the simplest option as long as i keep the basics of the power integration simple i think.

Cheers!

Stewart

Regarding inheritance, consider this as a top-down overview:

image

  • aDevice is an empty actor
  • SMC_Base is an overriden Static Mesh Component that has the common functionality all components share - how to attach stuff, how to look up other components, how to show a mesh, how to handle materials, an interface to communicate with and so on…
  • other comps - Battery, Body, Bulb, Switch inherit from the SMC_Base and add their own stuff - variables, functionality, an entire graph full of blueprint wires!

So I can make a weird modular flashlight aDevice actor whose component can do their own thing without the owning actor even knowing about it :slight_smile:

This is just the tip of the iceberg, ofc. A system like this can get really complex but if modularity is what you’re after, it may be worth exploring.

Good luck!


Also, this stuff can be added / removed dynamically.

2 Likes

Guys thanks so much!

These answers are all relevant, i would like to mark this as resolved.

However Everynone’s answer was probably more suitable, however, mixing in with @Mind-Brain and @Supremative’s suggestions may give me the best overall answer.#

How do i give props to you all?? :rofl: :rofl:

Thanks Stewart

3 Likes