macks2008

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.

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)

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 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.

@Greymagic27 Okay so I should follow up on that issue then?

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...

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.

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.

understood and done: BE issue #57264

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?

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?

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!

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

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

@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 🙂

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.

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.