Greetings and salutations!
This week's screenshot shows some changes to the key-mapping module. Since these changes are work-in-progress, and haven't yet been reflected in the main game, this screenshot comes from a simple test-program--hence the simplicity of its appearance.
The week just past was almost entirely given to work on the key-mapper, with only a few minor things being done otherwise, I believe:
As mentioned above, the main work of the week just past was on the key-mapping module. Specifically, Panda3D recently added support for devices other than keyboard and mouse (such as gamepads). However, these additional devices are not handled in entirely the same way as the the keyboard and mouse, and thus some retro-fitting was called for in the key-mapper. In addition, with the ability to use a variety of devices, I wanted to add support for selectable key-map profiles, allowing convenient selection of mappings, where available.
Overall, the retro-fit proved to be... somewhat of a headache. Figuring out quite how to work with some of the device-handling elements, especially within the previously-built framework of the key-mapper, proved quite tricky. And in addition to that general difficulty, I bumped into various problems along the way.
Still, with the aid of one of the Panda3D developers, I believe that I've made significant progress. It's not quite done yet--there's at least one bug and one or two major features yet to be dealt with, I believe--but I think that it's getting there.
One new feature that's working better than I'd expected is profile selection.
For a while I wasn't quite sure of how to handle multiple profiles: while saving and loading them seemed likely to be easy enough (and it was), I was uncertain of how to handle switching between the automatically-updated "custom" profile and any previously-saved ones. Should the "custom" profile be overwritten by any and all changes? But then would it be counter-intuitive to select the "custom" profile after selecting and changing another profile, and to find it no longer the same as one left it? And so on.
It was tempting to just take the easy route and not provide the option to save new profiles. This would leave the player with only the default profiles and a single auto-saved "custom" profile.
In the end, however, I found a simple solution that enabled both default profiles and user-saved ones: simply put, the "custom" profile isn't explicitly selectable. With the "custom"/"current" setting not available to select, it's hopefully more obvious that selecting a saved profile resets the current mapping. The "custom" profile still exists, but behind the scenes, ensuring that changes aren't lost between sessions.
There is still at least one issue with profile-saving that I want to look into, but overall it seems to work well, I think! ^_^
Aside from key-mapping work, I also removed a superfluous full-stop in a piece of text; made minor changes to some key-mapper test/example programs to get them to run in Python 3; added a convenience feature to one of my DirectGUI sub-classes; and made the very beginnings of work on a new key-mapper test-game, which I hope to use to get feedback on the key-mapper and its new features.
That then is all for this week--stay well, and thank you for reading! ^_^
