ESC brings up Pause Menu, but cannot get it to 'dismiss' it.

Just like the subject says, I’m using the “ESC” or the “P” keys on the keyboard to bring up my Pause menu, but I cannot press them again to dismiss the menu. I HAVE to use the mouse and actually click either the “Resume” or “Quit” buttons.

Even though I have both the P and Esc events in my First Person Character set to “Execute when Paused”, they don’t. I only see execution flowing through the events when it’s not paused.

This is my BP for it (not that it really matters, but here it is anyway.)

Basically, I set the Resume code as a function in my widget, and am attempting to call this when the ESC (or ‘P’) are pressed while the game is already paused.

I have a similar issue. The problem is that input is blocked while paused since the game is supposed to be in a suspended state. I’ve worked around it by using the ‘Was Input Key Just Released’ operation you get from 'Get Player Controller, then I have a check for that on my tick. Sadly, using the same button means that it returns true when you pause since it’s in the same frame that you started to pause that it sees you want to unpause. I had to us B to go back and Start (I’m using a gamepad, obviously) to pause. Works, but it’s kinda crappy to have to do that. Would love to know how others make this work like most games.

My blueprints for reference…

Pause called from the Player Pawn

&stc=1

Unpause called from the UI widget that’s active. BPressed is on Tick for the UI. Like I said, it works but it’s kinda ****. :slight_smile:

&stc=1

1 Like

Just found this thread that fixes everything! Give it a shot:

TL;DR - On your input node, look in the Details panel and check the ‘Execute when Paused’ button.

Never knew that existed. Awesome!

2 Likes

Definitely a creative solution, but I’m specifically needing to reuse the ESC key (or ‘P’ key if I’m running from within the editor) for interface reasons.

REALLLY appreciate taking the time to offer a possible solution, though! What may not work for this particular problem, certainly may be useful down the road in other situations, so I’m always grateful. :slight_smile:

Checked that out. Unfortunately, I already have the “Execute when Paused” checked for both of those. But for some reason, there isn’t any execution flowing through the nodes when the game is paused. Almost like it’s a bug. It should be working according to the other post you referenced since this is effectively what I’m already doing. But for some reason it isn’t.

Have you tried using ‘IsGamePause’ node rather than your custom bool? Not sure it would make a difference, but worth a shot…

Actually, looking at your blueprint I don’t see that you’re calling ‘Set Game Paused’ and un-checking it at any point. Just setting your bool, but not actually unpausing the game. Maybe that’s in a function? Something worth looking at.

That’s handled in my “Resume Button” code. (That function gets referenced here by the “Resume Button Function” node hanging off of the ‘True’ pin in the branch.)

But the good news is that I GOT IT TO WORK!

My problem was the “Set Input Mode UI Only”. Once I removed that, everything works the way it’s supposed to now. Here’s my revised BP. (And I did away with my own bool since I noticed in yours that there was a built-in “Is Game Paused” function.

I’ll be doing a little more optimization and cleaning (Like creating a variable for the Pause Menu widget so I only have to call the Create Pause Menu Widget once), but other than that, this works just fine now.

Why is it that whenever you fix ONE thing, something ELSE breaks?

The pause system works great if I’m using the keyboard. But NOW, when I hit escape and bring up the menu, if I want to click it with the mouse, I have to click once in the window (as if to gain focus) before it’ll register that my mouse and pointer are even in there. (Mouse-overs/hovers don’t even work unless I click first in the window.) Then I have to click a second time on the actual menu item for it to actually click it.

So now I’m effectively having to click the buttons twice. Once to gain focus, and another to actually click them. Anyone got any clues as to why THAT is happening?

Okay… Apparently this is the time I need to use the “Set Input Mode Game and UI” node. It’s working now. Here’s the BP one more time:

Yeah, if you set it to UI when paused and then back to game when un-paused it should work pretty well depending on your setup. Glad you got it working.

That was kinda the problem, though. That’s the way you’d EXPECT it to work. (I know I did…), but when I had the input mode set to UI Only (Since there was no point in having it set for the game, or so I thought) it didn’t work. I had to specifically have it on the “GAME AND UI” mode for it to work. Very strange. lol :slight_smile: Oh well. At least it works. On to my other aggravating problems. lol

Maybe this will clear up why it was happening for a bit but this is the expected behaviour when you are using a widget.

The player controller is where your input, your key presses, are being routed thru and when you show the widget and set the input mode to UI only the player is no longer getting the keypresses. If you set it to game only then yes you will still capture the inputs as you expected as your player controller is still active and accepting input. Setting it to game and UI is kinda the hybrid where your player will still get the inputs like you expect but you also get the mouse control and UI interactions like you want.

One thing to watch out for is if you are using game and ui your player input may still be working if you havent blocked it off.

1 Like

There are 2 ways (maybe more):

Either you set the “UIMode” to “Game and UI” and make sure to set a bool or something in your Character that blocks his Input.

OR

You set the “UIMode” to “UIOnly” and override the “OnKeyDown” (or similar name) Function of the Widget you are using and tell it
to listen for the ESC key. Then, instead of the PlayerPawn, the Widget takes care of reenabling the GameInput.

MathewW and eXi: Thanks! I did not know that before. Will definitely be helpful in the future when planning my interfaces and how/where I want to code certain things.