Tell the game input to "Relisten" to a key OnRelease Event

Community Community & Industry Discussion
,
1

I’m using a special plugin to have a popup window act as an interface (specialized control window that is basically a widget BP) This is a VR application and the instructor needs an interface to control the window.

How do I restore the game engine to make an OnRelease key event fire again, without pressing the original key. I have a special project that uses a secondary popup window (the developer and I have talked numerous times, he has no idea how to fix this) - and when you click this secondary window, it is effectively like alt-tabbing, so the input drops. I know this is more of a Windows limitation than Unreal. The plugin I am using DOES have OnEventFocus, so I can trigger events to fire once the input is lost (when you click the mouse in that new window, for example)

But using that event dispatcher is only half the solution - because if the VR player is holding down a key and the game loses input (by clicking that other popup window) then the game will never actually record when they physically DO release the key. (and that event won’t fire) -

So if I can make the “OnFocusWindow” event fire a “Restore ListeningForThisKey’sRelease” that would be a good workaround for this input dropping.

2

Go to the menu file and look for a function called, We extended the movie player and that was in there, if i remember right. If your is an extension of the movie player this should work.

 FilterButtonInput()

That is from UDK, bit it should be the same just moved over. That will allow you to check what key was pressed and then you can close that menu and get focus back. You will have to write the code that goes into it but in 8 or 9 lines you can accomplish this if not maybe less lines.

Here is the code we used, if it helps, adjust however you need use away.
Remember this is from UDK, So you will have to figure out how to get it to work in this engine but it worked in old engine. This is what we used to close our players menu when he was in game looking at it so he could get menu closed and focus back.

event bool FilterButtonInput(int ControllerId, name ButtonName, 
EInputEvent InputEvent)
 {
  local bool WasButtonPressed;
  local PBPlayerController PC;
  local string WhatKey, WhatKey2;
  local PBPlayerInput PBPI;

   PC = PBPlayerController(Playerowner);
   PBPI = PBPlayerInput(PC.PlayerInput);

    WasButtonPressed = false;  
   WhatKey = 
 PBPI.GetUDKBindKeyFromBindName("GBA_StartAdminMenu");
WhatKey2 = PBPI.GetUDKBindKeyFromBindName("GBA_ShowMenu");
 //`log("PBGFxTeamMenu::FilterButtonInput() WhatKey = "$WhatKey); 

 if((ButtonName == name(WhatKey) || ButtonName == name(WhatKey2)) 
    && (InputEvent == IE_Pressed))
 {
   WasButtonPressed = true;
   PC.StopAdminMenu();
  }
  //`log("PBGFxTeamMenu::FilterButtonInput() WasIPressed = 
  "$WasIPressed);
   return WasButtonPressed;
}
1 Like
3

Thanks for the quick reply -but it’s not that I need to filter what key was pressed, it’s that I need to tell the engine to LISTEN for a key RELEASE - (since the loss of input , like alt-tabbing, makes every OnRelease Event Fire

I think the plugin is an extension of Widgets actually, (it’s basically a popup widget and it has access to all Widget Functionality, with the exception of transparency since it’s its own window

4

That will close your menu when it is open, and get your game back so it can be used and played again. Seemed that is what you were asking for in above post?

Use not this > (InputEvent == IE_Pressed))

Use > ​(InputEvent == IE_Released)

5

Sorry for the late reply, I appreciate you following up:

The problem is that the Input Event - IE_Released FIRES, but then never fires again ever. So if you have an alt-tab occur, the system (windows essentially) makes the IE_Released fire. (But the user is still holding down the button)

Which means when the user actually does let go, the system doesn’t detect it.

I could construct some logic to bypass some of these but I haven’t figured out this one - how to make the system listen for a key press (or trick the system into pressing a key (but bypass the logic from that keypress event) solely for the purpose of making the system think a key IS held down and listen again

hopefully that is clearer