memetics

"Cannot reproduce" is a bit inaacurate/dishonest, isn't it?  Did anyone else even try to reproduce it?  Would be more accurate to tag this as "Fixed" if not "did not reproduce."

In case the issue arises again, for future reference: The issue existed and was quite reproducible in versions between the 1.13 pre-releases and 1.16.5.  But with 1.17 Mojang fixed something in the code that had been broken with 1.13, which arose at the same time as a dozen other reported issues relating to a change in the game engine's input handling - reference [Mod] Pokechu22's comment in MC-135845:

For context, 1.13 updated to LWJGL 3 from LWJGL 2, which completely changed the way the game gets input (it now uses GLFW). It's possible that something with how GLFW gets input doesn't work well with SendKeys, which I'll have to experiment with.

Then the issue was subsequently fixed (for current and previous releases) with the 1.17 code.

In any case, thanks for closing the ticket.

-m

Pointing device emulation of keyboard keys still works in 1.18.1.  Ticket can still be closed as "Resolved."

-m

Possibly related, possibly not - but Elecom HUGE trackball keypress emulation is working correctly now.

Elecom HUGE programmable buttons' emulation of keyboard keys now works as expected - not just in chat but also outside of chat, for example to send number keypresses to change the active inventory slot.  (Tested in 1.16.5, 1.15.2, 1.14.4, and 1.13.2; it also now works in all of those versions, oddly enough.)

Mods: This ticket may be marked as resolved / fixed.

Still in 1.12.1

Or roll it back to the 1.13 behavior.  Seriously, it was working fine back then.

-m

Definitely still an issue.  I dug a tunnel under the lava lake (and blocked off the opening) thinking that they wouldn't be able to follow; I went over 100 blocks away and stayed there for a good ten minutes.  When I carved out a side branch back toward land, the pigmen there were still giving aggro sounds, so I didn't surface.  Went back and tunneled even further away from land.  I was there for a good hour, and then finally crept back the entire way on crouch to my original entry point.  Finally they were de-aggro'd.  But as persistent as their aggro was, I was surprised that it finally went away.  Definitely not working as intended, and definitely not the way it was in 1.13.2.

Further testing reveals the following in 1.14.1 Pre-Release 2:

Keypress emulation is failing on both Elecom DEFT trackball and HUGE trackball pointing devices (both are using Elecom Mouse Assistant 5 current version [5.12] to handle assignment of keystrokes to programmable buttons on the pointing devices).

Keypress emulation is working as expected on Logitech Cordless Trackman trackball pointing device (using Logitech SetPoint Control Center current version [6.69.126] to handle assignment of keystrokes to programmable buttons on the pointing device).

Still not working correctly in 1.14.1 Pre-Release 2.  When I open the Talk bar, pressing the programmable mouse buttons (I'm using the Elecom brand HUGE trackball) produces the expected emulated keystrokes - for mine, I have mapped the keyboard buttons 5, 6, 7, 8, and 9 to my five programmable mouse (trackball) buttons.  The keystrokes also appear when entering a title for a new world in the world creation menu.  But during game play, the programmable mouse buttons produce no effect.  The expected behavior of sending keystrokes 5 through 9 would be to change the selected slot in the active inventory bar.  The mouse button keyboard emulation is still being dropped during game play, in other words.

Thanks for working on this; I hope it will get resolved soon!

Can someone confirm whether this issue persists in the 1.14 snapshots?

Fair enough.  It's still a bug (or design flaw), still a potential ADA issue, and still needs to be fixed.  Let's stick with the bug-tracker-relevant issues.  (Sorry I got us off-track.)

I expect hardware inputs to be on a more fundamental layer than software handling of the signals hardware inputs send to the software.  But as you're suggesting, I expect that the hardware's working correctly, and Java is receiving the signals, but Minecraft is discarding them for some reason.  Either a bug or a design choice - if the former, hopefully to be fixed; if the latter, hopefully one that is reversed after considering that the negative consequences outweigh the positives.

It just surprises me that an emulated keystroke is a different signal than an ordinary keystroke; seems like it should be sent as the same signal and therefore indistinguishable.  But in any case, it's something Mojang should fix.

-m

Come to think of it, any disabling of accessible technologies is probably an ADA legal issue, whether or not you're trying to prevent cheating.  Most likely something you need to fix entirely (to stop blocking emulation functionality and restore things how they worked in 1.12.2).

Still an issue in 1.13.2.  (Please restore programmable mouse button functionality!)  (Wouldn't it be possible to disable the use of macros for programmable mouse and keyboard buttons, but to leave simple keystrokes enabled?  That would avoid issues with cheating / automation but still enable the flexibility that programmable pointing device buttons have, including for ergonomic and handicap / accessibility uses.)

After I changed my screen resolution on the second monitor to its native resolution, the scaling issue I mentioned in the last post is not happening anymore.

In any case, the primary bug here appears to be resolved - full screen now (1.13.2) stays on the monitor where it's enabled.  But the Minecraft launcher still always defaults to opening the client window on the primary monitor.  I think that's a separate issue, though.

Still happened in 1.12.2.  Tested in 1.13.2; the full screen now seems to apply to the current monitor, but the Minecraft window does not scale to the correct monitor size.  (The Minecraft screen is bigger than the monitor area, so about 1/3 is off-screen on two edges.)

I've had several horses suffocated not just during world generation but upon reloading a server where the horse is standing in a corner of a stable or next to a wall.

Same thing happens with Elecom's HUGE trackball pointing device.  The Elcom software lets you map the extended mouse buttons onto specific keyboard key presses.  This enabled for example pressing numbers on the keyboard using the mouse buttons to quickly the active item to other inventory item slots.  This still works in 1.12.2 but now fails in 1.13.1.  Please fix this; it has taken away a critical power user / player tool.

-m

Having the exact same issue with Elecom's HUGE trackball pointing device.  The additional buttons on the device are mapped to specific keyboard keys (for me, keys 5, 6, 7, 8, 9 to enable quick inventory slot switching).  But these now fail to work in 1.13.1.  If I relaunch into 1.12,2, they still work.

Please fix this button mapping issue a.s.a.p.,  I'm so accustomed to playing using the extra mouse buttons for those key presses (extra speed changing to different items, and so on) that I will not be playing versions after 1.12.2 until this is fixed.  Thanks~

-Memetics