Keyboard Input Being Called Twice?

,

So following this guide on getting a basic input handler going:

https://forums.awsgametech.com/t/how-to-set-up-an-input-handler-in-c/759/1

Works great, except that key events are being called twice, even if specifying that activationMode == eAAM_OnPress or whatever. Doing some breakpoints reveals that the problem exists in Keyboard::ProcessKey. PostInputEvent is being called twice, once here

GetDXInput().PostInputEvent(event);

and once here:

GetIInput().PostInputEvent(event);

Looking at Keyboard.cpp for CRYENGINE 3.8.6, it seems that the GetDXInput call is the only one that exists, and the other GetIInput is commented out. Is there a reason that this was not commented out in Lumberyard?

Hello @cozzbp,

I’m not really sure why you are experiencing key events being called twice. Do you experience that with any of the sample games provided or is this only happening in your project?

Does commenting out the GetIInput() line fix the issue? Please provide more information regarding the basic input handler that you had set up.

Thanks!

Yes, commenting out the GetIInput() line does fix the issue, I was mostly just curious why this code was uncommented from Cryengine, if it had some meaningful purpose. I can also post my input handler code if that helps, but I’m sure that’s not the issue, as I was doing it the same way before in older Cryengine versions and I didn’t have the issue.

I talked to one of the engineers that worked on the input system and here is what he mentioned:

Yeah, pretty sure the first call is for the ‘raw’ key-press, while the
second is for the unicode character. The second (unicode) block was commented
out when we got it from Crytek, and either me or Rob enabled it again when we
were setting up keyboard support for the UI. They should be able to distinguish
between the two by checking event.state, the unicode event is of type eIS_UI.
It’s a little all over the place, so there could be something messed up with
it, but think that’s what’s going on.

Ahh, that makes sense. I’ll look into the event.state and see if that works. Thanks!