Blueprint Interface - Any assistance will be appreciated

Hi All
Wondering if anyone can assist me, not with a tutorial as I have gone through many, but rather possible causes for the Blueprint interface not working at all?

I am forever struggling with Blueprint interfaces, I have read the manual and still cant figure out why I just cant naturally plug in Blueprint interfaces and it just works. It could even be because I have picked up a bad habit and doing things backwards, whatever it is I need to figure it out now to stop future frustrations.

Any advice regarding common mistakes one can make, or even a dead simple easy to understand Blueprint interface Messages/Call/Bind/Events/etc… would help me greatly.

Thank you for your assistance.

I’d like to chime in to say that this is a topic that I’m quite interested in myself. I just switched over from Unity3D and am having a lot of trouble trying to figure out the whole paradigm behind drawing textures on the HUD. I’ve been able to draw stuff on the screen, create show rendertextures, etc. but the I haven’t been able to put widgets to use or create anything more organized.

Have a peek at Unreal’s UMG demo, it was an awsum demonstration of how to attached different UMG’s to one, also event dispatchers, etc… I’t was a great tutorial. But as mentioned when you dissect it and want to adapt it to your own functions, just doesn’t seem to work at all.

(???Getting the feeling you cannot use interfaces without having atleast one output or one input???) - Confirmed you dont need to, but if you do put inputs or outputs, you are converting the Interface into a function it seems.

Some extra feedback 16/01/2015:-
So it seems that the test example I made works flawless.So I can determine that a bad habit I started doing was not using CAST TO, why I started this bad habbit I dont know.

Advanced Question:-

Is it possible that the object you are trying to send the communication to has to be possessed? (If it is a actor?)
Tonight I’m going to make my project available so perhaps an expert can download it and point to why it just wont work or a work around for my problem.

This is getting really bad as I have spent a week trying to fix this prototype concept I’m making with absolutely no progress, this blueprint interface has caused such a halt on progression.

Lots of views but no answers. If my describing of the problem is lacking clarity please let me know.
I am getting pretty desperate for an answer why Event dispatcher and Blueprint interface is causing so many problems.
1). Event dispatcher, if you open a blueprint that makes use of a event dispatcher, you cannot open and re-edit (Still don’t know if I did something wrong of its a bug)
2). Blueprint interface, call messages and event just isnt working.

However I do realise that its possible due to UMG still in experimental stage, I just would like some sort of acknowledgement that UMG using event dispatchers or Blueprint interfaces are just buggy. Then I can move on and find some other way to implement this prototype.

Hi Archieochoke, can you upload your test project somewhere I can take a look? (Don’t include the Saved/Intermediate directories)

Thank you very much.
Data will be ready by tonight.

