Can someone please tell me how can I disable the widgets from overlapping on eachother?
You can set the Z-order of the widget when you add it to viewport in the blueprint, higher number means higher priority
The method you are describing is working okay, but I want whenever the user clicks on a tower, the previous widget collapses or just destroyed, I’m not sure where that should be implemented exactly.
I thank you for the picture.
Here’s my Bp , you might know the solution to my problem:
After setting the visibility, try adding Get Actor by Class and get all the actors of the BP_Tower. Run a for each loop through the actor array, and compare if the current actor == self or not. If not, then set it’s visibility to false, and do nothing on true.
You can create your widget in your player controller, save it to a variable.
Then from your TowerBP, call an event in your player controller to create that widget(and pass variable parameters to it). Whenever that event is called, you can say widget>isInViewport>RemoveFromParent>re create widget for example. That way you only have 1 widget on screen.
You are just getting the element which is on the first index. Try looping through them all, as I’ve done in the image below. I think this should fix your issue. Keep this thread posted
1 Like
Done as told, clicking on tower now won’t display the widget since it is set to hidden.
i’ve set it visible just to test it, and it does display, but same issue of having multiple widgets at the same time.
Normally, something like this is handled in one of the 3 ways, providing the goal is to show 1 widget at a time:
- you either have a manager blueprint who controls what, when and how stuff is displayed. You can even dispatch to a framework class in lieu of a dedicated manager - the
Player Controller/Game Modemay suffice. That BP would store references in order to hide current → show what is requested. - or you add widgets to single-child-container, the old widget should would pop-out atuomagically. Named slots work pretty well for this due to their versatility. I’d opt for that when working with non-component widgets and had some kind of Main UI.
- or you could have a single widget component in a class that can render (so not in the PC/GM),
Set Widget Classdynamically and pipe in fresh data. This can be pretty efficient, especially when you extend theWidget Componentand let it handle the swapping logic internally. You could then reuse components like for other things where a modular interface is needed.
And I’d strongly recommend against Get All nodes. But that’s wishful thinking. 
1 Like
That is a bit advanced for me at the moment, even though I’m trying my best to logic my way through it, also I find it very odd that there isn’t a video on YouTube that talks about this specific example, even though there are multiple videos about widgets and how they function, but having multiple ones overlapping on the screen hasn’t been tackled before it seems 
To simplify it somewhat:
- if this is the player controller:
- and this is your actor with a widget:
- clicking an actor tells the PC (pic 1) what to do with it:
1 Like
