How to call a button on a widget directly from an actor?

[Derkusmars]

Hello! I’m just learning BP (4 days of work) and don’t quite understand how to correctly connect a click event in the interface with the actor’s data. I apologize in advance for my English and experience in Unreal).

I have procedurally generated actors that contain data, they have an owner and they change depending on the data. Data is displayed in the widget when you click on it. All data processing takes place inside the actor.

I want to click on the button in the widget to change the data of a particular actor. I thought that calling the event directly from the actor would be a good idea. But apparently this does not work that way.

So far I have not found a more suitable way than the event dispatcher, but for some reason it does not work in this form. Maybe I’m not quite right to refer to the actor.

Please tell me how to solve this problem, or suggest another solution. Which is likely to be more correct.

Thank! )

[Est_engine]

Hi man,
The simplest way to talk between two things it to pass them they reference.
You can do it when you spawn them, or ingame.
Just find the actor using get actor from class, or overlap, or when you create him , save his reference.
And pass it to the widget (make a variable inside the widget before)

For Example, lets say we use the Gamemode that is avaible in all your levels.
Go in the Gamemode blueprint and add 1 varialbe actor reference. you have to set this variable when you create the actor, or find him.
From your Widget use
Get Gamemode- Cast to (your type of gamemode) and Get the Actor Reference you wanna talk.
Pin out a Call-Event or just set his variable.

[Everynone]

So far I have not found a more suitable way than the event dispatcher, but for some reason it does not work in this form. Maybe I’m not quite right to refer to the actor.

Does the “It Working!” print when you click?

[Derkusmars]

@Est_engine

Hi man,
The simplest way to talk between two things it to pass them they reference.
You can do it when you spawn them, or ingame.
Just find the actor using get actor from class, or overlap, or when you create him , save his reference.
And pass it to the widget (make a variable inside the widget before)

For Example, lets say we use the Gamemode that is avaible in all your levels.
Go in the Gamemode blueprint and add 1 varialbe actor reference. you have to set this variable when you create the actor, or find him.
From your Widget use
Get Gamemode- Cast to (your type of gamemode) and Get the Actor Reference you wanna talk.
Pin out a Call-Event or just set his variable.

Thanks for the answer ). In words, this sounds pretty simple.

But I still do not quite understand how to bind an actor to a game mode and call an event for this variable (

[Derkusmars]

@Everynone

Does the “It Working!” print when you click?

Unfortunately no(.

Otherwise, this question would not have been here.

[Everynone]

The BP_SlavCity creates a widget but the widget is never added to the screen - can you explain? Also, using dispatchers is absolutely the right way to do it and you’re using it correctly, too. Atm, it seems that you’re clicking on the wrong button - as in, you’re clicking a different button than you think you are.

[Derkusmars]

@Everynone

The BP_SlavCity creates a widget but the widget is never added to the screen - can you explain? Also, using dispatchers is absolutely the right way to do it and you’re using it correctly, too. Atm, it seems that you’re clicking on the wrong button - as in, you’re clicking a different button than you think you are.

Yes. This is for a future click event. No display is needed at this stage. I just show it when I click on an actor, substituting actor data.

And the button on the widget is the only one)

[Everynone]

This is for a future click event.

Makes sense. But even in the picture above we still can’t see *this *widget added to the screen. You do create and add *another *one but this new one has nothing bound to it…

Begin Play creates a widget with a bound event - that’s great! You then destroy it. Then you create a new - this new one has no bind. [HR][/HR]
Consider not destroying the widget (don’t remove it from parent). If you do not want to see it, hide it (set visibility - Hidden) - this is usually much better than removing and creating a new widget every time.

[Derkusmars]

@Everynone

Makes sense. But even in the picture above we still can’t see *this *widget added to the screen. You do create and add *another *one but this new one has nothing bound to it…

Begin Play creates a widget with a bound event - that’s great! You then destroy it. Then you create a new - this new one has no bind. [HR][/HR]
Consider not destroying the widget (don’t remove it from parent). If you do not want to see it, hide it (set visibility - Hidden) - this is usually much better than removing and creating a new widget every time.

Exactly! ) Thank you very much!

