Avoiding spurious inputs when closing Pause Menu

Unity Engine
, , , ,
1

I’m using Unity’s tradition Input (not the new Input System), and I have a Pause Menu which mostly works correctly (timeScale to 0, I can navigate with keyboard or gamepad, etc).

The one thing I’m trying to debug is… if I close the Pause menu by pressing the gamepad (A) button while my “Resume Game” button is selected, then the press of the (A) button is ALSO picked up by the game itself in the instant that the game becomes unpaused, and therefore a player action can be spuriously initiated.

I need to keep the game world from receiving the input event that “caused the unpause”, either if there’s some way to “eat” that input so that it won’t be transmitted to other game objects / components. Or by otherwise somehow cleanly detecting that the game has just become unpaused.

I tried unchecking “Send Navigation Events” in my EventSystem object, but then the gamepad won’t navigate the buttons and I can only click the mouse.

I have thought of some kind of “game was only unpaused in the last 2 frames” check to ignore all input. That sounds a little goofy/unclean so I’m hoping maybe someone else has a better/cleaner solution.

2

The initial and maybe a little unsatisfying answer is “Just use the new input system”. It handles such complexities much better.

That being said, you could probably make it so that on the unpause input you immediately close the menu, but only actually unpause the game (reactivate scripts, restart time, etc) in the next frame. You can achieve this delay via a coroutine or async method. I would probably use something like this even if I was using the new input system.

Does that make sense to you?

2 Likes
3

Oh yeah that’s a nice idea for “Unpause, but only next frame”. The best I’d been able to think of was a “justUnpaused” flag to tell the main controller to ignore input for one frame, which is the same general idea only I think less elegant.

(I would of course eventually switch to the new input system, but I’m presently prototyping from some older building blocks to move quickly. If the prototyping arrives at something “good” then refactoring of accumulated debt would inevitably follow haha)