Hi, I’m adding a pause menu to my game that consits of three widgets. The main one is display2 and I can’t seem to get it to reopen. When I press escape once it opens and when I press it again it closes, but after one go, it doesn’t work anymore. I tried to do this with a Flip flop and failed, so now I’m doing it with a branch and still failing. I tried doing it by setting it’s visibility on default to hidden, on begin play adding it to viewport, and by pressing the button changing from visible to hidden and that didn’t work, so now I’m just creating it and removing it from parent every time. I would really appreciate the help soon, because I’m running low on time.
As for your first attempt, it works fine to me. Are you sure the inputs are working? Place some Print Strings right after the FlipFlop to check if they are being executed.
Yeah I tried that later and it didn’t work, I reverted back to my original image, but just replaced the branch with flip flop because it works the same way anyways.
Sorry. I don’t see anything that can explain what is happening to you.
Try creating another simple widget with a text or something and use it instead of Display2 and see what happens.
I’m seeing a bunch of things that don’t look right to me.
Your last image uses a GetAllWidgetsOfClass node which seems to get only the audio widgets for display etc as well.
On your last image you are setting the input mode to UI only, in which input actions bound to an input component don’t work. This is because widgets use their own routing system for input.
In the first image and further on, you assume that a pointer is valid where it might not be. All the wires going from non pure method outputs depend on the method having run before the output might become usable.
In addition to 3, I can’t tell you how the garbage collector deals with those “floating” output wires of which the output is nowhere stored in a variable, looks fragile.
You create a widget and remove that… and create again… and remove again…etc
that’s not how this system is made to work…
You can create multiple widget Objects, that’s okay.
but… instead of spawning, place them inside a Main Widget. Best inside a Widget-Switcher. The Switcher is a Widget type lile a bool or Button… jzst… without any visible content. It can Hold as many children as you want, but only the first one is visible by default (it has the index 0). There, you can hold your Widgets and just switch between them by setting the ActiveWidgetIndex of the Switch, by pushing the buttons in your main Widget.
Then you just need to create your Main Widget once and hold it as a reference wherever you need to call it from.
Don’t use a FlipFlop, instead, use the Widget->isVisible bool to check if the awidget is visible.
take this bool and add it in a “select” node (type “select” in the context browser and use the very last one in the list of select).
now, add a Widget->SetVisibility Node and as Input visibility, set the “select” output.
your select node now will have two fields (true and false) both with a Visibily flag.
set the true to Collapsed and the false to Visible.
this is better than a flipflop, cause it uses the actual visibility state of the Widget… no matter in what state it is.
Yes I understand, that from that perspective it might seem overengineered, but in the end it works, at least to the part, where looping it becomes the problem. I don’t need to recreate the whole widget system, I need to know how do I make it from happening once, to being able to happen multiple times.
Ok, as for the get actors of all class and removing the widgets and in that case it being only audio is because, that was made in my audio widget bp, and since I’m making a new widget by clicking on lets say for example: display. It created the display widget, but removes the audio one so that they don’t overlap. As for it being UI only, that’s totally my fault I though I set it to UI and Game everywhere but I guess I didn’t. But even after changing that, the result is the same either way. So I would appreciate a suggestion that would actually fix this issue, because I’ve tried the visibility on/off and making it hidden on begin play when adding it to viewport and then when the player presses Escape it goes to Visible and Hidden again but no luck with that. So are there any other possible solutions or will I have to create a single widget somehow for this?
I removed the blueprints from my forth picture and did the switching in the widget switcher, now I’ve retested the menu usage and it’s still the same story. Appears once and closes, but never to be seen again. Once again I’ve tried adding it to viewport from the start but setting it to hidden and once the key is pressed a flip flop where A sets it visible and B hidden again. But I doesn’t even show the widget no matter how many times I press it. It’s like it’s hidden forever. But If I set it to default from the start just for testing let’s say Not Hit-Testable, it shows it at the start ofc, closes it with my keybind and once again doesn’t reopen.
So now that I don’t have all that unnecessary code, could you guys please help me sort this out?
Best post the entire up to date code again in a compact format screenshots. I can follow that much easier. Have you tried setting breakpoints on the blueprint nodes (F9)? that way you can see exactly what nodes are hit while playing. I have a feeling that the input action (the red input node) does not execute. Can’t tell without breakpoints what else is wrong.
One of my three widgets that it switches between (now updated and only have their own functionality and no switching, everything of that kind is now in the mainpausemenu):
So yeah nothing, that could cause this issue, just for reference, compared to before.
My LevelBP, where all of this is going on, I thought about doing it in FirstPersonCharacterBP but I have some levels in which I don’t want the pause menu to open up:
You should debug the input routing then, might be able to see the call stack in blueprints, otherwise visual studio.
This input should work if:
The playercontroller’s input mode != UI.
The game is not paused or the node runs paused.
The input is not handled elsewhere (preprocessor, widget, override (consuming)).
I don’t see anything wrong with it. I use the InputAction node on my playercontroller to open up the UI and set the input mode to UI, after that all input is routed through the widget’s OnKeyDown event which closes the UI and sets the input mode back to Game or Game + UI. This works just fine. Input actions configured on a widget like on your screenshot are also copied over to the playercontroller’s input component. Wrote a bit about it here:
If you click the node you get a few checkboxes on the details panel where you can choose if it should override any other bindings, could be you have another node somewhere else on the same action / maybe key which conflicts with this.
Sorry mate, but you just got me all confused. I checked the link you sent me and lets just say I might not know much about blueprints, but about c++ I know even less. I tried some things and It’s still not working, but about the debugging part, I would appreciate more specifics because I’m lost.
Ah alright. That does make debugging very difficult, it would be wise to invest some time in learning how to debug with visual studio or to what point possible the blueprint debugger (set breakpoint, read call stacks) because we can only guess without it.
That this red input event node triggers once but after that not anymore, means that either the input binding is removed or that input is read by another system and that it stops there. To really explain that things get technical.
If you click the red input event node you get a few checkboxes on the details panel which you can configure, possibly it is not configured to run in pause mode and you run pause, or another red node overrides this one. That is the simplest / first check you should do. Secondly, due to how the input system works, if your input mode of the playercontroller is set to UI I believe those nodes don’t work. Third, widgets receive input before these red nodes. If they decide to process and “handle” the input, this red node will never be reached. They do so through methods “OnKeyDown”, OnMouseButton… etc which are overridable methods. If none of that seems to be the issue, you need to deep dive into studying debugging using Visual Studio because this is a big c++ area. If you don’t wish to do that you might figure it out by recreating the widgets step by step and see after which change the input node breaks.
