[Code Discussion] Universal method to query key bindings by Tool ID / Storing sh

[Yona-TYT]

Hi everyone,If I remember correctly, some time ago @ceeac mentioned an interest in implementing an interface to customize keyboard shortcuts (or at least, that is what I understand, please correct me if I am wrong).

Looking at the refactoring history in the template directories (src/tpl/), it is clear that very clean foundations were laid with components like vector_tpl. However, the live GUI for key remapping was never completed.

Currently, I am working with the script API (Squirrel) and trying to find an effective way to retrieve key binding values loaded from the pakset configurations (menuconf.tab).

From a logical perspective, when Simutrans boots up, its startup routines load the pakset tools, and that should be the exact moment where our list of keys gets organized. Since these values are static and will not change dynamically during gameplay, grouping them at startup makes perfect sense.

However, the current engine architecture has a limitation regarding how it stores these tools by ID. In tool_t::general_tool or tool_t::simple_tool, the tools are indexed directly by their local ID. When a complex tool defines multiple shortcuts with different parameters in menuconf.tab (such as the underground tool (0x200F) using U, +, and - for its baseline activation and level increment/decrement variations), each new line overwrites the previous pointer in that specific slot.




While the actual shortcuts remain alive inside the global key map (tool_t::char_to_tool), the index maps only remember the very last instance processed. This makes it impossible for scripts or a future GUI to cleanly fetch all the valid key bindings for any given tool_id.To solve this globally, we need a universal function that can query the global key map for any tool ID and return a list of all its registered keys and parameters.

Obviously, please keep in mind that I am not an expert programmer, and it is quite difficult for me to implement all of this on my own. However, I would really love to know what you think about this approach, and if @ceeac made any further progress regarding the live keyboard remapping feature.

Looking forward to your thoughts and guidance on this!.

Best regards.

[prissi]

The keybindings are separated from the tool as multiple keys use the same tool. Hence, one could rather iterate over key bindings instead of tools. Also, tools change their function with different strings.

F1 retrieves the key bindings perfectly well. I think, it is not needed for the tutorial to get the key bindings. That is advanced stuff. A comment like see keybindings with F1 would be enough.

However, returning a list of keybindings with the tool ID and their default parameter is not too difficult to add, I guess. The the squirrel code has to search trough the tool ids.

Also, some keys are difficult to remap, since some keys (the ones without an ASCII code) produce other events than normal keys. Like TAB or ESC or the cursor keys on the numpad. This was the reason why ceeac did not go further, as it was not working as well as envisioned.

[Yona-TYT]

F1 retrieves the key bindings perfectly well. I think, it is not needed for the tutorial to get the key bindings. That is advanced stuff. A comment like see keybindings with F1 would be enough.

I think it's a good idea to mention this, but it's also very useful to show each keyboard shortcut individually for the tool/function being used; so far this has helped a lot those who played the tutorial.

However, returning a list of keybindings with the tool ID and their default parameter is not too difficult to add, I guess. The the squirrel code has to search trough the tool ids.

I'd like to modify get_tool_key to get the list of keyboard shortcuts, so I'd also change the name to get_tool_key_list.

Also, some keys are difficult to remap, since some keys (the ones without an ASCII code) produce other events than normal keys. Like TAB or ESC or the cursor keys on the numpad. This was the reason why ceeac did not go further, as it was not working as well as envisioned.

Thanks for clarifying that; now I see that keyboard remapping is much more complicated than it seems.