Pretty pretty please, can this be made to happen? With re-bindable keys basically being the norm, making the KeyEvent struct available to BP graphs from the InputAction event node would be an enormous help.
Just something like this:
Pretty pretty please, can this be made to happen? With re-bindable keys basically being the norm, making the KeyEvent struct available to BP graphs from the InputAction event node would be an enormous help.
Just something like this:
+1 I second that notion
Seriously, I’d kill for this right now. The elaborate end run I’m having to make around not having access to that struct (and the subsequent editor crashing) is starting to make me crazy.
Could you give a few more details on quite why you needed this? The idea of Input Actions is that the user can rebind but the gameplay logic doesn’t need to care
Sure. Let’s say I’m making a Hotbar, and I need all of the buttons that comprise it to be re-bindable to user preference, but I also want their gameplay functionality to change if they are held down before being released.
This is clearly going to require use of Tick to track the length of time the key has been down, but Tick can only be called once per graph. Without access to the KeyEvent struct, a reusable function employing GetInputKeyTimeDown is out, so I’ve got to hard-wire what key to look at into the logic the hotkey executes. Hard-wiring where to look directly contradicts the point of the re-bindable InputAction.
So in a manner of speaking, this is just giving gameplay logic the option to care with a quick look in the rear-view mirror for the key, and then full steam ahead.
Except the user CAN’T rebind them (at least the end user can’t, only the person using the engine itself) so anyone trying to write a rebindable key system for their game itself needs access to this data. Agnostic input events only work if the sources that feed them can also be controlled or modified.
That’s a much better way to put it. Thanks, RhythmScript! Rama’s Rebindable Keys plugin goes a long way, but doesn’t address this core problem.
Because Rama’s system (and BTW, love Rama and all, but it’s sheer lunacy that anyone should have to rely on a third-party plugin to do something as fundamental as key binding for a major engine. That’s just ridiculous) works by writing to the settings .ini. It can’t change what an InputAction is executing mid-execution.
Though FWIW for your specific situation I’m not sure what Rama provides isn’t good enough… It’s possible to measure the length of time an InputAction has been held down by using a Timer or Timeline node connected to it (press starts the timeline, release ends it, and it outputs a float value which is 1:1 with its total time, so you can see on release what the last value of “total hold time” was). This isn’t as elegant as “Get Key Time Down”, but as long as we’re requesting functionality why not just request a GetInputActionTimeDown output on InputActions? Seems like the most elegant alternative.
I still don’t think it’d be a bad idea to be able to see what input the InputAction is assigned to, though; for example, rebindable key systems want to be able to display that key. QTEs or on-screen instructions, for instance, probably want to know which hard-coded key to “suggest” for a prompt, rather than “press Attack!”
+1 for this!
Thank you for the compliment by proxy! Always nice to hear that more learned minds think your instinctual logic is elegant.
I hadn’t considered a timeline yet. That might be an effective stop-gap. Thanks for the tip!
Having tried them, Timelines do mitigate several problems, but having this struct exposed (optionally or otherwise) is still something I think a lot of people would like to see.
Hopefully EPIC adds rebindable key feature in the next few weeks.
The gets may return an array or a single value?
Setting the inputaction to a new key just changes the value appropriately in the defaultinput.ini ?
Nothing fancy.
Did they add this?
Sure did. <3 Epic.
Can you tell me what to google or any information on where I can find how to do it?
The key struct is exposed right on the event now.
So if the JUMP key is space bar, I can just set the key struct on input jump to a struct that contains the new hotkey?
I’ve been messing around with the KEY struct. I finally got it to set to a new key, but when I press the new key nothing happens.