[Mojang] Georgii Gavrichev
- fry
- ID257868
- Europe/Stockholm
- Yes
- No
is duplicated by
duplicates
is duplicated by
duplicates
is duplicated by
is duplicated by
duplicates
is duplicated by
duplicates
is duplicated by
The change happened in the new version of OpenAL-soft. Please refer to this page for further information, and potential workarounds, as well as to this comment from [Mojang] Georgii Gavrichev.
The bug
The sounds are too much related on the player's view, what causes a mono sound if a sound is applied perfectly at right or left.
Sounds are panned too aggressively to the left or right depending on where the player is facing. For example, if a mob is making a sound, and the player isn't looking directly towards it, the sound will be panned completely to the left or right. This effect is most obvious while wearing headphones.
This issue was pointed out in MC-121364 but that issue was erroneously marked as "Works As Intended"
[Mojang] Georgii Gavrichev suggested a workaround by downloading an older version of OpenAL-soft and using a JVM argument, but that causes my game to crash, and a workaround really isn't the best long term solution.
The list of changes for 1.13-PRE4 mentioned "Updated LWJGL" so I was hopeful that would have solved this issue, but that doesn't seem to be the case, sadly.
The best way to experience this issue is to put a music disc into a jukebox, and look around in different directions, paying attention to how the game handles where to place the sound in the stereo space. I recommend comparing the latest pre-release with 1.12.2, and you should immediately notice a difference. Even walking around, the sound of footsteps on the grass can be panned inappropriately far to the left or right, depending on which direction the player is walking.
Thank you for reading! I hope the team is made aware of this issue so it can be fixed before the final 1.13 release! Keep up the great work!
Quote of comment by [Mojang] Georgii Gavrichev from a private report about this:
The chunks that are regenerated have the flag "LightPopulated" set to false, which normally can only happen to the chunks on the border of the world, so the upgrade process drops them (since they might have not generated fully). This is a reasonable behavior, since those chunks couldn't've been modified by the player. Our guess is that you used some kind of a tool to edit the chunks; if so, please set that flag to true, and it should fix this issue for you.
If your server is/was a Spigot server you will need to use CraftBukkit/Spigot to convert the world. Spigot in 1.12 didn't set the "LightPopulated" flag, so that vanilla Minecraft will reset those chunks.
After a conversion with Spigot 1.13 the world can be opened in vanilla Minecraft again without problems.
See also the Bukkit, CraftBukkit, Spigot & BungeeCord 1.13 release notes:
+++ Spigot 1.12.2 worlds must be converted using CraftBukkit/Spigot and NOT Vanilla.
When i migrated my island world from 1.12 to 1.13, i have only 1/4 island. Around is new generated world.
1.12 world download - https://mega.nz/#F!C3g3kKwK!VjHjeZ9cHEDmWBikp6rwyg
World location - /tp -1536 80 1536
Images - https://imgur.com/a/KI70rz5
We can't reproduce any of the issues described in this bug report anymore, and it's really hard to hit a moving target (chunks not appearing on the screen can be caused by any number of things going wrong in a looong chain). If you still have this issue, please provide exact reproduction steps if you can; if running singleplayer, please provide a screenshot with the debug screen open and the profiling graphs showing (Alt + F3); if running multiplayer, show exact server arguments + number of active players + at least a rough idea of what those players were doing; a debug dump from the server when the issue occurs will help too (can be obtained by running /debug start followed by /debug stop shortly after). If you can only reproduce it in multiplayer, try to trigger it with as few users as you possibly can, so we can try the same here. Thanks!
The bug
Worlds will not load and/or if they seldom do, they load chunks very slowly. I run Minecraft the same way I always have and I even tried the typical responses to making the lag better; none of which helped.
In order to fix your existing world, you can try following these steps. Apparently this is just a temporary workaround, so you might need to repeat this once the issue reoccurs again.
Singleplayer: Select world → Edit world → Optimize world → check "erase cache data" → Backup and load
Multiplayer: Start the server.jar with the following command:
java -jar server.jar --forceUpgrade --eraseCache
This only needs to be done once, after this you can start your world or the server the usual way again.
Minecraft Realms: Download the world from your realm, copy it into your Minecraft singleplayer worlds folder, follow the steps for singleplayer, and then upload the world back up to your realm.
If this is still happening to you, and if you have a backup of the world right before you can trigger the issue, that might help; I managed to get one and consistently reproduce it, and fixed what was causing it, but there might be more to it; if you can reproduce it by
- Restoring the backup
- Choosing edit -> optimize -> erase cached data (before loading it)
- See the issue immediately after loading the world
Then it would be very helpful if you can share your world backup, along with what render distance you're using.
Thanks!
I found a stairway I'd previously made now pitch black.
I later found other areas (entire chunks, surface to bedrock) showing this behavior as well.
This is not just a visual glitch - the light sources I've used (torch, lantern, and jack-o-lantern) are all nonfunctional. As a result, monsters will spawn in them, and underground crops in these areas will break.
Forcing every single light source to update (or outright replacing them) is the only way I've found to get them to visually working again.
Reopened.
gary cousins, this is a bug tracker and not a discussion forum. If you don't have anything constructive to add to the report, please don't comment here. Consider this a warning.
To anyone who is experiencing this bug in 1.14.2-pre2 after having optimized the world with erasing the cache: If you want to help us with solving this issue for good, please read this comment by [Mojang] Georgii Gavrichev (that's the same comment as in the "Please read" box above). Just commenting "I have this issue as well" is not helpful.
Hi [Mojang] Georgii Gavrichev, the world was generated completely fresh in 1.18 Pre-release 1. I didn't upgrade versions of the world or anything along those lines, just a complete 1.18 Pre-release 1 vanilla world. ![]()
You may not be able to reproduce this consistently with the above information I've provided as a result of lush cave decorators varying regardless of world seeds. (MC-219200). Nonetheless, I can assure you that the problem is still present. ![]()





The change happened in the new version of OpenAL-soft - you should be able to get the old behavior if you manually override the openal library by adding a JVM argument -Dorg.lwjgl.openal.libname=path/to/openal_dll_or_so. openal version that lwjgl2 used is 1.15.1, which you can get here: http://kcat.strangesoft.net/openal-binaries/openal-soft-1.15.1-bin.zip
Fixed this particular screen, please create separate issues for any other gui regressions you find. Thanks!
Most likely caused by LWJGL update; the way the mouse input is handled is different now, the range of acceleration slider should be still enough for you to get the value you had before
Corresponding GLFW issue: https://github.com/glfw/glfw/issues/1112
We can't really reliably establish the difference between 1.12.2 and current fire spreading speed, so closing until either we or someone else can do that.
Something is very wrong with your world - villages.dat files are empty, for example. IndexOutOfBounds exception appears to only be triggerable by the same issue - if the region file is somehow truncated. The only explanation we can think of is running out of disk space, or some other storage corruption.
It works if the grass block is right in front of the dispenser, and not 1 block below.
1.13-pre8 should have fixed at least one source of the memory leak, please verify that it still happens for you.
Flying through those chunks in spectator in 1.12.2 and letting the game save them fixes the issue; if you see chunks in the external tool it doesn't necessarily mean that you've visited them in game. Chunks on the border of the generated area are not fully populated with all the relevant data - they need all of their neighbors to be generated too, and the only reasonable way for us to determine that is to look at the lightPopulated flag - if we keep chunks with that flag set to false, you'll see visible seams on most 1.12 to 1.13 converted worlds.
Please attach your full log (with errors and warnings shown), and, if possible, a backup of your world before you upgraded it.
Crash caused by teleporting to big coordinates is
MC-133839and should be fixed (after the next release), everything else should've been fixed earlier.Please also try adding -XX:-OmitStackTraceInFastThrow to your JVM arguments, to see the full stack trace.
Another potential thing worth mentioning: it's not always possible to reliably tell if you're using headphones or speakers, and openal might not be configured properly as a result of that; one solution is to manually set "stereo-mode = headphones" in alsoft.ini/conf. In the future we will most likely ship with the config file, and make it somehow toggleable between headphones and speakers, but it is not really something that is possible with the current way we do things.
Best results will be produced with headphones and with hrtf, as described here: https://www.reddit.com/r/oculus/comments/1fzonq/psa_for_games_using_openal_including_minecraft/
but this is certanly not something that the game should do for you, and something that you'll have to do yourself.
Sound is a very subjective thing, and even though the newest library version with the proper configuration is my preferred setup, some people will want to keep it exactly like it was before, and that's why my original response tells how to go back to the exact way it sounded in 1.12.2.
Couldn't reproduce; attempted steps:
Upstream issue: https://github.com/LWJGL/lwjgl3/issues/162
You can also see the yellow outline during the sunset/sunrise.
Not applicable anymore with 1.14 changes.
Couldn't reproduce by creating a world in 1.13.2 and loading it in 19w13b; please reopen if you can still trigger it.
And it will continue to happen, since the chunks have the heightmap present and wrong. Does it happen if you upgrade from 1.13.2 directly to the latest snapshot?
World where this bug happened will need to be fixed manually, by replacing the light sources, or by restoring the backups; Can you reproduce it in either a freshly created world, or in a world upgraded from 1.13.2 or earlier?
Obsidian covered with grass is indeed fixed; please open new issues for anything else that is not upgraded properly, with exact examples (world + coordinates) if possible.
Can you attach your world to the bug report?
Is this still an issue in the latest version?
"Remove cached data" option in optimize world screen should fix your world, and the underlying cause of the issue was fixed earlier.
Please provide the reproductions steps if you can, I can't trigger it myself on a fresh world in 1.14-pre1.
We can't reproduce any of the issues described in this bug report anymore, and it's really hard to hit a moving target (chunks not appearing on the screen can be caused by any number of things going wrong in a looong chain). If you still have this issue, please provide exact reproduction steps if you can; if running singleplayer, please provide a screenshot with the debug screen open and the profiling graphs showing (Alt + F3); if running multiplayer, show exact server arguments + number of active players + at least a rough idea of what those players were doing; a debug dump from the server when the issue occurs will help too (can be obtained by running /debug start followed by /debug stop shortly after). If you can only reproduce it in multiplayer, try to trigger it with as few users as you possibly can, so we can try the same here. Thanks!
Thanks for the analysis, it's very much appreciated.
First part of the issue was indeed a simple omission - already lit chunks were not marked as such after reloading.
Initializing the light using the implicit light level was the initial approach I tool, but it was not compatible with the worldgen/recomputation of data, since it is only correct if the chunk section is only filled with air/non light blocking blocks, so initially it resulted in full chunks filled with skylight; it should be done if the light for the chunk is in a computed state already, and when the new section needs to be stored for that chunk; I tried that approach, but it caused large dark spots of light to appear during worldgen, which I think is caused either by not quite right order of operations in worldgen lighting, or by
MC-148723, or by some other issue; I'll re-enable it after fixing that, and we'll see what happensTriggered by some change in lwjgl 3.2.1 (works fine on 3.2.0). We rolled back to 3.1.6, but that caused
MC-148461; proper fix coming laterDoes this still happen in 1.14.1-pre1 with either a new world, or a world with an erased cache? Please keep in mind that it's possible to trigger it, close the game, but not see it until you load the world the next time.
This bug is taking so long because we have not found any way at all to trigger it on demand; I never manager to trigger it once on my machine, and there seems to be no action in particular that makes it more or less likely to happen; a few potential causes of this error were fixed in 1.14.1-pre1, but without being able to check there's no way to know for sure.
1.14 or 1.14.1-pre1? One of the fixed issues was for the server shutdown code.
Is this the same as https://bugs.mojang.com/browse/MC-151079 ?
If this is still happening to you, and if you have a backup of the world right before you can trigger the issue, that might help; I managed to get one and consistently reproduce it, and fixed what was causing it, but there might be more to it; if you can reproduce it by
Then it would be very helpful if you can share your world backup, along with what render distance you're using.
Thanks!
No worries, better safe then sorry
Can you be more specific?
Pack has version 4, which is the format used in 1.14; 1.15 will use version 5, and version 4 is partially updated to that when possible, but this pack has banner patterns in 1.15 format, which makes them break on load; you need to either roll them back to 1.14 format, or update the pack fully to 1.15 format
Please post the full game log if you experience this issue, in addition to the crash report.
Is this still an issue in the latest pre-release?
The glass block does not render it's faces when seen from the inside; is that the only issue you see, or is there something else?
Hi! Could you please attach the full server log with the crash on the latest snapshot? It should contain more debugging information that should help us track down this issue
Is this still an issue in the latest snapshot?
I can reproduce this in 21w43a, but not in 21w44a; is this still an issue in the latest snapshot?
If you still have this issue in 21w44a, try erasing the cached data (Select world in the menu, press Edit, press Optimize World, check Erased cached data checkbox, proceed)
Is this still an issue in 21w44a? Please try loading directly from 1.17.1 to 21w44a; for worlds loaded in 21w43a erasing the caches might solve the issue (Select world in the menu, press Edit, press Optimize World, check Erased cached data checkbox, proceed)
Is this still an issue in 1.18 pre-release 1? fluid propagation was improved
Is this still an issue in 1.18 pre-release 1?
[Mod] Avoma was the world created fresh in 1.18 Pre-release 1, or was it created earlier?
Please provide seed/coordinates for 1.18 Pre-release 1, if the issue is still happening
Is this still an issue in 1.18 Pre-release 2?