Add UE method for handling key binds

[UE4SS]

Description

Note: This is a very early draft! It will change a lot, and might not be merged in the end, we'll see how it goes.

This PR adds UEs own input handling as a method we can use for our own key binds.
The system uses two reflected functions: APlayerController::IsInputKeyDown and APlayerController::WasInputKeyJustPressed.

The reasons why it doesn't replace our own system entirely: I don't know if every game has the necessary functions.
If the new system is battle tested and works in all games, we can drop our own system.
Otherwise, we'll need to keep our own system still as a fallback.

Reasons for replacing our current system:

1. Cross-platform support with no effort, and very low maintenance burden.
2. Culling of most of the Input dependency, which is an old homegrown solution that I wouldn't recommend to anyone.

Initial goals:

1. Implement the new system side-by-side with the old system.
2. Don't break existing code, the new system should route through our existing register_keydown_event functions, and there may need to be some small wrappers in the Input namespace.

Performance impact has not been tested.

Type of change

• New feature (non-breaking change which adds functionality)

Checklist

• I have added the necessary description of this PR to the changelog, and I have followed the same format as other entries.

[UE4SS]

Note that this currently uses UGameViewportClient::Tick.

[github-actions]

Build Details

Name	Information
PR Commit	07d0a00
Merge Commit	4976ac7
Size	47.16 MB
Last Updated	Feb 9, 25, 11:04:10 PM UTC
Expires At	Feb 23, 25, 11:04:05 PM UTC

---

Build Details

Name	Information
PR Commit	07d0a00
Merge Commit	4976ac7
Size	28.5 MB
Last Updated	Feb 9, 25, 11:08:55 PM UTC
Expires At	Feb 23, 25, 11:08:52 PM UTC

[igromanru]

1. If I see it right RegisterGameViewportClientTickHook for Lua is not a thing.
   I find it a bit weird that you went for input functions directly, instead of exposing RegisterGameViewportClientTick first, which would be more helpful for mod authors and would allow people to use these input functions themselves if they want.
2. APlayerController input functions are not very reliable, they can't replace the old system. They never work in main menus and depending on games implementation they often not even work as spectator or some other cases when you're not controlling a Pawn.
   I always used these function for my internal hacks to control my UCanvas self-made GUI or toggle features per hotkey and I always had issues with them.
   Also it doesn't work on Servers. Currently hotkeys are still helpful to test stuff in game Servers, because they work as long the console is focused, it's not ideal but enough for testing. Game servers have no player controllers until a player joins and no GameViewportClient either.
3. I really don't like that you are going away from server support with latest features. While GameViewportClient::Tick might be a temporary solution for live view etc. this is now a second thing that won't work on a Server,
   It would be nice if you could find a replacement for GameViewportClient::Tick hook first that would work reliably on servers as well and then add Lua functions to be able to register callbacks for it.

[UE4SS]

1. If I see it right RegisterGameViewportClientTickHook for Lua is not a thing.
   I find it a bit weird that you went for input functions directly, instead of exposing RegisterGameViewportClientTick first, which would be more helpful for mod authors and would allow people to use these input functions themselves if they want.

I wanted to focus specifically on our own key binds, and Lua support will come automatically with the regular functions.
The exposure of the hook function isn't within the scope of what this PR is trying to do.

2. APlayerController input functions are not very reliable, they can't replace the old system. They never work in main menus and depending on games implementation they often not even work as spectator or some other cases when you're not controlling a Pawn.
   I always used these function for my internal hacks to control my UCanvas self-made GUI or toggle features per hotkey and I always had issues with them.
   Also it doesn't work on Servers. Currently hotkeys are still helpful to test stuff in game Servers, because they work as long the console is focused, it's not ideal but enough for testing. Game servers have no player controllers until a player joins and no GameViewportClient either.

Do you have any alternatives to the PlayerController functions ?

3. I really don't like that you are going away from server support with latest features. While GameViewportClient::Tick might be a temporary solution for live view etc. this is now a second thing that won't work on a Server,
   It would be nice if you could find a replacement for GameViewportClient::Tick hook first that would work reliably on servers as well and then add Lua functions to be able to register callbacks for it.

The goal is to make it work on servers, and I even have a comment in the code about this, but it may take some time.
There's a reason why I'm implementing these things as opt-in... and I think it's a bad idea to ban "experimental" code like this. It's better to include them and allow people to opt-in to use them if it works for their game, and improvements can be made later.

To be clear: Making this new system the default is completely unacceptable without support for servers.
Meanwhile, I don't think there's a good reason to not include it behind an ini option.

[narknon]

Yeah, we literally have a section in the ini for experimental features.. which the function caller should probably be moved out of and the GUI rendering thread moved into tbh.

[igromanru]

1. If I see it right RegisterGameViewportClientTickHook for Lua is not a thing.
   I find it a bit weird that you went for input functions directly, instead of exposing RegisterGameViewportClientTick first, which would be more helpful for mod authors and would allow people to use these input functions themselves if they want.

I wanted to focus specifically on our own key binds, and Lua support will come automatically with the regular functions. The exposure of the hook function isn't within the scope of what this PR is trying to do.

I'm giving general feedback based on my experience, which is in scope of the RP, because in my opinion the PR changes are useless, if you can't rely on these functions at all time. They are not suited to be used as global hotkeys.
Obviously you can experiment with what you want, but I hoped that if you're already working in this sphere, that you would rather find a better Tick function, which would be really nice to have. Especially when this RP changes basically depend on it.

2. APlayerController input functions are not very reliable, they can't replace the old system. They never work in main menus and depending on games implementation they often not even work as spectator or some other cases when you're not controlling a Pawn.
   I always used these function for my internal hacks to control my UCanvas self-made GUI or toggle features per hotkey and I always had issues with them.
   Also it doesn't work on Servers. Currently hotkeys are still helpful to test stuff in game Servers, because they work as long the console is focused, it's not ideal but enough for testing. Game servers have no player controllers until a player joins and no GameViewportClient either.

Do you have any alternatives to the PlayerController functions ?

Since I didn't want to deal with unreflected functions and properties, I didn't find any.
You have to find out how UE deals with input when it decided if it should be directed to PlayerController or Widgets.
To be more precise, there is an Input Mode which decides where the Input goes. This is why user's input doesn't even reach PlayerController to be able to use it's input functions at all time.
This is all I know.

[narknon]

Eventually I would like to directly read UE's array of inputs from the frame