mattp_12
- mattp_12
- mattp_12
- America/New_York
- Yes
- No
Low![[Mojang] Billy Sjöberg](../../../data/avatars/users/42806.png){kind=small}
MC-252404
Normal
MCL-21590MC-255081![[Mojang] Maxime Lebrot](../../../data/avatars/users/18941.svg){kind=small}
![[Mojang] Gnembon](../../../data/avatars/users/93709.png){kind=small}
![[Mojang] slicedlime](../../../data/assets/gravatar/slicedlime.jpeg){kind=small}
The "previous output" text gets cut off in the command block GUI.
Trapdoors, fencegates, and blocks that changeblockstate when right clicked don'tmakesoundswhenshift right clicked with an item in your handBlocks that change state when right clicked (trapdoors, etc) don't play sound with shift right clicked while holding an item
Blocks that change state when right clicked (trapdoors, etc) don't play sound withshift right clicked while holding an itemBlocks that change state when right clicked (trapdoors, etc) don't play sound when shift right clicked while holding an item
In the latest 1.13 snapshot, blocks such as fencegates and trapdoors don't play their sound when shift clicked if you have an item in your hand.
Here's a video of it : https://www.youtube.com/watch?v=AxSlhydlcDA
(I would've attached it, but it was giving me an error)This occurs with the new trapdoors, and the standard oak wood one, all variants of fence gate, all wooden door types, and, from what I'm assuming, all blocks that change their state (and have no inventory), even when shift right clicked.
You must be holding something that can't explicitly be placed when you shift click, so you can't be holding a block, for instance. Items like swords work, because you don't perform an action with the sword.
Edit : I don't know how I just noticed, but the item also does not swing, as you can probably see.
When using /locate or /locatebiome, "blocks away" isn'tproperlychanged to "block away" when you are 1 block away from target
![[Helper] Lord_Quadrato](../../../data/avatars/users/26105.png){kind=small}
mattp_12, 1.13 is already marked as affected, please check before commenting.
![[Mod] Les3awe](../../../data/avatars/users/79847.png){kind=small}
![[Mod] Jiingy](../../../data/avatars/users/91802.png){kind=small}
mattp_12, when trying to reproduce this issue in the latest snapshot 24w20a, I was able to confirm the husk (or any entity) staying on top of the horse after 30 seconds. This occured both when using /ride, and summoning the entity with the command in the report. It seems like the issue was fixed at one point, but later reverted somehow. Can you still observe the result you got?
Here is my result:
2024-05-16_16-31-27.mp4
It looks like it's intended, but I could be mistaken.
This may be intended, as originally, it was a bug.
See video : https://www.youtube.com/watch?v=VyUeqeLoOb8
Happens in release 1.13, as well.
Confirmed for 1.16.3. Noticed a stone sword with 0 durability drop from a wither skeleton.
Confirmed for 22w17a (and 1.18.2).
Present in Pre-release 4
Happening in 1.19 Pre-release 5 as well. Scrolling down the world list and searching makes the results go off-screen until I scroll the mouse.
Can confirm for 1.19 Release Candidate 2.
Can confirm for 1.19 Release Candidate 2.
Is present in 22w24a.
Running /say @e shows
in the game output.
Ah I understand now, thanks. Yeah, I was just misunderstanding the output.
Confirmed for 1.19.1 Pre-release 1.
Can reproduce.
Can reproduce.
Can confirm for 22w42a.
Also happens with rafts.
Can reproduce.
Can confirm for 22w43a.
I imagine that at least holding Q is intended behavior, as in 22w42a
MC-135973"Can't hold Q to drop items rapidly from container inventories" was fixed.In recent snapshots the outputs of the commands have changed slightly.
For instance, running
outputs
Running
outputs
The wording of the error is different but the output is the same in that they still return 'minecraft:minecraft' and 'minecraft:' depending on the command.
Given the output is similar I think that marking the issue as still affecting newer snapshots/versions is okay.
I'm not sure if this is the same issue, but when switching my audio device from VoiceMeeter Input to Speaker/Headphone (Realtek High Definition Audio), this is continuously shown in the game output until switching the device again:
Get attributes size<long number>: Invalid device. Error starting SoundSystem. Turning off sounds & music java.lang.IllegalStateException: Failed to get OpenAL attributes at ebh.i(SourceFile:212) at ebh.a(SourceFile:168) at fre.h(SourceFile:113) at fre.a(SourceFile:103) at fre.a(SourceFile:235) at frh.a(SourceFile:266) at eio.q(SourceFile:1877) at eio.f(SourceFile:1142) at eio.e(SourceFile:776) at net.minecraft.client.main.Main.a(SourceFile:244) at net.minecraft.client.main.Main.main(SourceFile:51)I was thinking this, but the error I was getting is slightly different, being
rather than
Maybe the error changed wording between updates?
Ah okay, fair enough.
Can confirm for 1.19.3.
Can confirm for 1.19.3.
I noticed this happening when rearranging resource packs/data packs in their respective menus.
Can confirm for 1.19.3.
Can confirm for 1.19.3.
Confirmed for 1.19.3.
This must have been fixed at some point.
At least in 23w03a, untamed horses now properly dismount the mob.
Works either with /ride or with the summon command.
Can reproduce, the game does indeed crash.
Can confirm for 23w04a.
Can confirm for 23w04a.
Confirmed for 23w04a.
An entity whispers to me and I whisper to myself despite specifying !player.
This must have been fixed at some point. It happens in 1.18 but doesn't in 1.19, so somewhere in between.
I'm on 23w04a and cannot reproduce, the blocks are killed and disappear.
Confirmed for 23w04a.
Make sure to enable the datapacks enabling the bundle and 1.20 features when creating the world.
According to
MC-257082, the previous behavior of FOV changing while riding an entity was a bug. According to that bug report your speed also did not actually change, so the FOV changing wasn't indicating anything anyway.Also appears to affect the Open Pack Folder button (23w06a).
Previously (1.19.3) the button would be deselected when moving the mouse away.
Reproduced on 1.19.4. I just had to add a couple more zeroes to the command, otherwise it gave an output similar to
after stalling for a few seconds.
Something like
/spreadplayers ~ ~ 1 100000000 true @e[type=!player]worked for me.
Reproduced in 1.19.4. Making the setup and pressing the button causes the setup to fly off into the distance.
Confirmed for 1.19.4.
Confirmed for 1.19.4.
Confirmed for 1.19.4.
Confirmed for 1.19.4. The tag is different when grabbing it via a command like
Confirmed for 23w12a.
On 1.19.4 the game pauses when placing a sign.
The sign GUI stays open on 1.19.4 when teleported away if opened to LAN, and text entered is saved. I believe this behavior is what
MC-117809is describing. In fact that issue should most likely be marked as resolved as the GUI now closes when you get too far from a sign on 23w12a.This issue is not present on 1.19.4 as the GUI always stays open even if you're too far away.
Confirmed for 1.19.4 and 23w14a.
As of 1.20 Pre-release 1, this issue is fixed. Fixed, as in, all three dark oak planks simply don't generate anymore, making the bush also not generate. See newly attached image.
I'm not sure if the mineshaft not generating the planks would itself be considered a bug however.
Confirmed for 1.20 Pre-release 5.
Ah okay. I don't exactly think my issue is a duplicate because I am specifically talking about the lack of menu focusing. Because for example, for accessibility reasons, you may be using tab to navigate the menus and using enter to confirm. If the menu is scrolled away while the button was already tabbed into, it is not immediately obvious what happens after clicking enter because the menu stays where it is (besides the button click sound). It just so happens that this issue also occurs if you had clicked a button normally, scrolled, and hit enter (because of the linked bug you mentioned).
The issue you linked talks about how buttons stay selected after clicking. In my opinion this is related but not the same thing necessarily. The linked issue may indeed be a bug in its own right, but I think mine is related rather than being the same thing.
Also happens on 23w31a when joining a single player world, but not every time it seems?
A crash-reports folder wasn't generated, but I attached the launcher_log.txt file. It unfortunately doesn't seem to give much more info. On lines 3314 and 3315 it just says
The log is about right when I force closed the game when it was frozen and the crash screen shows in the launcher, like what the video shows at around 33 seconds.
Also, for reproduction sake, I am using VoiceMeeter Banana when reproducing this, and not regular VoiceMeeter. Just in case it makes a difference.
I have this issue too, but only when certain audio devices are set as the output device in Minecraft options. Namely devices that are not Voicemeeter related or monitor speakers.
I have noticed that when enabling the narrator the game freezes until Voicemeeter is completely closed.
MC-264913This appears to be fixed as of 23w40a.
If I had to take a guess I'd say the fix was a result of the changes to the raw JSON format in this snapshot.
Confirmed for 23w40a
So the game is no longer freezing (narrator button cycles what is narrated), but the narrator is also not working, even when VoiceMeeter is closed. Even on older Minecraft versions. 1.20.2 and 23w40a - 41a are what I tested, with VoiceMeeter and without.
I can only assume a recent Windows update messed with something but I don't know. I updated Windows yesterday. Not sure how this could be the case, but it's the only thing I can think of.
As of now I'm going to not update this issue unless it starts happening again. I'll test again next snapshot (or when Windows gets another update I guess? Whatever comes first).
I assume this is still an issue as of 23w41a but because of
MC-265767I technically can't know for sure lolIt's possible that this issue is a possible behavior of
MC-265744.I saw that issue prior to writing this one but I didn't think it was directly related.
I'll test again in the next snapshot where that bug is fixed.
This does appear to be fixed in 23w42a. It probably just was a behavior of
MC-265744. I'm guessing this should just be marked as duplicate then?I'm not sure what was changed or what happened but the narrator works correctly now on 23w43b as well as on other versions that I tested that were affected by this.
I can only assume a recent Windows update changed audio in some way or some internal sound updates were made to the game.
Ooh ok, I thought I tried just placing the minecart but I forgot about that when writing this.
I don’t exactly think it is a duplicate. I know that entities you are riding unfreeze when you mount them. I am specifically referring to if riding on a camel which is sitting down should count as “riding” when it comes to the game being frozen. Because if so, pressing a movement key to make it stand should adjust the player mounting position on the camel and make it controllable (aka unfrozen).
Additionally, a similar issue exists if you are riding a sufficiently scaled up horse or camel and try to open your inventory.
A command like
/attribute @e[type=camel,limit=1,sort=nearest] minecraft:generic.scale base set 5should work.
I'm not creating an issue for this because it seems relatively similar.
This bug appears to be fixed in 24w09a. The back button is now completely shown when the window is resized.
I see, thanks for explaining
Simplified description and how to reproduce
Seems to be fixed in 24w33a.
This appears to have just happened to get fixed in 1.21.2pre2, presumably as a result of this ender pearl fix:
MC-276716