The error due to carelessness.

[Everynone]

See if this helps:

https://forums.unrealengine.com/core/image/gif;base64
​
The widget is created only when a widget does not exist. If the reference is invalid, we create a widget, add it to the screen and bind its event - it’s now visible on the screen. Next time the cube is clicked the widget is valid, so the FlipFlop hides it. Next time we click, the widget is still valid but the FlipFlop will show it.

This way you do not need to make a new widget every time, its data is retained and it’s a bit more user friendly this way.

[Derkusmars]

@Everynone

See if you this helps:

https://forums.unrealengine.com/core/image/gif;base64
​
The widget is created only when a widget does not exist. If the reference is invalid, we create a widget, add it to the screen and bind its event - it’s now visible on the screen. Next time the cube is clicked the widget is valid, so the FlipFlop hides it. Next time we click, the widget is still valid but the FlipFlop will show it.

This way you do not need to make a new widget every time, its data is retained and it’s a bit more user friendly this way.

And it does not harm productivity?

If a user (in my case) pushes thousands of actors during the game and simultaneously hangs thousands of widgets in invisibility.

[Everynone]

It depends on how heavy your widgets are. Generally speaking it is the creation of a widget that is performance hungry - this is especially noticeable when you open an inventory with hundreds of items - creating a bunch of widgets in a single frame is costly. Keeping them hidden or away from the viewport (but with intact references so the Garbage Collection does not pick them up) is often preferable.

Hidden widgets do not tick, they do sit in the memory - this is usually a negligible cost unless we start going into thousands. Do note that if you destroy and recreate the widget, you will need to set all its field from scratch, while a hidden widget keeps its data. In your case, it’s a single widget per click, so it does not really matter that much.

If a user (in my case) pushes thousands of actors during the game and simultaneously hangs thousands of widgets in invisibility.

It’s a larger memory footprint, sure. Do note that Poolingexists. You actively pre-create a lot of objects ahead of time and keep them ready. Spawning stuff is expensive during gameplay where frametime is critical, fetching existing stuff from memory costs next to nothing in comparison. If you have 10000 bullets flying in the air, each spawning widgets on hit (i’m talking about you, Borderlands), it’s way cheaper to recycle the existing bullets than create new ones. One would need to strike a balance here, of course; pools can be trimmed dynamically so they do not grow too much.

But do get your game going first and optimise later, definitely. For as long as you understand how and why the script behaves as it does, you’re good!

Good luck, it’s looking neat!

[Derkusmars]

@Everynone

It depends on how heavy your widgets are. Generally speaking it is the creation of a widget that is performance hungry - this is especially noticeable when you open an inventory with hundreds of items - creating a bunch of widgets in a single frame is costly. Keeping them hidden or away from the viewport (but with intact references so the Garbage Collection does not pick them up) is often preferable.

Hidden widgets do not tick, they do sit in the memory - this is usually a negligible cost unless we start going into thousands. Do note that if you destroy and recreate the widget, you will need to set all its field from scratch, while a hidden widget keeps its data. In your case, it’s a single widget per click, so it does not really matter that much.

It’s a larger memory footprint, sure. Do note that Poolingexists. You actively pre-create a lot of objects ahead of time and keep them ready. Spawning stuff is expensive during gameplay where frametime is critical, fetching existing stuff from memory costs next to nothing in comparison. If you have 10000 bullets flying in the air, each spawning widgets on hit (i’m talking about you, Borderlands), it’s way cheaper to recycle the existing bullets than create new ones. One would need to strike a balance here, of course; pools can be trimmed dynamically so they do not grow too much.

But do get your game going first and optimise later, definitely. For as long as you understand how and why the script behaves as it does, you’re good!

Good luck, it’s looking neat!

Thanks for the help and support). Good luck to you too!