So typical problems with blueprint interfaces:

  1. The actor you are calling the interface method on hasn’t implemented the interface. You can test this with a “does implement interface” node before calling the interface function on the actor. If that returns false, make sure your actor has actually implemented the interface (i.e. you go to your actor, go to properties along the top, click it and in the defaults part of the actor editor you should see “interfaces”, make sure your blueprint interface is specified there. If it isn’t click the + and add it to the interfaces array.

  2. You are calling the wrong method

  3. You have the wrong actor you are calling the method on. Print out its name and make sure its the correct one you expect.

  4. Erm… not sure :slight_smile: they aren’t particularly problematic for me.

This all comes down to learning how to use the blueprint debugging tools though. You’ll soon learn where you are going wrong once you figure out how to use them (inspect variables, step code etc). I suggest reviewing the blueprint debugging toolset at some point. Debugging is a skill you have to practice to become fluent with.

Good luck!

Binding only works one on one, say you have a dispatcherA, whatever last binding call will be the events gets bound to when dispatcherA called.
Also, when you bind, the signature have to match, otherwise the bind would cause error.
And then I would certainly suggest you to avoid CAST TO, “unless” it’s a native C++ class. Approach problem with Interface is correct decision, CAST TO is simple and straight forward but you can’t get far with it.
(cause circular dependency of blueprints will eventually happen if you use a lot of cast to.)

Since you didn’t reveal all that you have, it’s hard to determine what went wrong.
My guess is the “target” to call PowerOn is not the class you have implemented interface function.

Since this thread is all about blueprints, I moved it over to the Blueprint Visual Scripting section so others can benefit from this. :slight_smile:

Herewith an Album of the different blueprints:-


I have created an image that describes the basic functionality:-

Demonstration that the button does have an effect on the LED display:-


I forgot to add proof that the Interface is added to the props:-

The Blueprint of the Wall:-

SingleUnitsPowerDisplay - Widget
This is where the basic design was done, however this widget has become uneditable whenever you try to add more code to it, if you remove the Event Dispatchers you are able to compile again. Soon as I add it all of a sudden crashes UE4.



InfBatDisplay - Widget

This widget makes use of the “SingleUnitsPowerDisplay” widget.

InfBatDisplay - Widget

Bleuprint part1:-

I forgot to add proof that the Interface is added to the props:-


The rest of the functions look the same, no input and no output.

Hi there, I noticed you have deleted many of your previous responses in this thread. While you are certainly free to do so, it can make it difficult for others to follow what is going on and try to help. I would recommend leaving all posts even if they have outdated information. Not only for those trying to help you right now, but also for those who may have the same problem and read this thread in the future.

Again it is totally up to you, if you ever want to have a deleted post restored, any of us moderators can easily un-delete them for you, just let us know. Thank you!

I apologies for this, my intention was to only ensure once I have gathered all the information that I could gather, I would do a complete post at the first post, explaining the mistakes that were made and concepts I have gathered through troubleshooting the issue. I completely understand your concern if you wish to restore them I have no problem with it, I was trying to keep this post clean and not make it a huge eye sore as previously I have been reprimanded for large images on other forums. Is this not an issue with Epic?

Once again I apologies for removing them, you may restore at your discretion.

Oh no it’s not a problem, no worries! No need to apologize, sorry if it sounded like that. :slight_smile: If you’d prefer to add it all to the first post that is just fine too! But don’t worry about cluttering the forums when you are posting about an issue your experiencing, the more details the better. It’s totally up to you, I was just making an observation.

Large images are just fine! That is not a problem at all either, it makes it much easier to find the problem. Hopefully the images help track down what is causing this issue.

okay…I can see 2 things that’s weird off the bat.

  1. you have getPlayerCharacter(which needs an index) and then cast to and set it to a my character variable. this is probably not a good idea, cause I don’t know if what you get from that function call is what you want.
    generally, if you can’t see a function from context menu out of a “self” node, you shouldn’t really call it with out any thing linked to it. Consider you have a BP that is not a Pawn, I doubt this would function properly.
    And, if your game are going anywhere near multiplayer, the player index based call are best avoided in blueprints.

  2. Blueprint Part1:- where you have assigne nodes, latter you cast InfiniteBattery to InfiniteBattery class, and then set back to InfiniteBattery variable, while another “PowerOnStuff” takes that variable as input.
    This could cause potential problem. If your class already implemented an interface, you can cast them to a parent level class(ie Actor/Pawn) and then just call the interface function directly without even cast them back.
    In your method it looks like PowerOnStuff could take only InfiniteBattery? If so then if you happen to have buttons constructed and before the cast/set finished and clicked on the button, you could have problem.
    So try to avoid assuming that something must have finished before another event could be called.

And lastly, I wanted to know if I’m reading the BP right:
You have a Wall object that have widget component that you can interact with, you have also a parent widget bp and another widget inherit parent layout and do special things.
Say you can have a InfiniteBattery, and a RegularBattery(where it can be run dry), and still have the same BP interface to click on and draw power from.

Now, what I have to say may be really shocking to you, but the events with UMG widgets(ie button/sliders/etc), they can already be bind to with other events with in another actor if they have access to reference of that instance.
(for one of my projects, I have actors to fill up a empty vertical box layout on my player’s hud when they interact with different objects, so each object can have different interface when player try to modify their parameters without having to create entire widget for each of them, just some custom parameters that only that object class has. )

Also, any inherited widgets from parent, if you check “inherited variables”, or in the layout editing mode, select your widget component and check “make variable”, you can then access them in blueprint as well.
This will greatly reduce your usage of dispatcher and cast, from the look of your bp, you basically tries to build a passing through dispatcher/binds on top of existing ones.

If you are confused, please explain with bullet points what you want to achieve.(without your current implementation)
I could probably do a simple one then upload a project so you can reference it.(and also upload to wiki’s tutorial section)

Let me know if you understand, this part is a bit hard to explain with just text only, so maybe a demo with blueprint screen cap and example would work best.
Put it simple, any event in the layout edit mode, when they have a “Bind” drop down menu you can click on, are already a event dispatcher.
If you DO NOT create functions that binds to it using the drop down menu, you can bind events to it from any other actor that have reference to this widget instance.
(you could bind with drop down menu and then override it later, but it might be best to avoid it, I’ll have to test to be sure since UMG is still kinda new.)

Hi thank you for your comments.

  1. The prototype im making wont cater for multiplayer as yet(Thinking maybe or maybe not, not sure), I was going to use the GetPlayerCharacter as a means to know if it was the player that overlapped(A Sphere component on the wall) as I have attempted to use GetActor = Mycharacter = Isvalid technique and didn’t get the results I was hoping to get (As the wall is a completely serperate actor that the player wont posses, but only use as a control panel). Then I moved onto GetPlayerCharacter, which from my understanding gathers the information of what DefaultPawnClass is being used**? (Is this wrong?)** in the map at the time based on your world settings?


Are you refering to the Actual “Get a reference to self” as displayed above?
If so then I should in future stop using The Default Pawn as an Actor, rather use a proper Pawn Class (For multiplayer use) - True/False

May need some clarity on how this can be done, with some pictures if possible.
When we are refering to ParentClass, are we reffering to the Wall, as it would be the Actor, that would use the Component Widget making it a child of the parent?

I added a custom event in the wall as to try any means to get this to work. Was wanting the interface to be a one stop switch everything on function.

I could be misunderstanding you here, but let me elaborate my thought process. Are you referring to the order of the way it is constructed. ie. (1.Wall ; 2. components ; 3. rendering umg? )
This section seems to work fine, the event On/Off/Destroy/Spawn prints a message everytime it is pressed, however the part where it is supposed to cast to the Wall, doesn’t print. I.e. EventPowerOn (PowerSourceInterface)

But you are right, the approach I have taken is flawed.

You are correct.

Here is the design Template I made up, as you can see Im struggling with getting the Lights section going. From there I was going to create an array for each Dip switch. Then an Array for each object that was spawned.

• I want an Object that looks like a wall. The UI looks very similar to a Distribution Box / Fuse box found within a home. You have your 1. Mains/Dip switches(Which comes from an Infinite power source), then you have 2. Mains/Dip switches (Which is fuelled by solar, fire, gas,turbine) sorta like an inverter/UPS.

• These two would fuel other sub separate Mains/Dip switches that would act like your plugs, lights , geyser, stove, etc…

• The interface would have have the ability to spawn a light (= light mains) and draw power from either of the 2 main switches.

• Each Sub interface was going to have the ability to spawn set objects that can be placed in the world and powered, user will power by switching it on at the object.

It might work if it’s entirely local only, have to test to be sure. And if you ever consider multiplayer, you have to do it from the beginning, otherwise you might have to rewire at least minimum 30%+ of your graph even when you plan it very carefully.
If you are going to test if player overlap with a trigger box component, it’s even easier, cause the overlap begin event you can then detect if overlapped actor is a Pawn(player controlled), then you can use GetController node from a pawn BP.

Yes. And True no matter if you do single or multiplayer. You probably need to study a bit more to what refer to as Actor/Pawn or what class or object instance means.
Read through the documents more carefully, and ask if you feel confused.

Blueprint can be inherited, there are several special cases but generally, if you base type is decided, inherited BP are the same type.
Ie. if you have a Pawn BP, if you inherit this parent BP class, your child BP will also be a Pawn BP.
In your case, you seem to inherit your widget BP for battery from SingleUnitsPowerDisplay. It’s totally legit just the way you setup onclick is over complicated.

From your description, it seems that you want to have switch dependency, and then a switch can control any object that switch spawned and placed in the world.
It’s not really simple when you do it from the main switch, it might actually be simpler when you do the subswitch and it’s spawned actors first. Use simple actor to establish relationship, like a GenericApplianceSwitch BP and a GenericApplianceActor BP, flex out all the details and then inherit all light/stoves/etc with these 2.
Then you can establish a GenericPowerSource BP that have proper relationship with GenericApplianceSwitch BP, so that when GenericPowerSource gets switched off, GenericApplianceSwitch attatched to the power source will be cut off power as well.

My recommendation for you is to go through these topic and find related tutorials.

  1. Epic’s blueprint tutorial about light switch and overlap when player enter a trigger shape.
  2. blueprint communication
  3. UMG have less tutorials, but ContentExamples have a good level demo many commonly used aspect. And widget component is still tagged as experimental as of 4.6.
    (means if you assige a widget BP to a actor so that the widgets will show up in 3D environment instead of player hud.)

It would be kinda cruel to just dump a example to you and you have no idea how or why I approach things.
So it’s better that following these conversation, and ask question as you like, and finally clicked and understand how you would approach and design your own logics.
Your design template is good, it’s just that you are still new to UE4 so that you can’t use the tools efficiently yet.

actually, as a test project, see how fast you can pull this off.(will help you in the long run and also related to your project) (started with a 1st or 3rd person template)

  1. have a actor(name it SourceBP) that is just a box and static(non moveable) so you can drag and place in the world.
  2. have another actor that could be spawned(name it SpawnedBP) with custom shapes upon using spawnActor node and are physics actor so player can collide with it and nudge them around.
  3. have a interface that have 2 functions: changeColor(accept a color as input), and destroy(no inputs) When SpawnedBP implement it, you can switch color on it’s mateiral attached to the shape, and destroy itelf.
  4. drag 3 SourceBP on to level and put in different corner. use trigger shape and overlap event to enable/disable input.
    Goal: when you approach sourceBP actor on the level, left click will spawn a Spawned BP with a shape you assigned to sourceBP when level editing.
    right click will change color to all SpawnedBP actors that are spawned by this Source actor. And press ‘X’ will destroy all SpawnedBP actors that spawned by this Source actor.

No widget BP is involved, but if you are able to do this, then all the basic communication wise aspect for your project is basically an extension of this test project.

Thanks, just opened the content example for UMG and its pretty extensive on UMG Designs. Will start a different project and use the umg example to see if I can do things differently.
Thank you for taking the time to explain some concepts and having the patients during this time. It is highly appreciated.