Better solution to using button14 for communicating minigame state
An issue was recently introduced which now interferes with mods using custom key binds (such as my Vore Tournament). This is in part due to a deliberate decision, but I'm not sure to what extent it's a correct one or set in stone.
Xonotic is now using button14 as a way to mark the state of mini-games. This has a few side effects, such as movement prediction breaking while this key is being pressed: The player can no longer walk and will snap back to their previous location when trying to. In my mod a button reserved by its code now freezes the player in place when pressed.
First of all, why button14? From what I remember, button12 was the first free button yet to be reserved. It seems like a good idea to move it from 14 to 12, so that buttons 13 14 15 16 can officially stay reserved for mods: Those are the last free buttons left, and I'm worried that my mod will remain without keybinds to use if they're ever taken up as well.
After talking with Mario on IRC however, I understand that a button shouldn't be used here at all: Using button14 is more of a hack for the client to tell the server about minigame state. The correct solution would be a proper function to tell the server about the client's state instead. Perhaps a better way to solve this would be implementing such a function?