Alternative to Casting- Works for me. Should I expect drawbacks from this method?

Before I start: If anyone more experienced wouldn’t mind sharing, is there any drawback to using this method versus traditional casting or interfaces? Because I’ve found this extremely effective and have been unable to cast to certain things, so I found a way around needing to cast at all and instead I now use Material Paramater Collections instead.

I come offering a solution for those like me. I couldn’t find, for the life of me, how to cast to a specific object in my scene. In my case, it was the directional light. I’d cast to actors then try going down the heirarchy towards directional lights, and be told that I needed to cast from the directional light to the directional light. Well, that can’t be done as far as I can tell because it’s a reference to self.
Or I’d have the opposite problem and only be able to try to cast in reverse, which, lacking inheritance, obviously did not work.

So I discovered Material Paramater Collections can be used as Blueprint variable passages. Since then, they have changed my life in a single night. Video below demonstrating their use in communicating between 3 blueprints, passing variables from a weather controller actor blueprint to a directional light in the persistent level while also updating master materials parameters all at the same time, without having to “castto” a single time.

I’m a new developer and either self taught or learned from the internet, so I do not know if this is bad practice in some unforeseen way. But I do know, if you can’t find ANY way to execute a given task, that is worse than finding a convenient way that works and later, when you have more experience, coming back and resolving potential issues you created for yourself when you were newer. Better to move forward and continue to learn and experience than get stuck trying to learn how to cast to specific actors when the modules seem to be sending you in circles.

Also, I find this workflow personally quite enjoyable and powerful.

Hi man,
i am not an expert so take it really lightly.

I really dont find “casting” an obstacle, sure sometime i mess up the project for unexpected things that we are unable “to cast” .
but i am not sure that the point is , be able to cast all the time at all the tings, this mess up the concept of “object oriented programming” and “Event prograammin” or what they are called.
The same concept of “Encapsulation” (i dont know how is in english)
the concept that variables are private and so not visible from other actors, object…
If you make a complex project where every actor cast to other actors and manipulate varialbe you can easily look control.
Am i saying something that make sense?

So , sure, we can use material parameter collecction to share some info around actors,
the same thing we can casting to the gameinstance,
every method should have better fit for some project too…

So if for now it works for you, nice!
but if one day your project will have multiple group of blueprint sharing, you could found really hard time.
But again, is interesting see how people work so tthank you for share :slight_smile:

As your project grows in complexity, you will need casting.

Casting ( or using the correct level of inheritance ) has many useful ascpects. Two of them being:

  1. Casting down the inheritance tree gives you access to the internals of an object ( variables, functionality etc ).

  2. Casting upwards ( or using a parent type ) hides all these things.

The main problem with living on ‘one level’, is the development of circular references. This is where object A knows about B and B knows about C and C knows about A.

In fact the links can be very long and torturous indeed. Once you get past a certain level, these links will introduce all sorts of weirdness into your project. For example attempting to package will include all sorts of irrelevant assets. Another example is inexplicable crashes.

If you want to know how you’re doing on that front, have a go with:

Also, if you give me a specific example, I’ll explain how to cast correctly for you.

Maybe if I made a specific post then demonstrating the specific problems I have had with casting someone could explain it better. I’ll post a video later on after work, because I tend to often get the same explanations that just lead in circles.
I’m uploading it now, I will post the link to the discussion when I get back.

There’s a limit to how many parameter collections you can use … Unless something changed in engine that I’m unaware of.

Video is still processing, should be live in about 2 minutes. But I have to leave for work 10 minutes ago, so i’m just going to post it now. Maybe this will help explain where I’m confused on the topic of casting:

Sounds like you are misunderstanding blueprint classes and object instances.

When you have an object instance of type B which is referenced as class type A, and you need to access properties from class B, if you cast reference A to type B you get a valid cast if class B is a child of class A.

For example, Dr_Light class is a child of Actor class. You can pass around a reference of type Actor, the reference is pointing to an instance of Dr_Light, when you cast Actor reference to Dr_Light class you have a valid reference to an object instance of Dr_Light class… If the instance your reference is pointing at is an instance of another class then when you try to cast the instance to Dr_Light that casting will fail.

Casting result depends on the class of the instance you are actually casting from.

When you create a blueprint asset, you are “declaring a class” prototype, not creating an instance of an object.
You create an instance of an object when you spawn a copy of that blueprint in the world.

Thank you. That actually makes a lot of sense. I’m going to re-read this post a few times to try and get a more specific understanding of what you’re telling me. But pointing out the specific flaw (that I’m trying to cast to the blueprints themselves) actually helps a lot. I’ve only previously seen instructions in one-to-one scenarios where a single blueprint has referenced another single blueprint, and I think that’s where I got confused originally and it’s just compounded from there.

I’m going to take a bit of time to try and process the rest of what you said and see if I can make a few successful casts in the next few days to understand the

part of what you said better.

In theory at least, I get it now. If I make a blueprint that opens doors, casting to that blueprint would be complete chaos even if it worked. So of course that isn’t how casting is supposed to work. I just didn’t realize that until now as I’ve only seen 1:1 demonstrations where it’s been done that way (ie- getplayercharacter in an empty demo level being the most common way it is described.)

I appreciate your help. Now at least I think I have enough of an understanding to start searching for the right questions.

