Removing a widget with button press

But you can call an event in another blueprint. If you create the call first there is no way the blueprint system can know where you want the red event node. That is another reason you must create the event node first.

If the event and the event call was limited to the same blueprint and could not call external events then I would agree with you, but …

Yeah please keep in mind that I am not arguing against you (lack the knowledge anyway). Just telling why I am having difficulties sometimes understanding the logic. I do get your point and everything you write makes perfect sense.

Can you tell me where the event is created (stored)? I don’t have to place the red node, right? But the event exists. Is it in the blueprint or in something “above” the blueprints?

I was trying to make you understand the reasoning for the event node first, call node second thingy. Sorry if this came across as arguing!

There are two “parts” (kind of) to consider when creating a custom event. The actual event node (the red one) and the node to call it (which is blue). This whole setup is almost like creating your own specialized node (the call node) and the code for that node is everything attached to the red event node.

There is nothing automatic about the custom event creation. You must create the event node first and the call node second. Nothing exist before you create any of the nodes.

The event node can be set up with its own in-parameters for example. So if you need to send the contents of a variable from one blueprint to another you can create a custom event with an in-parameter of the same type as the variable you want to send. You place the event node in the blueprint that will recieve the variable and the call node in the sender blueprint.

You decide where the custom event node is created. In a lightswitch example the event node goes in the light blueprint while the call node goes in the lightswitch blueprint (for example). So … the event node is the actual event while the call node triggers that event.

WHERE you create the event node depends on what you are doing and how you do it. In other words there are no simple answers.

Placing the event node in one blueprint and the call node in another is actually rather common.

This answer turned out to be really chaotic, but I hope you can figure it out somehow. :slight_smile:

I think part of the problem for me was that I didn’t know the call node was a call node. For me it was just a way of telling the program that “X and Y are now together Z”

You see, I saw it the other way around. Here:

I thought you first tell the program that the first line of events equals WidgetIsOnScreen. I thought the definition of what WidgetIsOnScreen is is the first line (like E, Create Widget, Add to Viewport then EQUALS WidgetIsOnScreen)

But what you are actually doing is defining what WidgetIsOnScreen in the lines under the call.

What I am trying to say is that I confused the creation/definition of the event with the call of the event.

So what I thought meant “X and Y are Z” actually means"X and Y lead to Z"

Of course then the creation of a red node would seem useless to me since I thought the call was the creation. Lol. What a brick in my head, seriously.

This is also why you misunderstood my question and I misunderstood your answer. I see things much clearer now.

Ahh! That explains a few things.

I never though it necessary to explain that the red event nodes make up the starting point of an event. This is hardwired into my brain to such a degree that I would never have understood that you saw it that way if you hadn’t explained it.

I knew that, I just didn’t know that the call node is nothing else but a call node.

Oh. Okay. I understand now.

By the way, I just got this stuff working in the widget blueprint that I was trying to get to work ALL THE TIME by casting (the toggle function). The solution is super simple - just set “get all actors of class” and then after it call the function from the class blueprint. Done. “Out Actors” is what has to go in the target for the function.
I can’t believe it took me opening 2 threads and googling for hours to find this.

Now I can die in peace. I mean…at the end of a long, fulfilled life, of course.

Good that you found a solution to this!!!

However … a friendly word of warning about the “Get all actors of class” node. As the name says this node gets ALL actors of the target class which can be slow. Epic’s documentation on this node says:

Find all Actors in the world of the specified class. This is a slow operation, use with caution e.g. do not use every frame.

The general rule is that the more actor you have in the target class the slower this node is going to be and it is a potential performance drain. I think it is important to be aware of this when using this node!

Thanks for the information.

Well I would do it with casting, but I STILL don’t know what to put in the “object” slot. Every question is about casting stuff to the player, so everybody plugs “get player controller” and so on in there, but since I want to cast to another actor, I can’t seem to find anything to go in there.

Now I managed to get the whole blueprint actor as variable, I can plug that in, but it still requires something else for “self”, I have no idea what I am doing wrong with the casting. I can’t find information about casting to a blueprint that is NOT the player.

116685-unbenannt.jpg

Get all actors of class seems to be the only way.

Or do you happen to know what object has to go in there? I’m still fiddling with the widget blueprint communicating to the actor blueprint that contains the widget.

It quite bugs me that it doesn’t seem possible to access a stupid bool with casting.

Does all communication only work when a player controller is involved in it?

No. The player controller is just another blueprint, but Epic in particular seem very fond of using this as an example.

There are several ways to communicate with other blueprints. The problem is that there are no universal solutions. It all depends on what you are trying to do.

As I mentioned in another comment here inter blueprint communication can only happen when the blueprints exist in the game world, but from there you can choose method of communication.

Direct blueprint communication is probably the easiest. The catch is that it can only work when you know which blueprint is the sender and which is the reciever AND you know for sure both exist in game world when the communication is to take place. This also means that casting is not necessary.

If you don’t know the reciever you have to use casting to make sure you “hit the intended target”. Take a look at this example (if you haven’t already): link text

I can try to set up a direct blueprint communcation example if you are interested!

There is also something called Event Dispatchers and Blueprint Interfaces. These are a slightly more advanced so I recommend “wrapping your brain” around bp-com and casting first.

But how can I make the widget blueprint exist in the gameworld? Do I have to drag it in the scene?

It’s still something simple I want to do, and I just want to do it because it keeps bugging me. Cast from a widget blueprint to an actor blueprint.

As I said, I even got the actor as variable but it does not help. I tried to put every single component that’s in the actor in the object slot but it doesn’t work.

If you could set up an example where 2 blueprints communicate with casting WITHOUT player controller or “cheat nodes” like OnTriggerOverlap (because it has the “other actor” slot and you can just put that into the object slot of the casting node, does not count because I don’t use OnTriggerOverlap)

