King of Fighters 98UMFE Controller Issues

[Flotilla]

First off: I play on keyboard. I know that's odd to some, but I've been doing it for the longest time and it's how I play.

That being said, it is incredibly annoying to play on keyboard with KOF98UMFE: For one, Keyboard 2 has controls bound by default that PREVENT you from binding controls to Keyboard 1 (the only keyboard I care about). This means I had to go out of my way to rebind all of Keyboard 2's actions to buttons I wasn't planning on pressing before I could even start to bind Keyboard 1. Secondly, for whatever reason the menus have their own set of confirm buttons which override my controls. If I have "Up" set to space, then I can't navigate the menus with my control scheme because Up is ALSO set to "confirm" in menu navigation. This can't be changed, which means I have to constantly change my hand position between arrow keys/enter and QWESpace whenever I go back into a menu.

If there were an option to completely disable Player 2's inputs being on the same keyboard as Player 1's (because this is more annoying than anything else for keyboard players), and if the menus were only navigable with the bound controls instead of arbitrary buttons like Space, then my problems with this game would be solved.

Thanks for listening!

[CodeMystics]

First off: I play on keyboard. I know that's odd to some, but I've been doing it for the longest time and it's how I play.

That being said, it is incredibly annoying to play on keyboard with KOF98UMFE: For one, Keyboard 2 has controls bound by default that PREVENT you from binding controls to Keyboard 1 (the only keyboard I care about). This means I had to go out of my way to rebind all of Keyboard 2's actions to buttons I wasn't planning on pressing before I could even start to bind Keyboard 1. Secondly, for whatever reason the menus have their own set of confirm buttons which override my controls. If I have "Up" set to space, then I can't navigate the menus with my control scheme because Up is ALSO set to "confirm" in menu navigation. This can't be changed, which means I have to constantly change my hand position between arrow keys/enter and QWESpace whenever I go back into a menu.

If there were an option to completely disable Player 2's inputs being on the same keyboard as Player 1's (because this is more annoying than anything else for keyboard players), and if the menus were only navigable with the bound controls instead of arbitrary buttons like Space, then my problems with this game would be solved.

Thanks for listening!

This is very good feedback, thanks. We will look into allowing the user to reassign keys directly between players in the next update. (It won't be necessary to disable Player 2's keys, so long as they can be assigned to Player 1 without having to clear them from Player 2.)

On the arrows, the problem with allowing the menu to be navigated with the arrows regardless of what keys are bound to up/down/left/right is it's possible to bind the arrows to actions like LK or SK, which the menu also needs. If the up arrow were assigned to SK, you'd either lose SK or SK would be pressed every time you moved the highlight up. For that reason, the menus accept mouse clicks as a way to be able to navigate even when your direction keys are not the usual ones.

[TAI-X]

I'm also finding it incredibly difficult to consistently execute half-circle and "sway" (i.e. QCB to HCF) motions in UMFE. You need to roll the motion at a perfectly consistent speed without going too fast, which is not consistent with the arcade, PS2 or XBLA versions. I believe there is a problem with the input detection. (This issue is not present in the Neo-Geo version included here.)

Why is LK the confirm button? Shouldn't it be LP?

Why is the default button layout inconsistent with the standard LP -> LK -> HP -> HK arcade layout?

Why isn't there a "disable" command in the control menu to turn off unwanted macros?

There's some serious issues in this port. I understand that you were constrained in what you could do about the netcode due to the limitations of the source code you were provided by SNKP, but the interface and button mapping need to be heavily touched up.

[CodeMystics]

I'm also finding it incredibly difficult to consistently execute half-circle and "sway" (i.e. QCB to HCF) motions in UMFE. You need to roll the motion at a perfectly consistent speed without going too fast, which is not consistent with the arcade, PS2 or XBLA versions. I believe there is a problem with the input detection. (This issue is not present in the Neo-Geo version included here.)

Why is LK the confirm button? Shouldn't it be LP?

Why is the default button layout inconsistent with the standard LP -> LK -> HP -> HK arcade layout?

Why isn't there a "disable" command in the control menu to turn off unwanted macros?

There's some serious issues in this port. I understand that you were constrained in what you could do about the netcode due to the limitations of the source code you were provided by SNKP, but the interface and button mapping need to be heavily touched up.

There were many changes to the control layout during development, and much back and forth with SNK. Ultimately, we defer to their judgement on default control layout, but certainly we can pass along any fan feedback.

Sorry about not having a "disable" option for controls. We've seen this request a few times, so it's definitely on the wish list for the update.

It is interesting that you are seeing a problem with half-circle motions, particularly in UM mode but not NeoGeo mode, since that code is shared between the two and was brought over from the XBLA directly without any changes. We will investigate.

[hellish]

I second the keyboard issues reported here. In fact I believe these issues are present for every keyboard player. I suspect Code Mystics didn't test gameplay using keyboard.
I can get around the annoying key binding issue somehow, but the input issue really is a deal breaker. It's extremely difficult to perform any half circle moves in UMFE, but much easier in original NEOGEO mode.

[CodeMystics]

I second the keyboard issues reported here. In fact I believe these issues are present for every keyboard player. I suspect Code Mystics didn't test gameplay using keyboard.
I can get around the annoying key binding issue somehow, but the input issue really is a deal breaker. It's extremely difficult to perform any half circle moves in UMFE, but much easier in original NEOGEO mode.

Not that it changes the fact that it needs to be fixed, but for the record a great deal of testing was performed by an external dedicated team.

[Flotilla]

I second the keyboard issues reported here. In fact I believe these issues are present for every keyboard player.

Not true at all. I'm a dedicated keyboard player and these supposed issues with half circle motions have been completely absent on my end. I don't doubt that there's a problem if so many people are having trouble, but I'm curious what could make it an issue for you guys and not for me.

[hellish]

I second the keyboard issues reported here. In fact I believe these issues are present for every keyboard player. I suspect Code Mystics didn't test gameplay using keyboard.
I can get around the annoying key binding issue somehow, but the input issue really is a deal breaker. It's extremely difficult to perform any half circle moves in UMFE, but much easier in original NEOGEO mode.

Not that it changes the fact that it needs to be fixed, but for the record a great deal of testing was performed by an external dedicated team.

And I see you're wondering why half circle won't work in UMFE mode:
"It's a little surprising because it is the same code for both modes, and was brought over directly from XBLA without modification."
I know developer knows much more than me, but here's my two cents:
#1 UMFE mode interprets input in a stricter manner than NEOGEO mode does, so the same keyboard input sequence works in NEOGEO but not in UMFE.
#2 XBLA version is designed for controller, not keyboard.

[CodeMystics]

#2 XBLA version is designed for controller, not keyboard.

It's something we will check, but some reports suggest the same issue exists when played with a controller, not keyboard.