KeyMapper: a key-binding module, with GUI [Major update 5/2019]

MAJOR UPDATE! 9th of May 2019:

  • KeyMapper now supports Panda3D’s additional devices! (Gamepads, etc.)
  • KeyMapper no longer requires GameSaver.
    • Instead, it is expected that developers will provide their own file-handling, as they prefer. See the documentation for details.
  • Error-handling is now a little better (I feel), with an error-dialogue that’s shown when trouble is encountered while saving or loading

It’s also now on GitHub, and should be found here:

And finally, there’s a new example mini-game to go along with it–a sort of Lander-style gem-collecting game.


About KeyMapper:

KeyMapper is a module intended to provide a simple-to-use key-binding system and GUI, allowing users to re-bind the controls of an application.

Specifically, it offers:

  • Simple key-handling, including support for re-bindable “held” keys and key-events
  • Support for near-transparent handling of Panda3D’s additional devices, such as gamepads. (Including axial inputs, like thumbsticks.)
  • A GUI interface, constructed in such a way as to enable alteration and customisation of the interface via sub-classing; the default GUI uses DirectGUI.

Current issues:

  • With some devices attached, the first attempt to bind a key may automatically end up bound to the mouse-button. This seems to be an engine-level issue, and has been reported!

  • The default UI is only navigable by mouse; implementing navigation by other devices is left to the developer, should it be desired.

  • Due to Panda not producing key-release events for key-combinations (that is, keys in combination with modifiers; “alt-r”, for example), support for key-combinations is somewhat broken and restricted via a default parameter that prevents them from being bound.

  • Support for binding mouse-buttons should work properly, but does involve a slight hack behind the scenes; this is a result of an odd issue in which DirectDialogue prevents mouse-press events from being sent–but not mouse-release, key-press or key-release events. This thread was created for this issue.

I’ve made a minor change to the example game included with KeyMapper, specifically the addition of an explicit “continue” button in the shop screen. (Continuing on from the shop previously involved an invisible button laid over a backdrop element, but this may have been a little too unobvious, and fell prey to a bug that caused the window-size to be smaller than intended, pushing the door image off-screen and leaving the button rather unintitive to find.

(There should be not changes to KeyMapper itself in this version, so the version number is unchanged.)

The new version should be available via the link in the first post.

MAJOR UPDATE! Check the first post for more, but KeyMapper now supports Panda3D’s additional devices (gamepad, etc.), is available on GitHub, and comes with a new example-game.

Minor update: I’ve added a script with dummy save- and load- callbacks, and updated the tester- and example-game- programs to use them. This should mean that those programs no longer show error dialogues every time that a key is bound, while still giving warning that saving and loading haven’t been implemented.

A moderate update, including some significant bug-fixes, I believe:

  • Optional key-group IDs, allowing for sets of keys that don’t conflict
    • Note that as the “group IDs” take the form of bitmasks, keys can belong to multiple groups
  • The addition of an optional callback that can be sent when a key or axis is detected to have been pressed/released
  • Previously, button-events could be left in effect when loading a key-mapping; this should, hopefully, be fixed.
  • The error dialogue should no longer show up if the reason for an IO error is simply that the binding-file to be loaded doesn’t exist
  • A handful of minor bug-fixes

As before, the new version should be available on GitHub, and accessible via the link in the first post!

1 Like

A minor update, including the following fixes and changes, I believe:

  • Improved (I hope!) handling of event-callbacks from axial inputs.
  • Improved handling of “None” axes; in short, KeyMapper now ignores them.
  • Replaced “DirectOptionMenuAware” with “DirectOptionMenu”
    • The former is one of my own classes, and was likely included here by mistake.