Affects 1.21.3
Can confirm in 1.21.2-rc1.
Yes, this still happens in the newest version to date.
I can confirm this issue in 1.20.2.
The game seems to scan all potential devices for audio (not just audio devices).
Thus far, I have discovered in 1.20.2 that the issue also occurs on a resource pack reload.
For example, this bug had been affecting my connected mouse which I had fixed by disconnecting the mouse (example 1). When my mouse was disconnected, the issue came back after a game relaunch and was fixed by connecting it (example 2).
Example 1:
[21:02:38] [Render thread/INFO]: Audio device was lost!
[21:02:38] [Render thread/WARN]: Missing sound for event: minecraft:item.goat_horn.play
[21:02:38] [Render thread/WARN]: Missing sound for event: minecraft:entity.goat.screaming.horn_break
[21:02:38] [Render thread/WARN]: Failed to reset device: Invalid Device
[21:02:38] [Render thread/ERROR]: Get attributes size1616449638432: Invalid device.
[21:02:38] [Render thread/ERROR]: Error starting SoundSystem. Turning off sounds & music
java.lang.IllegalStateException: Failed to get OpenAL attributes
at ejl.i(SourceFile:222) ~[1.20.2.jar:?]
at ejl.a(SourceFile:178) ~[1.20.2.jar:?]
at gdn.h(SourceFile:116) ~[1.20.2.jar:?]
at gdn.a(SourceFile:106) ~[1.20.2.jar:?]
at gdn.a(SourceFile:238) ~[1.20.2.jar:?]
at gdq.a(SourceFile:272) ~[1.20.2.jar:?]
at eqv.t(SourceFile:1961) ~[1.20.2.jar:?]
at eqv.d(SourceFile:1237) ~[1.20.2.jar:?]
at eqv.f(SourceFile:856) ~[1.20.2.jar:?]
at net.minecraft.client.main.Main.main(SourceFile:253) ~[1.20.2.jar:?]
Example 2:
[21:29:37] [Render thread/INFO]: Audio device was lost!
[21:29:37] [Render thread/WARN]: Missing sound for event: minecraft:item.goat_horn.play
[21:29:37] [Render thread/WARN]: Missing sound for event: minecraft:entity.goat.screaming.horn_break
[21:29:38] [Render thread/ERROR]: Get attributes size2618220208336: Invalid device.
[21:29:38] [Render thread/ERROR]: Error starting SoundSystem. Turning off sounds & music
java.lang.IllegalStateException: Failed to get OpenAL attributes
at ejl.i(SourceFile:222) ~[1.20.2.jar:?]
at ejl.a(SourceFile:178) ~[1.20.2.jar:?]
at gdn.h(SourceFile:116) ~[1.20.2.jar:?]
at gdn.a(SourceFile:106) ~[1.20.2.jar:?]
at gdn.a(SourceFile:238) ~[1.20.2.jar:?]
at gdq.a(SourceFile:272) ~[1.20.2.jar:?]
at eqv.t(SourceFile:1961) ~[1.20.2.jar:?]
at eqv.d(SourceFile:1237) ~[1.20.2.jar:?]
at eqv.f(SourceFile:856) ~[1.20.2.jar:?]
at net.minecraft.client.main.Main.main(SourceFile:253) ~[1.20.2.jar:?]
Yes, this issue has affected 1.19.4 as well as every 1.20 snapshot release to date.
EDIT: It now seems to concern all perspectives.
Could be the result of the fix of MC-183309.
Surprising how most of the related hand animation bugs weren't at all mentioned in the 1.19 changelogs.
I have heard of custom biome id issues, but these aren't.
The datapack attached has the necessary world data for vanilla world generation including the now essential "noise route" field.
EDIT: After investigating the issue further, I noticed that it affects a more general cause with worldgen noise settings and that the one presented by the reporter seems irrelevant for a fix has been explicitly stated in the attached game log.
Thus, I would suggest updating the report concerning a more up-to-date issue with the provided datapack for it prevents the world loading once the new generation settings are stored into the level.dat file.
I see. It could be that I'm simply experiencing an issue in the way my browser deals with cache. I doubt it; if the Minecraft website's language can be input manually through the address bar (and is usually independant to the IP address), can't the launcher language affect the website page language at all?
That I knew beforehand; must have forgotten to remove it in the summary (as it is now confirmed to affect both perspectives). Also appreciate the change @Chandler.
Can confirm a crash when renaming the dimension after generating it. It has registered the dimension already but under a different name (which it attempts to re-create)
EDIT: This is working fine with the updated datapack provided. Have you tried testing the issue in 1.16.2 pre2 ?
Chain command blocks execute in a straight line; try setting an unconditional chain block at every start of a certain direction (without the direction facing any other way but away from the last block or this will cause a partial chain indeed).
Funny enough this bug hasn't been resolved for US english.
EDIT: or wasn't
That's because the last Pre-release was minutes from being released. (Never had this one before!)
Confirmed for 1.16-pre4
Can confirm for 1.16-Release Candidate 1
Glad that this is a bug, and not a translation error in the English language to be reissued on Crowdin. 🙂
Affects 24w44a