As easy as it is. I’m currently remaping old inputs to enhanced and stumbled across “Any key” input. Previously it was used to detect forced “AFK” from player (and it is important). In enhanced inputs keyboard bind on “any key” just don’t call. Am I missing smth?
Hey there @Mebebonk! It does seem like the Any Key function is broken for the enhanced input system in 5.1. A report has been filed!
I already reported this issue back in May 2022 and I can’t believe it still hasn’t been resolved by end Feb 2023. It seems like such an obvious bug (Any Key binding simply doesn’t trigger). To top it off, I never received any follow-up about my report, and it seems like the moderators never approved my report to the tracker, so I couldn’t check on the status. So they just… ignored it? I have a case number and everything, so it’s not like I forgot to hit submit.
Just throwing this out because someone else has now reported the issue according to above, and I just hope that their report is actually looked at by someone at Epic this time. I hope someone actually resolves this bug soon. I can’t imagine many devs can publish a game without Any Key.
I have the same problem and I can’t continue to improve my game
Hey there @s54780478 and @crackedeggs1! Apologies! In the meantime, it does seem like the raw any key event is still working as of 5.1, but for some reason the enhanced input version is not.
Would the event version work in this case?
Yes, it works, Thank you very much for your attention, it is a great honor .
But if the enhanced input has been called in a certain blueprint,
For example In my case.
of the “Old Anykey”
will conflict with
"X Key of Enhanced Input " ,
only the X of the enhanced input will be called.
I think there is still a need the ANYKEY of Enhance Input.
I definitely agree and I hope the enhanced input variant works soon! Turning off the “Consume input” key on the event’s details should allow it not to cause any conflict in this case, and you can pass the key details out in post processing, which should allow it to still server the same purpose with a bit more work involved.
So, I spent half a day figuring out how to implement my input system with the Enhanced Input System and the Input mappings and so on, then half a day to realize that AnyKey is just broken for at least half a year, something that should be fixable in a day (hopefully).
With a workaround that does not work (it might “work” in blueprint, but in C++ I couldn’t find a obvious workaround yet. Furthermore, when working past the Input Mappings you’re losing the priority system and that higher priority input maps block the input for lower maps).
Ahhh that’s a bit of an oversight on my part, I didn’t recognize the ramifications of using the base input being lower priority, nor did I test the workaround outside of blueprints. I wasn’t aware the workaround itself wouldn’t work for C++, but if you’re proficient you may be able to make a quick patch in a source build. The input system is a bit deeper than it looks at face value though.
It’s been a year since the last comment, any updates on this? I’m unsure if “any key” will work with things like controllers.