mIRC Home    About    Download    Register    News    Help

Print Thread
$mouse.key bug and missing documentation #270594 31/07/22 02:38 PM
Joined: Feb 2003
Posts: 2,803
Raccoon Offline OP
Hoopy frood
OP Offline
Hoopy frood
Joined: Feb 2003
Posts: 2,803
I have been using "if ($mouse.key) break" in my scripts for many years as a cheap abort triggered by holding any of Ctrl/Alt/Shift/Mouse buttons. Since v7.69 extends this variable to expose other key states including Caps/Num/Scrollock as well as Middle click and Right Ctrl/Alt/Shift, I have had to go through and alter these scripts. No big deal.

However, there is no updated documentation explaining the new values offered by $mouse.key, so I have been decoding it myself with a simple timer. Please correct any mistakes or missing keys in the table below. I believe I have discovered a bug, also explained below.

/timer 0 1 if ($mouse.key) echo -a $mouse.key

Code
1 Left mouse button
2 Ctrl key
4 Shift key
8 Alt key
16 Right mouse button
32 Middle mouse button
68 Right Shift key (64+4)
130 Right Ctrl key (128+2)
264 Right Alt key (256+8)
512 CapsLock
1024 ScrlLock
2048 NumLock
???? Menu key


bug: The Right Ctrl/Alt/Shift keys express their own values (128, 256, 64) respectively, but they also present the left-handed key values as well (2, 8, 4 respectively). This prohibits scripts (such as game scripts) from detecting if the right-handed key is being held down while the left-handed key is currently released. Imagine a pinball game where the left-shift is the left paddle, and right-shift is the right paddle. Pressing the right-shift would necessarily have to raise both paddles since there is no way to determine that the left handed shift is not pressed.

bug: The versions.txt says that support for Menu Key was added, but I cannot get a value while pressing and holding my Menu key.


Well. At least I won lunch.
Good philosophy, see good in bad, I like!
Re: $mouse.key bug and missing documentation [Re: Raccoon] #270597 31/07/22 07:12 PM
Joined: Jul 2006
Posts: 3,930
W
Wims Offline
Hoopy frood
Offline
Hoopy frood
W
Joined: Jul 2006
Posts: 3,930
Confirmed, right ctrl/shift/alt key should trigger without their left counter part if not being held down. aka 64 128 and 256 respectively


#mircscripting @ irc.swiftirc.net == the best mIRC help channel
Re: $mouse.key bug and missing documentation [Re: Wims] #270599 31/07/22 08:55 PM
Joined: Feb 2003
Posts: 2,803
Raccoon Offline OP
Hoopy frood
OP Offline
Hoopy frood
Joined: Feb 2003
Posts: 2,803
(deleted dumb idea)

Last edited by Raccoon; 01/08/22 02:11 AM.

Well. At least I won lunch.
Good philosophy, see good in bad, I like!
Re: $mouse.key bug and missing documentation [Re: Raccoon] #270601 01/08/22 02:40 AM
Joined: Jan 2004
Posts: 1,805
maroon Offline
Hoopy frood
Offline
Hoopy frood
Joined: Jan 2004
Posts: 1,805
The problem isn't that it's a bug, is that it's not fully implemented for all keys. Fixing your table:

Code
1 Left mouse button
2 Either Ctrl key
4 Either Shift key
8 Either Alt key
16 Right mouse button
32 Middle mouse button
64 Right Shift key
128 Right Ctrl key
256 Right Alt key
512 CapsLock
1024 ScrlLock
2048 NumLock
???? Menu key


The 2 4 8 bitmasks have historically been "either-key", so 64 128 256 are simply layers on top to identify if the one on the right side has been pressed. Backwards compatibility would be broken if the 2 4 8 changes to be 'just the left one'.

The solution would be a 'feature request' to add bit masks for left-shift left-ctrl left-alt, because there's now to way to determine the difference between

left-only pressed
right-only pressed
both left+right pressed