MagicBeanDev/Hookshot

Archived

Watch

Fork 1

mouse/keyboard menu controls keybind bug #2597

Closed

opened 2026-11-12 00:56:56 +00:00 by ligmajammin · 3 comments

ligmajammin commented

2026-11-12 00:56:56 +00:00

(Migrated from github.com)

Hookshot version

v2.1.0

What kind of problem

Sound, controls or saves

What happened

Specs incase it helps: (All up to date.)

Windows 11 (IOT LTSC if it matters.)
Ryzen 7 2700x
rx 9070 xt (strange build i know.)

Note: Swap button controls option in regular game does not fix this.

Keybind Settings:

***A: Right click
B: Space
X: Shift
***Y: Left click
ZL: I (bound to mouse macro so i can target without other keys.)

Issue:

With this setup, when entering a dialogue, pressing left click does not automatically do the default "Select" option. It instead puts a cursor on your screen that is hit or miss if it chooses the option you click. The default E keybind for the "A" button works as intended. Right clicking (Right click is set to the "B" button keyboard keybind) in this case exits the conversation always correctly.

Intended behavior would be for left click in this case to work as yes "Choose selected dialogue"/"Yes"/"OK" option, as the "B" button does for the opposite.

Issue 2:

With this setup, even if you want to work around it and simply click the dialogue option with left click, left click opens some sort of prior chats menu since it is bound to the "Y" button which also does this. Meaning if you intend to skip through dialogue with left click and then select the option with left click, doing the skipping this way means you are going to open the prior chats menu. Pressing B to skip means you will default to the "No" option unless you pay attention and stop clicking exactly when the dialogue options show.

Note: I am using instant text speed.

Thank you very much :) I looked through other issues and didn't see these. Sorry if I missed them.

Sorry if i got buttons mixed up, I am used to the original. I'm sure you understand what i mean here though. If this is not a bug please feel free to correct.

Where in the game

Kokiri Forest, very start of game talking to Saria sitting on the log playing Ocarina

How often

Every time

Graphics card and driver version

RX 9070 XT, latest

CPU, RAM and operating system

Ryzen 7 2700X, 32GB, Windows 11 IOT LTSC

Changes from the defaults

No response

Other software hooked into the game

No, nothing hooked in

hookshot_log.txt

hookshot_log.1.txt
hookshot_log.txt

I think log.1 has it, i booted again to check the control scheme i did again to verify but my PC crashed when opening the driver update tool to verify driver version lol. Never happened before, likely unrelated, had pc on for a long time who knows.

Screenshots or video

No response

Before you send it

I'm on the newest release, or the problem is still there on it.
I searched the open issues for this problem.
I'm not attaching game files, keys, hookshot.exe, the .bin caches or saves.

