Blueprints are just as difficult as scripting languages, but more difficult to search for answers!

I’m trying to do a simple access of a public variable in a child object. These are the amount of different ways I’ve tried so far:

I mean, the Epic answer seems to be “the engine wasn’t designed in that way, just work around it”, but this is meant more as “I’m new and this feels like the logical way of doing things, why wasn’t it designed to be this simple?”

I mean, more people than me are confused by this, because for example, here’s the first Google result on this topic:

https://answers.unrealengine.com/que…-function.html

Hopefully there’s an equally easy way other than the three examples posted here to accomplish this but also, it would be great if these three examples actually worked, instead.

Right now, it seems that the Blueprints follow exactly the same archaic syntax rules as programming languages, and are not at all easier, because it just makes it more difficult to search for the answers, since the answers are graphical nodes instead of text you can copy and paste. And it seems you need to know exactly what to search for in the blueprint editor and type it in in order to make it work, which again I don’t really see much of a difference between scripting (that white connecting line is perhaps easier to spot than a missing comma, but still). A toolbar with common functions that you could drag and drop, like the modes bar in the main editor, would have gone a long way to mitigate this.

As of writing this, I still don’t know the answer! First impressions from me are a big thumbs down, unfortunately.

Yes, Blueprints can serve as a ‘non-programming-required’ system to a certain degree, but you still need some programming knowledge to create more complex systems, or just to feel more confident in what you do.

One of the steps to truly understand Blueprints is to learn about Object-oriented programming. When you understand the concept of classes,objects,interfaces,etc. it’ll be a lot easier - for example, the ChildActorComponent that you have is of… ChildActorComponent type. That’s why you can’t see your variable that is declared in your ViveControllerV1 class.

Now, the thing with Child Actor Components, it’s a little bit different than regular object references. Usually you can cast to your ViveControllerV1 this way, but in case of Child Actor Components you need to get current child type via GetChildActor -> Cast to ViveControllerV1, just like it’s explained in the AnswerHub link you’ve posted.

As for the image questions:

  1. It can’t be just dropped like that, because the variable is in a different class. You can access variables through object references of certain type, for example, by getting it from your ViveControllerR —> GetChildActor —> Cast to ViveControllerV1 chain. It just needs to be a ViveControllerV1 type to access a variable that is declared in the ViveControllerV1 class.
  2. This is not allowed because the SetControllerHand function has a ViveControllerV1 target (as you can see in the node), and the ViveControllerL you try to plug in is of ChildActorComponent type. Again, it needs to be a proper type of object.
  3. It is not listed, because you try to access it from an object of ChildActorComponent type. If you do the “ViveControllerR —> GetChildActor —> Cast to ViveControllerV1”, and get it from the Cast node output then it should be visible, since now it’s a proper object type.
  4. Same, if you use the output of Cast node (but with the extra GetChildActor step before), you can see that it is a ViveControllerV1 type - so it should fit the function Target: “Target is Vive Controller V1”.

Thank you for the explanation, although it seems that your suggestion didn’t work either:

I know some C/C++ from 20 years back, and I also know some Objective-C, Swift and C#. Isn’t the ViveControllerL an object instance of the class ViveControllerV1 here, that I should be able to directly call a class function on?

EDIT: This is the correct solution… again the problem was “syntax error”, just as with a scripting language:


Feedback for Epic: I can’t understand why the Blueprint editor doesn’t just insert the required in-between nodes here for me, as it seems to do if I, for example, drag any variable onto a print node.

First off, I need to know that I wanted to “cast” when I dragged of the function target node, because nothing popped up in the action menu. Second, I needed to know that I wanted a “child actor” when I dragged off the object reference, because nothing popped up in the action menu for that either.

Right now, I see no difference between Blueprints and a proper coding language, and with a proper coding language, I’m at least learning a skill I can re-use. Here, it feels as if I’m wasting my time fighting bad UI (yes, I know I can use C++, but I have coworkers who can’t, and again, this is feedback. Things could have been so much easier).

EDIT: Ok, maybe I see it now. Is it because I can actually switch class in that drop down menu in the details panel? Ok, that would make the cast fail with a warning. I think I’d prefer to just have an error on the function call itself. But Epic didn’t design it that way. Sigh, “just work around it” I guess.

Yes, it’s ChildActor instead of ChildComponent, glad to see you’ve made it work.
Yes, the Child Actor Component is quite specific like that, since it’s designed to have different child object types.

You can also use create a SceneComponent and add it to your actor, instead of using Child Actor Component, but it has its limitations, so that depends on your use case: Imgur: The magic of the Internet

You don’t need to work around here anything, you just need to understand this system in order to understand why and what’s happening. Blueprint is missing many things, it can be very annoying, but not on the level you’re currently looking at. You can’t just build a Lego tower by getting the pieces and stack and throw them upon each other randomly, heads-down, because for you, coming from matchboxes, that seems to be logical. You have to learn how to build with Lego bricks.
Anyways, ChildActorComponent might not be language feature you want to start with if you don’t fully understand the basics yet, as it’s a bit more complex (just a bit, but still).

Print only inserts those nodes, because UE knows how to convert some types to string. Besides that, BP actually does insert some intermediate nodes if it understands what you want to do, like the components of actors as middleware. While it can probably be smarter, you have to know what you want to put there, the editor has no idea what do you want to cast.

The UI might be better, but I believe it’s far from bad. You just don’t understand it yet. It doesn’t make 3DS Max’s UI bad that I have no idea where to click to make a cylinder. Of course you need to learn the UI to use a non-text based language.
For co-workers who can’t program at all, you’ll see that it’s much easier for them to learn building simple features with a few links, nodes and branches than teaching them C++. The frame of the blueprint system used in your game is, obviously, not built by artists, but programmers who understand inheritance, classes, and all these things. However, (technical) artists can easily learn to write simple logic with Blueprint, like creating some logic for weapon instances, particles, etc.

If you don’t see how Blueprint helps prototyping and the work of artists / designers, then you probably didn’t put enough time in it yet. I agree with you that jumping right into it is not really trivial, programmers usually have to put their head around it first, but many people have walked your path before who are now using Blueprint in products generating millions of dollars, and they probably don’t do it just to f*ck with themselves, but because it’s a great tool if you learn how to use it :wink:

Ok, so as a learning excercise, would you be willing to give me a few examples of what else I could have put into the target of my child actor function that would have been valid and that the editor could have had no idea how to cast?

The Blueprint graph has no idea what type your ChildActorComponent is using currently, as the ChildActor member variable has an Actor type. Yes, you have set it in the property window, however, it can be changed at any time in-game, so the editor will have no knowledge if at that point in the code you’ll use ViveControllerV1, ViveControllerV2 or even ChairMesh for the same ChildActorComponent.

So actually the linking didn’t fail because there were too many possibilities - but because there was none.