Casting to actor using actor reference failed?

CyclonicTuna · January 22, 2024, 7:29pm

I don’t know if I’m so stupid, or there’s just something I’m not getting. But I still don’t understand how casting works in blueprints.

I have this simple setup where I want a door to open after the player has picked up a set number of pickups. So I create some logic, with a variable that keeps track of the pickups.

And then I want to cast to my door blueprint which has a custom event that just opens the door.

I’m casting from my FirstPersonCharacter to my Door blueprint:

The Door blueprint holds the logic for animating the door that’s initiated by a custom event:

Using some print string debugging I find that my cast keeps failing.

I looked up how casting works and from what I can tell, you just need to make sure you define the parent class of the thing you’re casting to. So I use an actor reference variable to do so. But it still doesn’t work.

Someone really needs to explain to me in todler language what I’m doing wrong here.

Everynone · January 22, 2024, 7:50pm

That’s not how casting works, though.

A reference variable is not an instance of the actor:

Think of the above variable as of a blank sheet of paper you can write a house address on.

Where’s the actual house?

In 99.9% of cases people do not have problems with casting, casting is trivial:

There, done! It’s just a single node that does the conversion.

People have problems with obtaining a valid object reference - called Actor Ref here. So, we’re looking for an instance of BP Door:

Which door? How do we know which one out of the hundred doors in the scene is the correct one? Once you know which Door Actor you want, you can store that info in Actor Ref variable.

Everynone · January 22, 2024, 8:02pm

Perhaps you could briefly explain what’s going on.

there is a bunch of pickups in the scene
there is a bunch of doors
specific pickups open specific doors? like keys would?
player collects X pickups and door slides to the side?

How close am I?

I have this simple setup where I want a door to open after the player has picked up a set number of pickups.

Are there many kinds? if it does not need to be that specific, and you just need X of something, perhaps you could count stuff being destroyed. Would that work?

CyclonicTuna · January 22, 2024, 8:12pm

Okay, well see. I understood that… somewhat.

However I still don’t really undestand it. The reason is 2 fold.

I saw a video that I can’t really find that quicky anymore, where a guy made the comparison that casting to a blueprint, is like asking for Star Wars Episode 3.

But not specifying which Star Wars Episode 3 you’re asking for. I.E. is it the movie, the game, the lego set etc.

And the way he said to solve this is by simply making a variable that is a reference to an actor, to plug into the cast node. So the cast knows which parent class to look for. As shown here:

Second. If that’s not how it works. Then what is a reference? And how can you reference something in a blueprint that isn’t actually in that blueprint. But is another blueprint somewhere in the level?

CyclonicTuna · January 22, 2024, 8:13pm

Ah so, no. Its not that complicated.

I literally have 1 kind of pickup, and one kind of door.

There’s 3 of the pickups in the scene, I want the door to open as soon as you have all 3 pickups.

Everynone · January 22, 2024, 8:15pm

If it’s that simple indeed, then I’d do in the level blueprint:

It already knows about all actors that have been placed there.

Everynone · January 22, 2024, 8:22pm

a blueprint is a template
when we spawn an actor or place one in the level, we use that template to create an instance of an actor
that instance sits in the computer memory, we need something to keep track of it
the reference variable stores the address of that actor (simplifying a bit but that’s the gist).

And how can you reference something in a blueprint that isn’t actually in that blueprint.

Depends. If both entities are already in the level, it’s pretty straightforward since the level knows everything. Not sure how you spawn the player but consider the following.

the door is already in the level, it already exist which is great
the problem is that the player is yet to be spawned by the Game Mode - since the player does not exist, it cannot reference the door

CyclonicTuna · January 22, 2024, 8:29pm

Okay I think I’m starting to understand.

So the reason the cast fails is because when the player is spawned, it doesn’t keep track of the door because the door is just a seperate instance in the level?

So then why shouldn’t you script all your logic in the level blueprint? If the level bluepring is the only thing that can know all instances you might want to reference.

I thought it would make sense to keep track of the pickups in the PlayerCharacter blueprint because the player is the entity that atcually collects the pickups.

