Twisted Code
- macks2008
- macks2008
- America/New_York
- Yes
- No
MC-160715
Important
MCPE-57264
WEB-4515
Put the summary of the bug you're having here
What I expected to happen was...:
The mouse cursor would stay in place when it is over the on-screen keyboard, regardless of whether I'm in a menu or not. It used to work like this prior to 1.13, but according to sources including a prominent mod developer and your own support, this likely changed because of the update to LWJGL3What actually happened was...:
Instead of the above, the mouse cursor resets before I can click any keys on the on-screen keyboard, making it completely useless and preventing me from being able to play due to my spinal cord injury.Steps to Reproduce:
1. Load up any version of Minecraft post-1.13 release
2. open the On-Screen Keyboard that is built into Windows' "Ease of Access center"
3. Place the on-screen keyboard over Minecraft such that the Windows overlap
4. load up a world and try to click thearrowkeys on the on-screen keyboard to move around (you won't be able to)Put the summary of the bug you're having here
What I expected to happen was...:
The mouse cursor would stay in place when it is over the on-screen keyboard, regardless of whether I'm in a menu or not. It used to work like this prior to 1.13, but according to sources including a prominent mod developer and your own support, this likely changed because of the update to LWJGL3What actually happened was...:
Instead of the above, the mouse cursor resets before I can click any keys on the on-screen keyboard, making it completely useless and preventing me from being able to play due to my spinal cord injury.Steps to Reproduce:
1. Load up any version of Minecraft post-1.13 release
2. open the On-Screen Keyboard that is built into Windows' "Ease of Access center"
3. Place the on-screen keyboard over Minecraft such that the Windows overlap
4. load up a world and try to click the WASD keys on the on-screen keyboard to move around (you won't be able to)
Windows 10. I think Java 8? I'm not absolutely certain on the Java version but I will update this later when I have time to check. I'm trying to finish this report as fast as possible because I have to leave suddenly.
Windows 10. Java Version 8 Update 171
Put the summary of the bug you're having here
What I expected to happen was...:
The mouse cursor would stay in place when it is over the on-screen keyboard, regardless of whether I'm in a menu or not. It used to work like this prior to 1.13, but according to sources including a prominent mod developer and your own support, this likely changed because of the update to LWJGL3What actually happened was...:
Instead of the above, the mouse cursor resets before I can click any keys on the on-screen keyboard, making it completely useless and preventing me from being able to play due to my spinal cord injury.Steps to Reproduce:
1. Load up any version of Minecraft post-1.13 release
2. open the On-Screen Keyboard that is built into Windows' "Ease of Access center"
3. Place the on-screen keyboard over Minecraft such that the Windows overlap
4. load up a world and try to click the WASD keys on the on-screen keyboard to move around (you won't be able to)Ever since Minecraft version 1.13, I've been completely unable to play because of a change in how the game interacts with the cursor. Specifically, whereas I'm used to being able to have the cursor over Windows' On-Screen Keyboard and click keys that way (something I have to do in order to compensate for a disability), that no longer seems to be possible as it once was, because the cursor gets centered regardless of its location on the screen. I've been told by various sources, including a prominent mod developer as well as one of your own support representatives, that this is likely due to the update to LWJGL3 that, among other things, defined some undefined behavior, but I still consider it a bug because it essentially "fixed" something that wasn't "broken", per se, in the process making the game unplayable for me.
What I expected to happen was...:
The mouse cursor would stay in place when it is over the on-screen keyboard, regardless of whether I'm in a menu or not. It used to work like this prior to 1.13, but according to sources including a prominent mod developer and your own support, this likely changed because of the update to LWJGL3What actually happened was...:
Instead of the above, the mouse cursor resets before I can click any keys on the on-screen keyboard, making it completely useless and preventing me from being able to play due to my spinal cord injury.Steps to Reproduce:
1. Load up any version of Minecraft post-1.13 release
2. open the On-Screen Keyboard that is built into Windows' "Ease of Access center"
3. Place the on-screen keyboard over Minecraft such that the Windows overlap
4. load up a world and try to click the WASD keys on the on-screen keyboard to move around (you won't be able to)
Ever since Minecraft version 1.13, I've been completely unable to play because of a change in how the game interacts with the cursor. Specifically, whereas I'm used to being able to have the cursor over Windows' On-Screen Keyboard and click keys that way (something I have to do in order to compensate for a disability), that no longer seems to be possible as it once was, because the cursor gets centered (in the process of "aiming" where Steve is supposed to look) regardless of its location on the screen. I've been told by various sources, including a prominent mod developer as well as one of your own support representatives, that this is likely due to the update to LWJGL3 that, among other things, defined some undefined behavior, but I still consider it a bug because it essentially "fixed" something that wasn't "broken", per se, in the process making the game unplayable for me.
Worth noting, this is a high enough priority issue to me that, were I a bit more competent with Java (and for that matter, programming in general... I'm a bit of a novice), I would attempt to write a coremod to override whatever part of LWJGL is causing this. As is, however, I'd probably end up making things worse and just crashing the game repeatedly. It's really a pity, considering a lot of the new content (bees, raids, etc.) looks really cool... please help
What I expected to happen was...:
The mouse cursor would stay in place when it is over the on-screen keyboard, regardless of whether I'm in a menu or not. It used to work like this prior to 1.13, but according to sources including a prominent mod developer and your own support, this likely changed because of the update to LWJGL3What actually happened was...:
Instead of the above, the mouse cursor resets before I can click any keys on the on-screen keyboard, making it completely useless and preventing me from being able to play due to my spinal cord injury.Steps to Reproduce:
1. Load up any version of Minecraft post-1.13 release
2. open the On-Screen Keyboard that is built into Windows' "Ease of Access center"
3. Place the on-screen keyboard over Minecraft such that the Windows overlap
4. load up a world and try to click the WASD keys on the on-screen keyboard to move around (you won't be able to)
Following up on a bug report I made on JE's tracker, JE issue #160175, I felt it was important to make you aware that, due to a lack of compatibility with the Windows On-Screen Keyboard, I'm unable to play Bedrock Edition, just as with the other issue I reported. Here's what I know so far:
first off, cards on the table, I don't know if there ever actually was compatibility between the OSK and BE; I just know that, much like when I tried to play Java edition 1.14 for the first time, I wasn't able to, and the symptoms are the same here. Specifically, if I place the on-screen keyboard over the app's window like I'm used to doing in Java Edition, bedrock ignores it and doesn't let me click anything on the keyboard, instead resetting the cursor's position regardless of where it is. I realize it may be a lot to ask for this "bug" (which only really qualifies as such because it's a game breaking discrepancy between editions) to be "fixed", especially given that what was actually going on in the case of Java was technically Undefined Behavior with LWJGL (which isn't even present in the case of bedrock), but nonetheless it's kind of a serious thing to not be able to play at all, you know?
Please let me know what other information you need from me, and if there's anything else I can do to help move this along.(screenshot description: a picture of what my screen usually looks like when I play on Java Edition. Note the on-screen keyboard and the little blurb from Dragon NaturallySpeaking telling me what the last recognized voice command was. Normally, to move around or otherwise use keyboard controls, I would just click the virtual key I want, but that requires the cursor staying in one place over the on-screen keyboard)
Concerning DLL injection: I am aware. I think you missed my point again. But even if you had gotten it, the point was kind of off-topic anyway. Perhaps we should strike these last three comments as well (this one, my previous one, and your reply to it), since we don't seem to be adding anything meaningful to the ticket.
(replying to AM's seemingly-now-deleted comment about this only been possible with DLL injection... which roughly translates to "the developers have to do it")
...which is why I'm reporting it as a bug rather than asking "how do I do this" because I feel it's the game's developers' responsibilities to make it accessible (within reason). JE is accessible to me but my friends like playing on BE. although I believe the former case might've been accidental, I don't think it would kill them to at least take a look at it to see what they can do. Had I paid for BE rather than receiving a complementary copy because I already owned JE when they released BE, something like this would make me immediately (if reluctantly) request a refund (which is another reason I am putting it here rather than on the overworked feedback tracker: missing but unavoidably necessary functionality is essentially a bug unless it was, and of course this is incredibly unlikely, the developers' intent to completely alienate someone).
Based on the above comments, there seems to be at least two different (but closely related) bugs that are being confused. One with leashes breaking inexplicably (mob drops a lead item and is able to wander; leash no longer appears to be on the mob; seems to happen whenever the server (minecraft's internal server or the smp server, whatever is doing the non-graphics processing.) is restarted), and one with leashes and their knots disappearing (selection box included) but the mobs still acting like they are leashed, which seems to happen when the client is restarted (again, it can be SSP or SMP).
The bug's are probably the same oversight (occurring when the leash is unloaded on either the server or client), but appearing to be different do to the differences in what the two do.
perhaps the current implementation should just be scrapped and redone. Or maybe they're waiting until the rest of Minecraft works better for this sort of thing? Still, if this is not working, what is the point of having this part of the lead's functionality? It's a bunch of false security for your animal farm. Take it out until it works and leave people to use fenceposts like we did before this item came out.
@miwob Done. It took a bit of finagling, both on account of my injury and because for some reason my physical keyboard won't send that keystroke combination. I had to hold F3 on the on screen keyboard (while the game was paused on account of the bug I'm reporting here, no less!) and have someone press and hold C on my wireless keyboard. It was quite the orchestration (story of my life sometimes...), but nonetheless, it's done
So on a scale of 1 to 10, how likely is this to get fixed, or at least looked at/worked on, in the foreseeable future? Don't get me wrong, I understand you have limited resources, but contrary to what you might think, this doesn't just affect me. Other people affected by this bug include but are not limited to: the other players on the private server I host, developers that receive 1.12 bug reports from me because that's the most recent version I can play on, and anyone I tell about how long it's taking to resolve this issue (a number that increases the longer it takes).
Edit: Sorry if I seem to be pushing this too hard, but to be fair, I've been dealing with this issue since 1.13 came out. The only reason it took so long to open an issue on here for it is that I thought one would have already been opened after I reported it to your email support and explained in great detail that "basically, I can't play". I don't like being obnoxious, but I also don't like bugs that sit for eternity and prevent me from enjoying all the new features you've been adding
This forge mod I found for 1.12 might have a piece of the puzzle to fixing this, but as it's for an older version of the game (before I started experiencing this problem), I'm not sure how applicable it actually is. Nonetheless, if/when you get around to trying to fix this, it might be worth taking a look, since it's open source and all: https://www.curseforge.com/minecraft/mc-mods/ungrab-mouse-mod
Thank you so much @NeunEinser! Yeah, most people are surprised I manage to play with an on-screen keyboard, but I just drag it out of the way whenever it's in the way. I'm still not exactly good at fighting (or at least not moving around while fighting. I'd probably get crushed in PvP). Hopefully you're right on that, and that's what I keep telling myself and what people keep telling me "they've added lots of accessibility lately". I know enough about coding to know things like this are never easy (library updates, undefined behavior that you never knew was actually helping someone, etc. etc.), but I'm okay with that; I just want it fixed eventually, you know? Fingers crossed these mods can help them figure it out. In the meantime, at least I should be able to play again thanks to you!
I'm not too worried about figuring out a control that works for me. My trackball doesn't have a middle mouse button, but it does have two auxiliary buttons. Ironically, I normally have them disabled because I always end up accidentally clicking them (they are just slightly too close to the main buttons and I use the mouse with my palm) but... well, they are finally going to be useful. Alternatively or additionally, I could also set up a side button (we have accessibility buttons around here) or something with Dragon NaturallySpeaking (the speech to text software I'm using to type this. It's a bit slow to control the game directly but it could press a button for me), but the point is I have options.
Honestly the hard part for me will probably be figuring out how to use fabric, as its somewhat of a new thing from what I've heard. Is it compatible with Forge? I like a lot of mods that are currently only available for forge; If not, that's fine, just being able to play the latest snapshots is a relief. Thanks again!
Good news: my problem only happens if raw input is enabled in Options> Controls> Mouse Options. As such, this might not be as high a priority issue as I initially thought, since disabling that seems to allow me to use the On-Screen Keyboard normally. I don't know how I missed this setting until now (I suspect it was added sometime between last time I looked for mouse settings to help and now. I know for a fact it wasn't there in 1.13 when I checked the first time), but someone on the Forge Project's discord suggested trying it, so I did.
All that said, there might still be an underlying issue that caused this to start happening… I'm just not sure what exactly. Perhaps that setting, at least until this is fully resolved, should default to OFF? What does it even do, anyway?
In any case, I'm very happy to be able to play the game without modding again (even if it's so I can subsequently add 100+ forge mods...). Back to being a happy player
As an aside, while playing around with the snapshot, I noticed it no longer seems to recognize the state of numlock,
so I can't use my numpad as arrow keys... it just sees them as numbers, which means I can either have 2, 4, 6 and 8 control my movement (as I normally do with the numpad versions of those numbers) or my hotbar (as I normally do with the normal number keys across the top of the QWERTY).Amended: it just displays ambiguously. It still recognizes the numbers as separate numbers. Furthermore, while I would normally resolve this with a fairly simple AutoHotkey script (I use AutoHotkey to remap a lot of my keys), none of that seems to work on this version. Even my previously-functional remap of vk0C::Space seems to break on the snapshot... So I might have another issue to report. Shall I go ahead with that in a separate ticket?Just to clarify/summarize, this issue is at least partially resolved for Java Edition (JE) because I can disable raw input and it stopped happening, but I have the same basic problem on Bedrock Edition for Windows 10. Is there a way this can be linked so it shows up on the BE tracker?
understood and done: BE issue #57264
as far as I know this is still a valid issue. Sorry I didn't reply sooner. I kind of dropped the ball
Steps to Reproduce:
1. load up Bedrock Edition on Windows 10
2. open up the Windows On-Screen Keyboard (C:\Windows\system32\osk.exe on, presumably, all versions of Windows 10. Certainly all that I am aware of but that's not saying much suppose. If that's not the executable name, try getting to it from the Ease of Access Center or mouse/keyboard settings)
3. Load any world and attempt to use the on-screen keyboard in place of your keyboard
Observed Results:
it is impossible to interact with the on-screen keyboard like I can do (at least when I disable raw mouse input) in JE because, as you should be able to observe, the cursor lock prevents the cursor from interacting with the on-screen keyboard no matter how fast you move the cursor
Expected Results:
By contrast, on JE, if I move the cursor fast enough so that it gets to the on-screen keyboard before it's pulled back, it will stay there until I move it off again. This is relatively workable behavior, and is about equal in usefulness as it would be if the cursor's actual position was not modified until it reached the edges of the game window as another voxel builder, Trove, does.
Wait, title bar? What does that have to do with anything? Are you talking about activating the OSK window when it is over the game? Because that would be impossible, regardless of title bar, for the same reason I specified above: I cannot get the mouse to go over to the on-screen keyboard because the cursor is locked when it's on the player's aiming reticle.
I will try what you said tomorrow, as the built-in OSK has a title bar by default, but I highly doubt it will help with the issue I described.
except that's not what I want to do. The OSK requires the working window to be in focus (otherwise it doesn't know where to send the keystrokes), and I don't want to change focus to the OSK or any other window. What I want is to be able to interact with the OSK AT ALL when the game is in focus and I don't have an inventory or any other menu open, but again, I cannot do so because I can only click things in the game world due to the cursor lock. That is to say, the issue isn't that I can't break out of the cursorlock to change focus; the issue is that if I do anything to change focus, it defeats the purpose of having put focus on the game window in the first place.
I'm guessing you either didn't try following my reproduction steps, or (despite my best efforts) didn't understand them, if you don't know what I mean. I'll see if I can get a GIF or video together later to demonstrate, since that's generally better than reproduction steps anyway...
@Greymagic27 Okay so I should follow up on that issue then?
I can confirm this is happening (and am responsible for one of the dupes of this issue). I've tried posting a comment multiple times and, while I have my suspicions on why it was rejected the first two times, I am nonetheless hesitant to post it a third time without knowing for certain. Checked my inbox and spam folder; zilch!
I am using either my Outlook or Gmail, if that helps. Not positive which but I think the former.
is there any workaround for this at least, such as an activity feed somewhere on the site? do the mods get mad if I just go to trial and error on it until I get approved?
The fact this has been open since at least March of last year is kind of disappointing, since it's probably not doing anything to help the efficiency of the moderation team if their rejection reason isn't being reliably communicated.
Can confirm for 23w33a.
(Approximate) expected behavior: On the first tick where a LivingEntity is being deserialized, don't run the check comparing health with LivingEntity.getMaxHealth() until the underlying field has been initialized to account for Attributes.
(Please. It's been 10 years.)
I've been trying to migrate my stuff to ISO 8601 ever since I read the XKCD comic/PSA about it.
On a tangentially related note, can y'all standardize This Very Mojira™'s date format next? I just posted on a bug that's still haunting us from 10 years ago, and had to do a double take to make sure I didn't misinterpret the year.
(I can put this aside into an issue of its own if that helps, just tell me what section/tags/whatever, I don't use JIRA much)
Maybe CatLieOnBedGoal should cancel itself if the pathfinding fails? To me the real "bug" is the cat never reaching the goal and getting mysteriously stuck in corners and such, particularly when the presence of the bed isn't even realized yet. Not so much a cat wanting a catnap, that's typical!
From my somewhat limited and informal testing it does eventually cancel but it takes either a long time or a higher priority goal like SitWhenOrderedToGoal being invoked. Or breaking the bed.