Hello,
I have a slider in UMG.
Passes its value to Blueprint interface to be used in another blueprint.
UMG>Interface>Pawn
Not sure if I’m doing anything wrong or missing something
First time using interfaces otherwise I’ll just go back to casting.
Thanks.
You need a reference to the pawn here
and, the version of the interface call with the little envelope here
The pawn needs to exist in the world, so an actual pawn. You can change the default class values of the pawn blueprint.
Sounds like a threat! Heh, to cast you need a reference to the instance. Same for an interface. 
The difference is that when you cast, you do not need to manually select anything, the interface will look up what’s needed and cast for you automagically.
Its probably a threat to my projects performance.
I guess its unclear as the only thing I can drag off the object pin is a cast anyway.
So I’m missing something.
What is best practice for passing values like float across blueprints?
There is no best method. There is only a method suitable for the job.
You said you wanted to cast, so do the exact same thing but send an interface message instead of casting, as in the pic above.
:
No script in the widget is needed for this to work.
Depending on the scenario, if both actors are in the scene and that’s it, you can reference them directly and never cast, use dispatchers or interfaces. It really depends on the bigger picture.
I’m trying to learn interfacing as well.
I will get the job done regardless. I just thought it was smarter than it was initially.
Your solution is informative though.
Give me a a few minutes to make it modular. Id want to call it from all kinds of places for multiple reason not just this slider in the widget. I guess I’m also stuck on trying to reference an actor who isn’t in the scene before ‘BeginPlay’ as well.
Think about it like this:
You want to send a message 
to a specific actor instance 
that has this function implemented via an interface:
Which instance of the actor would you like to send it to? What if there are 10 dudettes in the scene and their eyes need fixing up? How are you choosing who to send the message to?
It does not matter how many instance there are, even if there is only one - you need a Target - that’s the pin.
People never have issues with interfaces or casting ← this part is trivial, it’s just one node. They have issue with referencing - finding which actor they want to talk to.
How to approach things depends on the job at hand. For example, if you’re possessing a pawn and want to communicate with an interface, you can just:
There can be only 1 possessed pawn at a time so this will always work (unless you destroy the pawn, ofc - then it will fail quite gracefully). As mentioned above:
You need a target to send the message to.
Yep, I get it.
Same function but we have to delineate between a hypothetical magnitude of the same actor, hence the requirement. I just have to get my reference in there in a way that makes sense for my application to be modular.
I’m just putting together something crude as a baseline that has a potential future and will give you the kudos.
So the solution for me specifically was ‘Get Actor of Class’.
Am unsure about how expensive this is. If someone could comment.
Input
It’s the worst possible solution that works:
When you drag the slider, it fires as often as it can. But perf is not an issue if you just use it here like this. No need to demonise it.
The thing is it will stop working correctly if you have more than 1 pawn. That node gets the 1st actor it can find, not necessarily the one you want. It may work now, it may not work tomorrow or after shipping.
Why do this? How many pawns do you have? If you have 1, possess it and get it from the framework.
Also, not only are you’re sending the incorrect message (note the yellow icon mentioned in the posts above), but this utterly defeats the use of an interface. That node already returns the correct type:
Call what’s needed as is. No interface needed, no casting.
For this purpose it will only be a single pawn that will change skeletal mesh and material instance parameters.
I have another idea of using 5 actors of different meshes but they will all use the same variables for values like hair/eyes/colors. They all use the same Material instance as while the mesh is different the UV is the same.
So a healthier alternative would be nice too, if there were 5 actors hypothetically (Not necessarily pawns as they are just animated, no possession).
At the end of the UI route I was going to have the final one possessable for a seamless tutorial but I am very much letting limitations drive the narrative.
Pretty much as robust as it gets. No possession necessary. No casting or interface needed if step 2 was skipped. There should be no script for this in the widget whatsoever. The widgets’ job is to show stuff, rather than finding actors that may or may not exist.
I pinned a lot of gathering nodes in the widget blueprint based on button and sliders etc to pass the data out of there it felt more natural that way from a design perspective, but you’re saying the best practice is to just listen for these outside of the widget blueprint?
That looks spot on. Yeah, widgets trying to pull data is like pulling teeth. Can’t recommend it.
And if you ever need to get to the widget or to the spawned actor, their references sit right in the Game Mode that is reachable from pretty much anywhere via a single cast to a class that is already loaded anyway. Virtually no cost.
one interface and the other a native calling a function.
To clarify, the Create Event node is an Even Dispatcher. Actors and widgets already have a bunch but you can also add your own with custom signatures to carry data across.
Good luck!
This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.