I’m unfamiliar with you method as you showed how to do it in the level blueprint. What do the Bind Event and Get Player Character nodes do?

And how do you reference a specific instance of a door in the level?

Everynone · January 22, 2024, 8:44pm

Pretty much. The player has a variable that could point to a door (a pointer is another name for this) but it does not. For now it’s just an empty data container we’ve yet to fill.

So then why shouldn’t you script all your logic in the level blueprint? If the level bluepring is the only thing that can know all instances you might want to reference.

Level blueprint is great if you want to script unique stuff that happens in this level only. It dramatically simplifies referencing. If you want to have 100 levels with the same mechanics… then I’d rather avoid repeating this script 100 times:

We’d need something more automated. For that we’d need to know how the game is supposed to work and then choose the right tool.

I thought it would make sense to keep track of the pickups in the Player Character blueprint because the player is the entity that actually collects the pickups.

Oh, it does! The pickups were never a problem, you handled those with overlaps and casting. The problem is that the player has no idea about the door. If I place the player:

in the level:

I can immediately tell it which door I want. If you make the someActor reference door type, you wouldn’t even need to cast.

I’m unfamiliar with you method as you showed how to do it in the level blueprint. What do the Bind Event and Get Player Character nodes do?

Bind is a part of a communication system often referred to as Event Dispatchers or delegates. It allows one blueprint to listen to what happens elsewhere. Actors have a bunch a of dispatchers built in and additional can be added, too.

Get Player Character is a reference to the currently possessed character:

in short, the Level Blueprint is listening to the player character overlapping stuff.

And how do you reference a specific instance of a door in the level?

The humble drag&drop does the trick:

Or you can select any actor in the scene and right click in the LB to:

CyclonicTuna · January 22, 2024, 9:19pm

Okay I now realize that I never thought something simple would be so complicated.

So would it make sense to keep the variable that tracks the amount of pickups in the PlayarCharacter blueprint in this case? Is it possible to reference a variable of a different blueprint in the Level blueprint?

Or is it better to just script everything in the level blueprint? But then what if I do want to re-use the logic?

Everynone · January 22, 2024, 9:46pm

Or is it better to just script everything in the level blueprint? But then what if I do want to re-use the logic?

If you need reusable logic, my suggestion is to avoid LB or script that logic into an actor and then drop that actor into every level that needs it. This would make things somewhat scalable, maintainable and modular.

You have too many options, actually:

you can place the player in the scene and directly reference the door needed, done:

if you cannot place the character upfront (100 times in every level is tedious), and there’s only 1 door, the player can fetch that one door:

if you have more doors, sets of doors, you can use tags and filter some special ones later on:

if you have 100s of doors, we’ll need an ID system:

if there’s 1 door only, you can have the door find the player instead:

Here, it is the door that looks up the player and sets itself as the door the player opens. The Some Door is a var in the player, as you originally had it.

technically not what you’re after atm, but consider the following::

It’s the door that counts stuff the player picks up and then opens itself once threshold is met. This is especially useful if we have doors in 50 out of the 100 levels only. It’s one way to declutter the otherwise superbusy player BP who no longer needs to worry about mundane pickup stuff. This is a question for you to answer from the design point of view - does the player even need to know the number of pickups?

or the other way round:

All of the above would work, and none use the level blueprint. There’s probably another 2-3 methods:

the player can spawn the door dynamically ; this can be useless - but could work, depends on the design
another blueprint can look up both the player and the door and hook them up; oftentimes people write separate managers objects that handle objectives/scenarios. The idea is to decouple the player from objects/events, perhaps they do not need to know about details.

Creating hard references (the actor ref) is frown upon. Even if a level has no door to open - the player BP now must load the entire door class it will never ever use. If the door references something else, it will also be loaded.

CyclonicTuna · January 23, 2024, 10:36pm

I feel so so dumb trying to understand how this works, and what makes the most sense. I’m really not a programmer, and I’ve been trying to avoid it for a long time, precisely because of this. I know its not difficult but my brain just doesn’t compute with why this is supposed to make sense.