### Hookshot version v2.1.0 ### What kind of problem Sound, controls or saves ### What happened Specs incase it helps: (All up to date.) - Windows 11 (IOT LTSC if it matters.) - Ryzen 7 2700x - rx 9070 xt (strange build i know.) Note: Swap button controls option in regular game does not fix this. Keybind Settings: ***A: Right click B: Space X: Shift ***Y: Left click ZL: I (bound to mouse macro so i can target without other keys.) Issue: With this setup, when entering a dialogue, pressing left click does not automatically do the default "Select" option. It instead puts a cursor on your screen that is hit or miss if it chooses the option you click. The default E keybind for the "A" button works as intended. Right clicking (Right click is set to the "B" button keyboard keybind) in this case exits the conversation always correctly. Intended behavior would be for left click in this case to work as yes "Choose selected dialogue"/"Yes"/"OK" option, as the "B" button does for the opposite. Issue 2: With this setup, even if you want to work around it and simply click the dialogue option with left click, left click opens some sort of prior chats menu since it is bound to the "Y" button which also does this. Meaning if you intend to skip through dialogue with left click and then select the option with left click, doing the skipping this way means you are going to open the prior chats menu. Pressing B to skip means you will default to the "No" option unless you pay attention and stop clicking exactly when the dialogue options show. Note: I am using instant text speed. Thank you very much :) I looked through other issues and didn't see these. Sorry if I missed them. Sorry if i got buttons mixed up, I am used to the original. I'm sure you understand what i mean here though. If this is not a bug please feel free to correct. ### Where in the game Kokiri Forest, very start of game talking to Saria sitting on the log playing Ocarina ### How often Every time ### Graphics card and driver version RX 9070 XT, latest ### CPU, RAM and operating system Ryzen 7 2700X, 32GB, Windows 11 IOT LTSC ### Changes from the defaults _No response_ ### Other software hooked into the game No, nothing hooked in ### hookshot_log.txt [hookshot_log.1.txt](https://github.com/user-attachments/files/34721683/hookshot_log.1.txt) [hookshot_log.txt](https://github.com/user-attachments/files/34721682/hookshot_log.txt) I think log.1 has it, i booted again to check the control scheme i did again to verify but my PC crashed when opening the driver update tool to verify driver version lol. Never happened before, likely unrelated, had pc on for a long time who knows. ### Screenshots or video _No response_ ### Before you send it - [x] I'm on the newest release, or the problem is still there on it. - [x] I searched the open issues for this problem. - [x] I'm not attaching game files, keys, hookshot.exe, the .bin caches or saves.

mooki000 commented

2026-11-12 02:51:27 +00:00

(Migrated from github.com)

I'm looking at this tonight (Linux, RTX 4090): what decides between the pointer and a mouse button that is bound to A or Y when a dialogue is open, for both of the problems you describe. By the project's scoring: S3, one report (confidence 0.4). Part of it may be a design decision for the maintainers (should an explicit binding win over the pointer for that button?); I'll say so here with what I find.

NotRexed commented

2026-11-12 03:08:25 +00:00

(Migrated from github.com)

Thanks for the report. Reports of the same kind are collected in #2504, which lists this one with your details and links back here, so one fix closes them together. Follow #2504 for the fix and add new details there (or here). If this turns out to be separate it will be reopened.

github-sync commented

2026-11-12 13:39:33 +00:00

Owner

@mooki000 commented on GitHub · 2026-11-12 12:45 UTC · original

I found why the mouse behaves differently in dialogue choices. In the Windows pointer-mode handlers, mouse-button bindings are suppressed: left-click selects a choice under the pointer, while right-click sends B regardless of its binding. While the mouse is captured, your left=Y binding still sends Y.

A game-free check of those handlers reproduces this on v2.1.0 and main 09aac439; I have not reproduced the Saria conversation in a Windows game. E for confirmation remains the workaround you already found.

@NotRexed, for the fix tracked in #2504, should explicit mouse-button bindings take priority over pointing in dialogue choices? That would preserve Y as Y, not make it confirm as A; changing the rule for every menu would also change the existing default point-and-click behavior. I have not changed that policy without a decision.

> [@mooki000](https://github.com/mooki000) commented on GitHub · 2026-11-12 12:45 UTC · [original](https://github.com/NotRexed/Hookshot/issues/2597#issuecomment-6823982156) I found why the mouse behaves differently in dialogue choices. In the Windows pointer-mode handlers, mouse-button bindings are suppressed: left-click selects a choice under the pointer, while right-click sends B regardless of its binding. While the mouse is captured, your left=Y binding still sends Y. A game-free check of those handlers reproduces this on v2.1.0 and main `09aac439`; I have not reproduced the Saria conversation in a Windows game. E for confirmation remains the workaround you already found. @NotRexed, for the fix tracked in #2504, should explicit mouse-button bindings take priority over pointing in dialogue choices? That would preserve Y as Y, not make it confirm as A; changing the rule for every menu would also change the existing default point-and-click behavior. I have not changed that policy without a decision.

Commenting is not possible because the repository is archived.