Do you think you could set up an actor blueprint with different components and a widget blueprint and cast from the widget to the actor, accessing a variable from the actor?

And then please tell me what you put in the object slot and how you made the actor go in there.

That would help a ton, seriously.

The example you posted did not help me because they just plug the player controller in, but since I am not casting to that, I still don’t know how to get my blueprint actor in there.

Get all actors of class is like this

116781-anigif_enhanced-buzz-8611-1403171250-5.gif

That gif is amazing! Get all actors of class is okay to use when testing stuff and prototyping, but be careful if you intend to use it in a finished game.

Okay. So I have good news and bad news.

The good news: I have been able to send the contents of a variable from a widget blueprint directly to an actor blueprint.

And the bad news: I have not been able to do this with casting.

I tried to send a string variable (inlay on the first screenshot) from the widget blueprint to the actor blueprint and I had to use an Event Dispatcher in order to get this to work:

The Event Dispatcher (“SendVariable”) is located in the widget blueprint and is set up with a string input (as you can see in the details section on the screenshot). I am using an ‘event construct’ to activate this and the delay node is to give the actor blueprint enough time to set things up properly before the dispatcher event is called.

In the actor blueprint I use Event Begin Play to put the widget onto the screen and “activate” (bind) the event from the event dispatcher:

After the delay node is completed in the widget blueprint the SendVariable_Event in the actor blueprint will be triggered.

I used an empty blueprint project for this in version 4.13.2. I have included a [ZipUp version of it here][3] so you can disect it if you wish! Ask if you have trouble!

Thanks a bunch for your effort!

So…there’s a great tutorial on Event Dispatchers from a guy called Devils D, I have tested with this stuff before and I’ll look at your example. Maybe I’ll use Event Dispatchers then, but what I am using in my game should be rather harmless, I don’t have many variables and stuff and right now I am using get all actors of class only in 2 widget blueprints to access a bool, but I think I can replace it with an event dispatcher.

What would really interest me though is why did you not make it work with casting?

What was the problem?

There is no problem. But in this case you don’t actually need to cast. The reason for that is that you already know which blueprints are communicating with each other.

You can test this with my project. Open the actor blueprint and add a ‘cast to widget blueprint’ node. It can be anywhere in the blueprint and you don’t need to connect the white execution wire. The bind node needs a reference just like any other form of blueprint communication and that reference is the return value from ‘create widget’ node.

If you try to plug the return value from ‘create widget’ into the object pin in the ‘cast to widget blueprint’ node and compile you will get a warning saying that the return value is alreay a widget blueprint and you don’t need to cast:

Casting is only necessary when you don’t know exactly which blueprint you end up communicating with. Just like in the first person example where you want something cool to happen if the player shoots a specific target (or blueprint class). You’ll need to cast to know what the player is shooting at. If the casting fails the player did not hit the ‘something cool’ target. If the player hits the target the casting will be a success. If you know what I mean?

I tried to recreate what you did with my example project but it did not work because again a target was required that I couldn’t deliver.

Maybe I fail to explain properly or don’t grasp something fundamental.

I still can not transport one variable from one blueprint to another. It still requires a target and I still don’t know what target it wants.

Look. It’s actually not that hard, but as I said, maybe I am overlooking something super fundamental.

I made a few pics to explain again what I want.

And in the last pic I made a workaround that works as well. There I created a custom event in the player blueprint that sets a different bool there to true, then call this custom event in my BP_Texchange3, and then cast to the Player blueprint from the Widget blueprint, which works. Without the player character to plug into target I can’t make it work. Is this workaround also bad or better than Get All Actors of Class?

And if I don’t have to cast, how else do I access the variable? As you can see it requires a target.
What target?

I can create a reference of the actor in the level blueprint (as you can also see on the screenshot) but only there.

Also about what you said: I get casting is not required if you already have an event dispatcher. Too bad the event dispatcher also does not work. I didn’t save what I set up with it but I’ll do so and show you that it also requires a target I don’t have.

So my answer to this became HUGE so I had to include it as a PDF file. I have also included a ZipUp of the project!

EDIT: Oh … I forgot to add ask if you have trouble! Sorry! :slight_smile:

Haha thanks!

So I read your PDF and I know what you are doing because I did exactly this with my BP_Texchange3, I made it a variable, it is public, but it STILL requires a target.

Maybe I did something wrong with it though, I’ll try it again and do it exactly how you did it.

If it doesn’t work, can I send you my example project and you just have a look at it? Who knows what I keep ■■■■■■■ up there. I’ll delete all the unnecessary stuff and comment on the rest, so you can figure out easily what is where.

Haha thanks!

So I read your PDF and I know what you are doing because I did exactly this with my BP_Texchange3, I made it a variable, it is public, but it STILL requires a target.

Maybe I did something wrong with it though, I’ll try it again and do it exactly how you did it.

If it doesn’t work, can I send you my example project and you just have a look at it? Who knows what I keep messing up there. I’ll delete all the unnecessary stuff and comment on the rest, so you can figure out easily what is where.

But also you have a sphere interacting with a cube. I have a widget, and I don’t want to use the overlap, I am already using it for something else. Why do I have to use the overlap to use this? I read this in another thread as well where someone wrote the difficult part is to create a reference of the actor and you can do it with overlaps and a bunch of other things. Why?

The overlap is just in my example. You can use anything you want to trigger the communication. I just though it would be easy to understand because overlap is a very common mechanic.

If you did exactly what I did in the PDF and it still need a target, you must be doing something wrong. That is my first initial reaction to reading that, anyway. Buuuut I could be wrong.

I’ll be happy to look at your project and see what I can make of it!