Emit a KeyInputEvent when a mouse button is pressed

[wlhlm]

This is a proof of concept that emerged after the discussion on GTNewHorizons/TinkersConstruct#205 where I fixed TC's keybindings not working on mouse buttons.

Handling keybinding in Forge for 1.7.10 seems a bit bare-bones: if a mod wants to associate an action with a keypress on the keyboard, it sets up a KeyBinding and listens for the KeyInputEvent. However, the event is sent every time any key is pressed on the keyboard, regardless of which specific key a mod is interested in. So each mod has to check all its own keybindings upon receiving the event to see if it's even relevant.

While Minecraft allows to easily configure keybindings on mouse buttons, these are not delivered by the KeyInputEvent, but by the MouseInputEvent. This is probably rooted in how lwjgl represents mouse and keyboard buttons separately. This means each mod that registers a keybinding has to explicitly check for mouse events as well to see if a mouse button has been pressed. Unsurprisingly, many mods don't implement that. See the discussion in GTNewHorizons/TinkersConstruct#205, which mentions Tinker's Construct, TravellersGearNeo, and EnderIO as examples that needed fixing. This leads to a bit of whack-a-mole trying to fix these issues (annoying with ARR mods of course...).

Moreover, the MouseInputEvent is also emitted on mouse movement, which needs additional care to avoid overhead if a mod wants to support mouse buttons explicitly, but is not interested in mouse movement.

My proposed solution modifies Minecraft's gameloop to also emit a KeyInputEvent (in addition to a MouseInputEvent) if it detects that a mouse button has been pressed. This should free us from having to make each mod individually compatible with mouse buttons. I have no idea if this is sufficiently robust. Brief testing with GTNH fully loaded hasn't given me any issues so far. I don't think doubled events (a mouse button press will now emit both a MouseInputEvent and a KeyInputEvent) will be an issue here as all the mods are already doing their own keybind checking as mentioned above anyway. Though, I can imagine this could interfere with other mods that modify input or keybind handling (it seems to work fine with GTNH, but consider hodgepodge's relevance outside of that modpack).

I'd very much appreciate feedback here.

/cc @sisyphussy

[Caedis]

Relevant
GTNewHorizons/GTNHLib#154
GTNewHorizons/GTNHLib#155
GTNewHorizons/GTNHLib#156

[wlhlm]

I did some tests with Backhand that uses some keybind handling from GTNHLib mentioned above and that works perfectly with the changes made here.

[sisyphussy]

@wlhlm Do you know what would happen if a method called Keyboard.getEventKey()?

https://github.com/GTNewHorizons/Angelica/blob/86c726e50bab40964dbe6515972995cfb6a0550e/src/main/java/com/gtnewhorizons/angelica/zoom/Zoom.java#L37

[wlhlm]

@sisyphussy

Do you know what would happen if a method called Keyboard.getEventKey()?

Sorry, just saw your comment.

Good question. It's not something I considered initially, but I tested it and in the absence of any keypress, the method returns 0, which will be handled safely.

Though good thing you brought up the Angelica code, because for the zoom key it needs some slightly different key handling and won't magically be fixed by this PR here.

[wlhlm]

Short list of mods in GTNH, that I'm aware of, that currently have trouble with keybinds on mouse buttons:

• EnderIO
• Angelica

[sisyphussy]

Do you think this is fine to test on zeta?

[mikkerlo]

Short list of mods in GTNH, that I'm aware of, that currently have trouble with keybinds on mouse buttons:

* EnderIO

* Angelica

It looks to me that this bug is present in Better Questing as well. It shows the same symptoms. I'd love to see it fixed.

[wlhlm]

@mikkerlo Can you test, if this change here fixes your problem with BetterQuesting? Swap out the hodgepodge jar locally with this build here: https://github.com/GTNewHorizons/Hodgepodge/actions/runs/18254822151/artifacts/4184780761 (extract and use the jar file without a suffix) If you're playing on a server, that's fine you only need to update the client.

[mikkerlo]

@mikkerlo Can you test, if this change here fixes your problem with BetterQuesting? Swap out the hodgepodge jar locally with this build here: https://github.com/GTNewHorizons/Hodgepodge/actions/runs/18254822151/artifacts/4184780761 (extract and use the jar file without a suffix) If you're playing on a server, that's fine you only need to update the client.

This works well, thank you!

[mikkerlo]

@mikkerlo Can you test, if this change here fixes your problem with BetterQuesting? Swap out the hodgepodge jar locally with this build here: https://github.com/GTNewHorizons/Hodgepodge/actions/runs/18254822151/artifacts/4184780761 (extract and use the jar file without a suffix) If you're playing on a server, that's fine you only need to update the client.

Actually, I just find out that Ctrl + Mouse 4 triggers Mouse 5 as well. Do you have the same Behavior?

[wlhlm]

Actually, I just find out that Ctrl + Mouse 4 triggers Mouse 5 as well. Do you have the same Behavior?

Which keybindings did you set for Mouse 4/5 (or Ctrl + Mouse 4/5) exactly?

[mikkerlo]

Actually, I just find out that Ctrl + Mouse 4 triggers Mouse 5 as well. Do you have the same Behavior?

Which keybindings did you set for Mouse 4/5 (or Ctrl + Mouse 4/5) exactly?

For Button 5, I have the "Open quests" binding from Better Questing. With just that binding on the additional mouse buttons, when I press Button 4 + Ctrl or Button 4 + Shift, the quests pop up. If I remove the binding, that behavior also goes away.
I’ll try to make a simple mod with the same button-handling logic as in EventHandler.java#L102 later this week, so we can test it better.
Also I tested it without hodgepodge at all and behavior is still the same, so your change isn't the issue.

[mitchej123]

🦗