I have been trying to find a way to make a system that allows the player to open the inventory of a nearby container by being near it and opening your inventory (kinda like the terraria). but the widget refuses to ever be seen.
this BP is apart of a character BP, this piece well for getting the “hotbar” to work but the attached code that involves making the container inventory visible. I can’t progress making this work if the widget refuses to even be visible. I am using what worked for the “hotbar” widget that work… but not with the container widget. (yes both prints do go off successfully)
On the Add to Player Screen node, try clicking teh tiny arrow at bottom to expand it, and bump the Z Order up. If you already have widgets on the screen, UMG might just be burying/culling it. I’ve had a problem like that where an option menu would never display until I bumped the Z Order up to like 6.
good news: a layout error is the easy one to fix. how anchors work — the anchor defines what the widget’s position/size is measured against. the fast fix is in the designer: select the root of your container widget, open the Anchors dropdown (top-left of the designer), and pick the preset matching where it should live. for a container panel that pops near the player, Center or Full Screen is typical.
two gotchas: (1) changing the anchor preset keeps the current offsets, so afterwards zero out Position in Details → Slot (Canvas Panel Slot) and set an explicit Size — a canvas child at 0x0 renders nothing no matter what. (2) with a point anchor like Center, set Alignment to 0.5/0.5, otherwise the widget hangs off to the bottom-right of the anchor point.
also check the parent: anchors only mean something inside a Canvas Panel. if the container is a child of a vertical/horizontal box, the slot is Size Auto vs Fill instead and anchors are ignored entirely.
debug trick that beats guessing: give the root a Border with a semi-transparent red brush — you will instantly see the actual rectangle being laid out: zero-sized, off-screen, or under the hotbar, all obvious at a glance. and the widget reflector (window → developer tools → widget reflector) shows final layout boxes at runtime with exact sizes, which tells you in one look whether the fix belongs in the widget itself or in how it is added to the screen.
I think the anchors are fine because my other two HUDs that work fine with each other are designed similar and so is the HUD that is not working. The alignments I didn’t know about so that made the widgets snap in place better but the main issue is still present.
The one with the black border is the one not working. The other two work perfectly, even together. Maybe these images can help. tysm btw for trying to help me out
Are you using the IA_Menu input action to call what is not showing? if so, the flip flop execution outputs aren’t connected to anything so nothing besides setting the internal flip-flop macro var will happen. You may need to connect your A and B pins to the branch, OR, just use the A and B execution pins to set your visibility.
If that doesn’t help, let us know more about where RunMenu get called vs the IA_Menu input? Talk about what the sequence of events you’re expecting to happen with those two events.
I had it like that because the filpflop didn’t want to work a few days back. I shaved off the branch just now and It seemed to work fine. It still doesn’t fix the main. The custom event is gone now so don’t worry about it. as for the widget not showing up, I’m still clueless why it don’t work.
You can change ‘collapsed’ to visible temporarily, just to make sure it shows.
Try adjusting your BP so you’re only piping in one object per ‘target’ input; meaning a separate call to setvisibility for menuhud and containhud. Having more than one target is generally ‘legal’ but is bad form and can lead to odd behavior.
Instead of adding widgets to screen one at a time and fighting with z orders/conflicting anchors, you should consider adding them to a parent inside the main hud widget itself.
In my action rpg project, the main hud widget has an empty panel anchored on the left for inventory and one in the center of screen for loot/chests. My inventory and interact keys call functions on hud widget called InventoryToggle and LootToggle which creates an InventoryPanel widget and uses Add Child to stick them to the matching panel.
The inventory toggle looks the same, only I don’t need to pass it an external “owner” ref to get chest/corpse inventory since I can just get player pawn.
Doing it like this not only means less headaches with z order, but it lets you layout the whole hud in one design window (minus details like dynamic inventory grid/lists).
I was planning on doing that but I thinking that it might have issues down the line. But seeing that you can do it without it conflicting too much, I might as well. ty