I’ve ended up doing it differently. And letting the door check whether to open by adding a box colision and checking how many pickups the player has when it overlaps with the door.

But I’m frustrated I can’t think of a smarter way to do it myself. I thought that having the door open automatically when you have collected X pickups would be easier. Apparently trying to make things simple isn’t actually simple when it comes to blueprints.

What I don’t understand is why only the Event ActorBeginOverlap has the little blue output you can plug into the cast. Why don’t all event nodes have that? Would make it a lot easier as far as I can tell.

Anyway, it works now. I have logic in my pickup blueprint that only destroys the actor when it gets overlapped. I have logic in my FirstPersonCharacter that keeps track of the number of pickups. And I have logic in my door Blueprint that checks how many pickups the player has.

That will have to do for now. I have a class to teach tomorrow where I have to be able to explain this stuff.

Thank you. Many many many thanks for your help and detailed explanation. I don’t know if I’ll ever be able to progress past this point with blueprints, but don’t take it personally. Its just not my cup of tea.

Everynone · January 24, 2024, 10:31am

I had to sub for 3 months as a history teacher once. The thing is that I generally can’t remember what happened last week, not to mention ancient Mesopotamia. It was a riot. I definitely had to study more than the kids.

Blueprinting follows OOP quite closely. Scripting still counts as programming. It’s a vast and deep subject where you’re communicating in a strange language on top of the usual logic and complexity. And need to deal with engine’s quirks to boot…

I don’t understand is why only the Event ActorBeginOverlap has the little blue output you can plug into the cast.

A lot of the nodes do. But think about it - how can a node output a reference to an object whose existence it does not know about. Or how can it decide which object to output if there are many instances? It’s the dev’s job to procure access to objects.

CyclonicTuna · January 24, 2024, 12:31pm

Yeah. Well I actually work as a freelance teacher but I mostly teach more artistic classes like character design and 3D design.

I’ve dabbled in programming before, but it never really aligned with me as easily as it seems to do for other people.

I took on the role of technical art teacher this semester, where I basically try to teach them as much as I can about Unreal engine.

I like a challenge but I think this time I bit of a bit more than I can chew. Which if I’m honest, is what always happens. But hey, what are you going to do?

Thank you again for all the help!

nmiles2go · November 7, 2024, 8:14pm

This template is C++ template or are you using this word in a general english language sense?

PrezThompkins · November 7, 2024, 8:28pm

If the cast failed, that means you didn’t pass in an actor that matches what you’re casting to.

Think of it this way:
The cast isn’t searching for an object and running some code,
it’s looking at an object you’ve already specified, and if it passes a ‘Is this what I think it is?’ test, then it runs the instructions.

So for your scene, you need some way to tell your blueprint what Actor-Ref is.
If there’s only one of this thing, you could use GetActorOfClass and explicitly grab the result.

With that type of function, you don’t even have to cast because you know whatever it returns is already the class you want.

Because this is on a ‘begin overlap’ I’m fairly certain that you’re doing this in the player character BP… Personally, I avoid putting stuff in there for one-off and rare occurrence events. You might be better off having the door sense the players nearby, and then the door itself checks whatever rules you’ve set up.

If this is something you’re going to have in a lot of areas, then I’d argue for an object that sits in a room and knows what door is associated with what items.

nmiles2go · November 8, 2024, 2:30pm

I am a bit confused with this statement. Isn’t casting related to inheritance chains? If some thing does not have a “is a” relationship, then casting fails? For example, if a “Burger” is a “Food”, then you can cast “Burger” to a “Food” but not the other way round because a “Food” is not necessarily a “Burger”? Please correct me if I am wrong.

Everynone · November 8, 2024, 2:50pm

In general. I mean, Epic named it all Blueprints - that should already be self-explanatory; yet, In 9/10 cases, folks will create an actor reference thinking it is the actor instance, which it is not. It’s a reference to an instance. Casting itself is never the issue, finding a valid reference to convert to the type we want is.

It’s a pretty straightforward way to put it and should live among:

animals => mammals => dogs and:

nmiles2go · November 8, 2024, 2:55pm

Thanks bud for a great explanation of all this! This post should be archived!