I realize that I’ve made 11 posts on these forums and they might all seem strange. So I’m just going to add, if it helps anyone understand my perspective, that 28 days ago, I didn’t know anything at all about any of this. And since then I’ve more or less dived in headfirst, not just to blueprints, but also Blender, World Machine, Photoshop, Audacity, etc. And I’m not just trying to follow tutorials and copy someone’s work, but to try and learn from them as I can to implement my own ideas.
So there maybe some basics that I’ve thus far been unaware of, and I’m sorry if I seem like a pest lol. But that is kind of Unreal’s thing in the modern age: Anyone can learn it if they just like headbutting walls consistently enough. And I’ve always been a fan of headbutting walls (joke, means I’m stubborn and passionate about learning new things.) But of course, 28 days of learning by yourself over the internet can leave a lot of missing gaps, especially when it has been so heavily divided between different aspects of the various workflows.

I get where you’re coming from. Taking your specific example of getting access to the internal parameters of a directional light.

I have had a problem here also. Some parameters are visible, some are not. You will find, for some obscure reason, that putting the directional light in a blueprint and droppng that in your scene will give you access to much more.

Reparenting the light, not a good idea, because there will probably be other systems that expect it to be a particular class.

Generally speaking though, if it’s not a BP written by you, you might not ever be able to get access to some parameters from blueprint. C++ probably yes.

If you have made BP-a and BP-b, then everything is accessible.

So, you don’t have a casting problem here, you just ( with the directional light ) have a problem that a lot of the parameters you see in the viewport are just plain not accessible.

If that really matters to you, then probably C++ is the way, but often there is another way of doing things in blueprint.

Long reply inbound, as I wanted to respond to specific things one at a time:

Okay, THAT explains a LOT actually. Because most systems where I’ve made the pieces from scratch have given me little issue. So it’s been doubly confusing that sometimes it is “just that easy” to send information direct from one component to another, but other times it feels like learning a new language and nothing I do seems to work. And looking back… With a single exception where I completely misunderstood “overlap events” (my pawn had VR hand bubbles that were making my brain bleed by triple triggering the volume, was a fun first day in the engine lol) everything I’ve had trouble with casting to has been pre-made in engine.

That said, Bruno is still right and even though I may sometimes accidentally do the right thing, I have been confusing Blueprints (classes) with Object --references-- (instances* I did it again. Reference is an index or pointer to an instance, if I’m getting this right) (the specific copy of the blueprint I had spawned in.) So even when it has been “just that easy”, it’s mostly been by chance or luck that I’ve gotten through that.

I was mostly just spitballing that suggestion to express that I was completely lost. I didn’t actually think reparenting would help. I just meant to imply that was how little I understand what I was supposed to be doing that for all I knew, it COULD be a method.

I don’t know C++ well. “Hello World” would be about 1/5 of all the programming I’ve ever done manually with it. However, if I can be assured a specific task that I really want to follow through on can only be reliably done that way, I would set aside the time to learn. That said, if I find any of those limitations, I will likely save them until the bulk of the content is in place. “Assurance of the possibility of release” before pursuing the things I expect to be most difficult and all.

Before diving too deep into development, try to search and understand the theory of “Object Oriented Programming”;

Blueprints are not like coding, but they are still heavily object oriented systems. You need to know well class inheritance, instances, and the overall ideas behind it to make good use of Blueprint system.

^ THIS ^ is solid advice. However if you have to meet all the rules of OOP, you may never get started making games (as its a lot to bite off). Game work is often chaos, as designs start out as one thing and then morph into something else as game mechanics don’t pan out / user feedback is negative. So expect to bin lots of nice looking object hierarchy charts. Also different game genres dictate different kinds of plumbing. If you’re aiming for RPG / RTS, you’re probably looking at a substantial amount of design work compared to an FPS-TPS shooter / puzzle / 2D (not much editor automation to help either).

However, there are ways to make life easier for yourself: 1. Cast early and then just use Direct Refs (Gamemode-GameState can also be used as a Casting / Messaging hub)… 2. Embed commonly used casts into Global-Function-Libraries to reduce bloat (achieve similar simplicity to Get-Player-Pawn/Controller / Get-Gamemode funcs etc)… 3. Simplify execution… Make Pawn / Character / Gamemode-GameState drive gameplay and invoke dependent components / widgets (rather than having callbacks which can add to complexity / circular references). Last thing, just accept you’ll have to rework code later anyway to make it more Object Oriented. This is the good thing about BP though, you can change designs quickly / easily. Whereas in C++ that’s its own special kind of hell. :stuck_out_tongue:

Alright, I’ll study the concepts of OOP more as I work. Thanks for the sage advice, Bruno.
Those are good suggestions as well Enterprise, I hadn’t considered that much.
Also, this is the way I learn. I’m used to jumping off the boat with no idea how I’m getting back to land. It just happens to have been the method that has always worked best for me when I really want to make progress. I usually scrap everything by the time I understand the difference between duct tape and craftsmanship, but I’ve found that duct tape holds things together long enough for me to get it together enough to know that difference.

Just wanted to thank you guys. Reading documentation and other forum posts, as well as trying to learn on YouTube, just never stuck. I was having a very hard time sending information between blueprints. Often because the examples would be an hour long, and the relevant segments would be 4 seconds in which the focal point (setting object references) would be given no emphasis and glossed right past.

But after clearing up for me specifically that I was confusing the classes and references, I have had my most productive day yet today, as I’m not struggling for basic interaction between different systems and actors. I’m setting up a dynamic lightning strike system with damage fields as a subset of my already variable severity weather system. And all because you guys, in what was really a few sentences, helped me work out that I was mixing up two very different terms.