ziggurism
- ziggurism
- ziggurism
- America/New_York
- Yes
- No
MC-92923
Normal
WEB-197![[Mojang] Jeb (Jens Bergensten)](../../../data/assets/gravatar/jeb.jpeg){kind=small}
With 15w49a, the ability was added to shear off the pumpkin head of the snow golem, to reveal their "derp" face (https://twitter.com/jeb_/status/670277230895960064). But upon quitting the world and reentering, all derpface snow golems have regained the pumpkins on their heads.
*What I expected to happen:*
Snow golems whose head pumpkins I've sheared off should not have pumpkins on their heads even after I quit and rejoin*What actually happened was:*
Snow golems whose head pumpkins I've sheared off have pumpkins on their heads after I quit and rejoin*Steps to Reproduce:*
1. Spawn a snow golem with two blocks of snow and a pumpkin on top.
2. Shear the snow golem's head, exposing his derp face
3. Press escape to exit your world. Then enter world again, and observe snow golem face.
With 15w49a, the ability was added to shear off the pumpkin head of the snow golem, to reveal their "derp" face ([jeb on twitter](https://twitter.com/jeb_/status/670277230895960064)). But upon quitting the world and reentering, all derpface snow golems have regained the pumpkins on their heads.
What I expected to happen:
Snow golems whose head pumpkins I've sheared off should not have pumpkins on their heads even after I quit and rejoinWhat actually happened was:
Snow golems whose head pumpkins I've sheared off have pumpkins on their heads after I quit and rejoinSteps to Reproduce:
1. Spawn a snow golem with two blocks of snow and a pumpkin on top.
2. Shear the snow golem's head, exposing his derp face
3. Press escape to exit your world. Then enter world again, and observe snow golem face.
With 15w49a, the ability was added to shear off the pumpkin head of the snow golem, to reveal their "derp" face ([jeb on twitter](https://twitter.com/jeb_/status/670277230895960064
)). But upon quitting the world and reentering, all derpface snow golems have regained the pumpkins on their heads.What I expected to happen:
Snow golems whose head pumpkins I've sheared off should not have pumpkins on their heads even after I quit and rejoinWhat actually happened was:
Snow golems whose head pumpkins I've sheared off have pumpkins on their heads after I quit and rejoinSteps to Reproduce:
1. Spawn a snow golem with two blocks of snow and a pumpkin on top.
2. Shear the snow golem's head, exposing his derp face
3. Press escape to exit your world. Then enter world again, and observe snow golem face.
With 15w49a, the ability was added from MCPE to shear off the pumpkin head of the snow golem, to reveal their "derp" face (see jeb on twitter https://twitter.com/jeb_/status/670277230895960064). But upon quitting the world and reentering, all derpface snow golems have regained the pumpkins on their heads.
What I expected to happen:
Snow golems whose head pumpkins I've sheared off should not have pumpkins on their heads even after I quit and rejoinWhat actually happened was:
Snow golems whose head pumpkins I've sheared off have pumpkins on their heads after I quit and rejoinSteps to Reproduce:
1. Spawn a snow golem with two blocks of snow and a pumpkin on top.
2. Shear the snow golem's head, exposing his derp face
3. Press escape to exit your world. Then enter world again, and observe snow golem face.
Confirm in 1.9-pre2
While testing
MC-30646"Hardcore game is not deleted" I found what may be another manifestation of the same bug, or maybe a new bug (perhaps related toMC-526"Worlds will not delete").Not only does a hardcore world not delete with the hardcore death screen deletion button (
MC-30646), but additionally even after an apparently successful manual deletion on the world selection screen, it can still appear.Steps to reproduce:
1. create singleplayer hardcore world.
2. Die in your hardcore world
3. Choose "delete" on the death screen (not "spectate").
4. Get dropped back to title screen.
5. Choose singleplayer and view list of worlds. Observe that the hardcore world is not deleted, as perMC-30646.
6. Highlight hardcore world and choose delete.
7. On confirmation screen ("forever is a long time!"), confirm deletion.
8. Get dropped back to singleplayer world list. Observe that hardcore world is not on the list, indicating (apparently) that it was deleted successfully.
9. Hit escape.Expected result: go to title screen. Hardcore world remains deleted.
Actual result: get kicked back into your hardcore world, facing once again the choice to delete or spectate. The first time I arrived here, I chose to spectate and my world was full of chunks that wouldn't load, and the game crashed with a memory overflow shortly, indicating maybe some part of the deletion was successful. On subsequent attempts, spectator mode worked fine, with no crashes, in the supposedly deleted world.
Windows10, Java 1.8_71 32bit, 64bit
Hardcore world restoredafter apparent successful deletionafter apparent successful deletion, hardcore world still runs in background
While testing
MC-30646"Hardcore game is not deleted" I found what may be another manifestation of the same bug, or maybe a new bug (perhaps related toMC-526"Worlds will not delete").Not only does a hardcore world not delete with the hardcore death screen deletion button (
MC-30646), but additionally even after an apparently successful manual deletion on the world selection screen, it can still appear.Steps to reproduce:
1. create singleplayer hardcore world.
2. Die in your hardcore world
3. Choose "delete" on the death screen (not "spectate").
4. Get dropped back to title screen.
5. Choose singleplayer and view list of worlds. Observe that the hardcore world is not deleted, as perMC-30646.
6. Highlight hardcore world and choose delete.
7. On confirmation screen ("forever is a long time!"), confirm deletion.
8. Get dropped back to singleplayer world list. Observe that hardcore world is not on the list, indicating (apparently) that it was deleted successfully.
9. Hit escape.Expected result: go to title screen. Hardcore world remains deleted.
Actual result: get kicked back into your hardcore world, facing once again the choice to delete or spectate. The first time I arrived here, I chose to spectate and my world was full of chunks that wouldn't load, and the game crashed with a memory overflow shortly, indicating maybe some part of the deletion was successful. On subsequent attempts, spectator mode worked fine, with no crashes, in the supposedly deleted world.
While testing
MC-30646"Hardcore game is not deleted" I found what may be another manifestation of the same bug, or maybe a new bug (perhaps related toMC-526"Worlds will not delete").Not only does a hardcore world not delete with the hardcore death screen deletion button (
MC-30646), but additionally even after an apparently successful manual deletion on the world selection screen, it can still appear.Steps to reproduce:
1. create singleplayer hardcore world.
2. Die in your hardcore world
3. Choose "delete" on the death screen (not "spectate").
4. Get dropped back to title screen.
5. Choose singleplayer and view list of worlds. Observe that the hardcore world is not deleted, as perMC-30646.
6. Highlight hardcore world and choose delete.
7. On confirmation screen ("forever is a long time!"), confirm deletion.
8. Get dropped back to singleplayer world list. Observe that hardcore world is not on the list, indicating (apparently) that it was deleted successfully.
9. Hit escape.Expected result: go to title screen. Hardcore world remains deleted.
Actual result: get kicked back into your hardcore world, facing once again the choice to delete or spectate. The first time I arrived here, I chose to spectate and my world was full of chunks that wouldn't load, and the game crashed with a memory overflow shortly, indicating maybe some part of the deletion was successful. On subsequent attempts, spectator mode worked fine, with no crashes, in the supposedly deleted world.
While testing
MC-30646"Hardcore game is not deleted" I found what may be another manifestation of the same bug, or maybe a new bug (perhaps related toMC-526"Worlds will not delete").Not only does a hardcore world not delete with the hardcore death screen deletion button (
MC-30646), but additionally the world continues to run after choosing even after an apparently successful manual deletion on the world selection screen, it can still appear.Steps to reproduce:
1. create singleplayer hardcore world.
2. Die in your hardcore world
3. Choose "delete" on the death screen (not "spectate").
4. Get dropped back to title screen.
5. Choose singleplayer and view list of worlds. Observe that the hardcore world is not deleted, as perMC-30646.
6. Highlight hardcore world and choose delete.
7. On confirmation screen ("forever is a long time!"), confirm deletion.
8. Get dropped back to singleplayer world list. Observe that hardcore world is not on the list, indicating (apparently) that it was deleted successfully.
9. Hit escape.Expected result: go to title screen. Hardcore world remains deleted.
Actual result: get kicked back into your hardcore world, facing once again the choice to delete or spectate. The first time I arrived here, I chose to spectate and my world was full of chunks that wouldn't load, and the game crashed with a memory overflow shortly, indicating maybe some part of the deletion was successful. On subsequent attempts, spectator mode worked fine, with no crashes, in the supposedly deleted world.
While testing
MC-30646"Hardcore game is not deleted" I found what may be another manifestation of the same bug, or maybe a new bug (perhaps related toMC-526"Worlds will not delete").Not only does a hardcore world not delete with the hardcore death screen deletion button (
MC-30646), but additionally the world continues to runafter choosingeven afteranapparently successfulmanualdeletion on the worldselection screen, it can still appear.Steps to reproduce:
1. create singleplayer hardcore world.
2. Die in your hardcore world
3. Choose "delete" on the death screen (not "spectate").
4. Get dropped back to title screen.
5. Choose singleplayer and view list of worlds. Observe that the hardcore world is not deleted, as perMC-30646.
6. Highlight hardcore world and choose delete.
7. On confirmation screen ("forever is a long time!"), confirm deletion.
8. Get dropped back to singleplayer world list. Observe that hardcore world is not on the list, indicating (apparently) that it was deleted successfully.
9. Hit escape.Expected result: go to title screen. Hardcore world remains deleted.
Actual result: get kicked back into your hardcore world, facing once again the choice to delete or spectate. The first time I arrived here, I chose to spectate and my world was full of chunks that wouldn't load, and the game crashed with a memory overflow shortly, indicating maybe some part of the deletion was successful. On subsequent attempts, spectator mode worked fine, with no crashes, in the supposedly deleted world.
While testing
MC-30646"Hardcore game is not deleted" I found what may be another manifestation of the same bug, or maybe a new bug (perhaps related toMC-526"Worlds will not delete").Not only does a hardcore world not delete with the hardcore death screen deletion button (
MC-30646), but additionally the world continues to run behind the UI. You get dropped to the title screen, but can hear the game sounds and music. Can also see the world still running on a second deletion confirmation screen. And even after the apparently successful second deletion action, the world is still not deleted.Steps to reproduce:
1. create singleplayer hardcore world.
2. Die in your hardcore world
3. Choose "delete" on the death screen (not "spectate").
4. Get dropped back to title screen.
5. Choose singleplayer and view list of worlds. Observe that the hardcore world is not deleted, as perMC-30646.
6. Highlight hardcore world and choose delete.
7. On confirmation screen ("forever is a long time!"), confirm deletion.
8. Get dropped back to singleplayer world list. Observe that hardcore world is not on the list, indicating (apparently) that it was deleted successfully.
9. Hit escape.Expected result: go to title screen. Hardcore world remains deleted.
Actual result: get kicked back into your hardcore world, facing once again the choice to delete or spectate. The first time I arrived here, I chose to spectate and my world was full of chunks that wouldn't load, and the game crashed with a memory overflow shortly, indicating maybe some part of the deletion was successful. On subsequent attempts, spectator mode worked fine, with no crashes, in the supposedly deleted world.
after apparent successful second deletion, hardcore world still runs in background and is not deleted
While testing
MC-30646"Hardcore game is not deleted" I found what may be another manifestation of the same bug, or maybe a new bug (perhaps related toMC-526"Worlds will not delete").Not only does a hardcore world not delete with the hardcore death screen deletion button (
MC-30646), but additionally the world continues to run behind the UI. You get dropped to the title screen, but can hear the game sounds and music.Can also see the world still running on a second deletion confirmation screen. And even after the apparently successful second deletion action, the world is still not deleted.Steps to reproduce:
1. create singleplayer hardcore world.
2. Die in your hardcore world
3. Choose "delete" on the death screen (not "spectate").
4. Get dropped back to title screen.
5. Choose singleplayer and view list of worlds. Observe that the hardcore world is not deleted, as perMC-30646.
6. Highlight hardcore world and choose delete.
7. On confirmation screen ("forever is a long time!"), confirm deletion.
8. Get dropped back to singleplayer world list. Observe that hardcore world is not on the list, indicating (apparently) that it was deleted successfully.
9. Hit escape.Expected result: go to title screen. Hardcore world remains deleted.
Actual result: get kicked back into your hardcore world, facing once again the choice to delete or spectate. The first time I arrived here, I chose to spectate and my world was full of chunks that wouldn't load, and the game crashed with a memory overflow shortly, indicating maybe some part of the deletion was successful. On subsequent attempts, spectator mode worked fine, with no crashes, in the supposedly deleted world.
While testing
MC-30646"Hardcore game is not deleted" I found what may be another manifestation of the same bug, or maybe a new bug (perhaps related toMC-526"Worlds will not delete").Not only does a hardcore world not delete with the hardcore death screen deletion button (
MC-30646), but additionally the world continues to run behind the UI. You get dropped to the title screen, but can hear the game sounds and music. You can also see the world still running on a second deletion confirmation screen. And even after the apparently successful second deletion action, the world is still not deleted.Steps to reproduce:
1. create singleplayer hardcore world.
2. Die in your hardcore world
3. Choose "delete" on the death screen (not "spectate").
4. Get dropped back to title screen. Notice the game sounds continue, as if your world is still running.
5. Choose singleplayer and view list of worlds. Observe that the hardcore world is not deleted, as perMC-30646.
6. Highlight hardcore world and choose delete.
7. On confirmation screen ("forever is a long time!"), confirm deletion. Notice that you can see your world still running in the background here, as well as hear it. Instead of the expected dirt texture background.
8. Get dropped back to singleplayer world list. Observe that hardcore world is not on the list, indicating (apparently) that it was deleted successfully.
9. Hit escape.Expected result: go to title screen. Hardcore world remains deleted.
Actual result: get kicked back into your hardcore world, facing once again the choice to delete or spectate. The first time I arrived here, I chose to spectate and my world was full of chunks that wouldn't load, and the game crashed with a memory overflow shortly, indicating maybe some part of the deletion was successful. On subsequent attempts, spectator mode worked fine, with no crashes, in the supposedly deleted world.
after apparent successful second deletion, hardcore world still runs in background and is not deletedAfter apparent successful second deletion, hardcore world still runs in background and is not deleted
While testing
MC-30646"Hardcore game is not deleted" I found what may be another manifestation of the same bug, or maybe a new bug (perhaps related toMC-526"Worlds will not delete").Not only does a hardcore world not delete with the hardcore death screen deletion button (
MC-30646), but additionally the world continues to run behind the UI. You get dropped to the title screen, but can hear the game sounds and music. You can also see the world still running on a second deletion confirmation screen. And even after the apparently successful second deletion action, the world is still not deleted.Steps to reproduce:
1. create singleplayer hardcore world.
2. Die in your hardcore world
3. Choose "delete" on the death screen (not "spectate").
4. Get dropped back to title screen. Notice the game sounds continue, as if your world is still running.
5. Choose singleplayer and view list of worlds. Observe that the hardcore world is not deleted, as perMC-30646.
6. Highlight hardcore world and choose delete.
7. On confirmation screen ("forever is a long time!"), confirm deletion. Notice that you can see your world still running in the background here, as well as hear it. Instead of the expected dirt texture background.
8. Get dropped back to singleplayer world list. Observe that hardcore world is not on the list, indicating (apparently) that it was deleted successfully.
9. Hit escape.Expected result: go to title screen. Hardcore world remains deleted.
Actual result: get kicked back into your hardcore world, facing once again the choice to delete or spectate. The first time I arrived here, I chose to spectate and my world was full of chunks that wouldn't load, and the game crashed with a memory overflow shortly, indicating maybe some part of the deletion was successful. On subsequent attempts, spectator mode worked fine, with no crashes, in the supposedly deleted world. Hitting delete at this screen will repeat the loop without deleting the world.
The bug
While testing
MC-30646"Hardcore game is not deleted" I found what may be another manifestation of the same bug, or maybe a new bug (perhaps related toMC-526"Worlds will not delete").Not only does a hardcore world not delete with the hardcore death screen deletion button (
MC-30646), but additionally the world continues to run behind the UI. You get dropped to the title screen, but can hear the game sounds and music. You can also see the world still running on a second deletion confirmation screen. And even after the apparently successful second deletion action, the world is still not deleted.How to reproduce
- Create singleplayer hardcore world
- Die in your hardcore world
- Choose "Delete world" on the death screen (not "Spectate world")
- Get dropped back to title screen
→ Notice the game sounds continue, as if your world is still running- Choose singleplayer and view list of worlds
→ Observe that the hardcore world is not deleted, as perMC-30646- Highlight hardcore world and choose delete
- On confirmation screen ("forever is a long time!"), confirm deletion
→ Notice that you can see your world still running in the background here, as well as hear it. Instead of the expected dirt texture background- Get dropped back to singleplayer world list
→ Observe that hardcore world is not on the list, indicating (apparently) that it was deleted successfully.- Hit escape
Expected result
Go to title screen. Hardcore world remains deleted.
Actual result
Get kicked back into your hardcore world, facing once again thechoice to delete or spectate. The first time I arrived here, I chose to spectate and my world was full of chunks that wouldn't load, andthegamecrashed with a memory overflow shortly, indicating maybe some part of the deletion was successful. On subsequent attempts, spectator mode worked fine, with no crashes, in the supposedly deleted world. Hitting delete at this screen will repeat the loop without deleting the world.The bug
While testing
MC-30646"Hardcore game is not deleted" I found what may be another manifestation of the same bug, or maybe a new bug (perhaps related toMC-526"Worlds will not delete").Not only does a hardcore world not delete with the hardcore death screen deletion button (
MC-30646), but additionally the world continues to run behind the UI. You get dropped to the title screen, but can hear the game sounds and music. You can also see the world still running on a second deletion confirmation screen. And even after the apparently successful second deletion action, the world is still not deleted.How to reproduce
- Create singleplayer hardcore world
- Die in your hardcore world
- Choose "Delete world" on the death screen (not "Spectate world")
- Get dropped back to title screen
→ Notice the game sounds continue, as if your world is still running- Choose singleplayer and view list of worlds
→ Observe that the hardcore world is not deleted, as perMC-30646- Highlight hardcore world and choose delete
- On confirmation screen ("forever is a long time!"), confirm deletion
→ Notice that you can see your world still running in the background here, as well as hear it. Instead of the expected dirt texture background- Get dropped back to singleplayer world list
→ Observe that hardcore world is not on the list, indicating (apparently) that it was deleted successfully.- Hit escape (don't click the cancel button with mouse cursor)
Expected result
Go to title screen. Hardcore world remains deleted.
Actual result
Get kicked back into your hardcore world, facing once again the choice to delete or spectate. The first time I arrived here, I chose to spectate and my world was full of chunks that wouldn't load, and the game crashed with a memory overflow shortly, indicating maybe some part of the deletion was successful. On subsequent attempts, spectator mode worked fine, with no crashes, in the supposedly deleted world. Hitting delete at this screen will repeat the loop without deleting the world.
Note that hitting the escape key on the world select screen should probably behave the same as clicking the cancel button. That they behave differently may be another bug.
In order to begin a Minecraft instance, the launcher needs to be able download the jar files. Single stack IPv6 hosts cannot download those files from AWS since s3.amazonaws.com is not reachable over IPv6. However Amazon now supports IPv6 on S3 instances, since August 2016 ( [see blog post] ( https://aws.amazon.com/blogs/aws/now-available-ipv6-support-for-amazon-s3/ )], but the customer has to switch an IPv6 enabled endpoint like https://BUCKET.s3.dualstack.REGION.amazonaws.com or https://s3.dualstack.REGION.amazonaws.com/BUCKET
In order to begin a Minecraft instance, the launcher needs to be able download the jar files. Single stack IPv6 hosts cannot download those files from AWS since s3.amazonaws.com is not reachable over IPv6. However Amazon now supports IPv6 on S3 instances, since August 2016 ([see blog post](https://aws.amazon.com/blogs/aws/now-available-ipv6-support-for-amazon-s3/)
], but the customer has to switch an IPv6 enabled endpoint like https://BUCKET.s3.dualstack.REGION.amazonaws.com or https://s3.dualstack.REGION.amazonaws.com/BUCKETIn order to begin a Minecraft instance, the launcher needs to be able download the jar files. Single stack IPv6 hosts cannot download those files from AWS since s3.amazonaws.com is not reachable over IPv6. However Amazon now supports IPv6 on S3 instances, since August 2016 (see blog post at https://aws.amazon.com/blogs/aws/now-available-ipv6-support-for-amazon-s3/), but the customer has to switch an IPv6 enabled endpoint like https://BUCKET.s3.dualstack.REGION.amazonaws.com or https://s3.dualstack.REGION.amazonaws.com/BUCKET
Bug
MC-3776(IPv6 Does Not Work) is marked as fixed, so I went to test out Minecraft between two IPv6-only hosts. While it is possible to connect to another multiplayer session over IPv6 by entering the IPv6 address manually in the "server address" box of the "direct connect" UI screen (you have to remember to enclose the IPv6 address in square brackets so the port number can be distinguished from the IP address segments delimited by colons (what are these called? IPv4 called the octets, since they were 8bits. So hexidectets for IPv6?)).But IPv4 multiplayer servers on your LAN show up automatically under your list of multiplayer servers, so the kids can connect without manually entering IP addresses. This functionality should also work with IPv6.
Note that while it is possible to play multiplayer over IPv6, you still have to be dual stack, because IPv4 is required to download the jar files (https://bugs.mojang.com/browse/MCL-2627 Launcher will not download game over IPv6) and to authenticate to Mojang
This may be a form of MC-98598
Bug
MC-3776(IPv6 Does Not Work) is marked as fixed, so I went to test out Minecraft between two IPv6-only hosts. While it is possible to connect to another multiplayer session over IPv6 by entering the IPv6 address manually in the "server address" box of the "direct connect" UI screen (you have to remember to enclose the IPv6 address in square brackets so the port number can be distinguished from the IP address segments delimited by colons (what are these called? IPv4 called the octets, since they were 8bits. So hexidectets for IPv6?)).But IPv4 multiplayer servers on your LAN show up automatically under your list of multiplayer servers, so the kids can connect without manually entering IP addresses. This functionality should also work with IPv6.
Note that while it is possible to play multiplayer over IPv6, you still have to be dual stack, because IPv4 is required to download the jar files (https://bugs.mojang.com/browse/MCL-2627 Launcher will not download game over IPv6) and to authenticate to Mojang
This may be a
formof MC-98598Bug
MC-3776(IPv6 Does Not Work) is marked as fixed, so I went to test out Minecraft between two IPv6-only hosts. While it is possible to connect to another multiplayer session over IPv6 by entering the IPv6 address manually in the "server address" box of the "direct connect" UI screen (you have to remember to enclose the IPv6 address in square brackets so the port number can be distinguished from the IP address segments delimited by colons (what are these called? IPv4 called the octets, since they were 8bits. So hexidectets for IPv6?)).But IPv4 multiplayer servers on your LAN show up automatically under your list of multiplayer servers, so the kids can connect without manually entering IP addresses. This functionality should also work with IPv6.
Note that while it is possible to play multiplayer over IPv6, you still have to be dual stack, because IPv4 is required to download the jar files (https://bugs.mojang.com/browse/MCL-2627 Launcher will not download game over IPv6) and to authenticate to Mojang
This may be a manifestation or consequence of MC-98598 "LAN List does not populate reliably"
Bug
MC-3776(IPv6 Does Not Work) is marked as fixed, so I went to test out Minecraft between two IPv6-only hosts. While it is possible to connect to another multiplayer session over IPv6 by entering the IPv6 address manually in the "server address" box of the "direct connect" UI screen (you have to remember to enclose the IPv6 address in square brackets so the port number can be distinguished from the IP address segments delimited by colons (what are these called? IPv4 called the octets, since they were 8bits. So hexidectets for IPv6?)).But IPv4 multiplayer servers on your LAN show up automatically under your list of multiplayer servers, so the kids can connect without manually entering IP addresses. This functionality should also work with IPv6.
Note that while it is possible to play multiplayer over IPv6, you still have to be dual stack, because IPv4 is required to download the jar files (https://bugs.mojang.com/browse/MCL-2627 Launcher will not download game over IPv6) and to authenticate to Mojang
This may be a manifestation or consequence of MC-98598 "LAN List does not populate reliably"
Bug
MC-3776(IPv6 Does Not Work) is marked as fixed, so I went to test out Minecraft between two IPv6-only hosts. While it is possible to connect to another multiplayer session over IPv6 by entering the IPv6 address manually in the "server address" box of the "direct connect" UI screen (you have to remember to enclose the IPv6 address in square brackets so the port number can be distinguished from the IP address segments delimited by colons (what are these called? IPv4 called the octets, since they were 8bits. So hexidectets for IPv6? Ed: sources suggest "hextet", "hexadectet", "hexadecatet", "quibble", "quartet", or "piece")).But IPv4 multiplayer servers on your LAN show up automatically under your list of multiplayer servers, so the kids can connect without manually entering IP addresses. This functionality should also work with IPv6.
Note that while it is possible to play multiplayer over IPv6, you still have to be dual stack, because IPv4 is required to download the jar files (https://bugs.mojang.com/browse/MCL-2627 Launcher will not download game over IPv6) and to authenticate to Mojang
This may be a manifestation or consequence of MC-98598 "LAN List does not populate reliably"
Bug
MC-3776(IPv6 Does Not Work) is marked as fixed, so I went to test out Minecraft between two IPv6-only hosts. While it is possible to connect to another multiplayer session over IPv6 by entering the IPv6 address manually in the "server address" box of the "direct connect" UI screen (you have to remember to enclose the IPv6 address in square brackets so the port number can be distinguished from the IP address segments delimited by colons (what are these called? IPv4 called the octets, since they were 8bits. So hexidectets for IPv6? Ed: sources suggest "hextet", "hexadectet", "hexadecatet", "quibble", "quartet", or "piece")).But IPv4 multiplayer servers on your LAN show up automatically under your list of multiplayer servers, so the kids can connect without manually entering IP addresses. This functionality should also work with IPv6.
Note that while it is possible to play multiplayer over IPv6, you still have to be dual stack, because IPv4 is required to download the jar files (
MCL-2627Launcher will not download game over IPv6) and to authenticate to MojangThis may be a manifestation or consequence of MC-98598 "LAN List does not populate reliably"
Steps to reproduce
#On server machine, turn off IPv4 (eg on MacOS, go to System Preferences -> Network -> Advanced -> TCP/IP -> Configure IPv4 = Off), but ensure that IPv6 is enabled and addressable.
#On client machine, turn off IPv4 as well, and IPv6 is enabled. Both hosts are now IPv6-only single stack hosts.
#On server machine, launch Minecraft session, enter a Minecraft world, hit escape to pause, and choose "Open to LAN" -> "Start LAN World"
#On client machine, choose "Multiplayer" from the title screenExpected results
#Server machine session is seen at the bottom "local network" section of the "Play Multiplayer" server list
→ Note that if the session does show up, you might be able to connect at a low level, but you wouldn't be able to authenticate on an IPv6-only host, so you would not successfully join the session untilWEB-197is fixed. This report is only about populating LAN list, not connecting/authenticating.Actual results
#Server session is not seen
Bug
MC-3776(IPv6 Does Not Work) is marked as fixed, so I went to test out Minecraft between two IPv6-only hosts. While it is possible to connect to another multiplayer session over IPv6 by entering the IPv6 address manually in the "server address" box of the "direct connect" UI screen (you have to remember to enclose the IPv6 address in square brackets so the port number can be distinguished from the IP address segments delimited by colons (what are these called? IPv4 called the octets, since they were 8bits. So hexidectets for IPv6? Ed: sources suggest "hextet", "hexadectet", "hexadecatet", "quibble", "quartet", or "piece")).But IPv4 multiplayer servers on your LAN show up automatically under your list of multiplayer servers, so the kids can connect without manually entering IP addresses. This functionality should also work with IPv6.
Note that while it is possible to play multiplayer over IPv6, you still have to be dual stack, because IPv4 is required to download the jar files (
MCL-2627Launcher will not download game over IPv6) and to authenticate to MojangThis may be a manifestation or consequence of MC-98598 "LAN List does not populate reliably"
Steps to reproduce
#On server machine, turn off IPv4 (eg on MacOS, go to System Preferences -> Network -> Advanced -> TCP/IP -> Configure IPv4 = Off), but ensure that IPv6 is enabled and addressable.
#On client machine, turn off IPv4 as well, and IPv6 is enabled. Both hosts are now IPv6-only single stack hosts.
#On server machine, launch Minecraft session, enter a Minecraft world, hit escape to pause, and choose "Open to LAN" -> "Start LAN World"
#On client machine, choose "Multiplayer" from the title screenExpected results
#Server machine session is seen at the bottom "local network" section of the "Play Multiplayer" server list
→ Note that if the session does show up, you might be able to connect at a low level, but you wouldn't be able to authenticate on an IPv6-only host, so you would not successfully join the session untilWEB-197is fixed. This report is only about populating LAN list, not connecting/authenticating.Actual results
#Server session is not seen
Bug
MC-3776(IPv6 Does Not Work) is marked as fixed, so I went to test out Minecraft between two IPv6-only hosts. While it is possible to connect to another multiplayer session over IPv6 by entering the IPv6 address manually in the "server address" box of the "direct connect" UI screen (you have to remember to enclose the IPv6 address in square brackets so the port number can be distinguished from the IP address segments delimited by colons (what are these called? IPv4 called the octets, since they were 8bits. So hexidectets for IPv6? Ed: sources suggest "hextet", "hexadectet", "hexadecatet", "quibble", "quartet", or "piece")).But IPv4 multiplayer servers on your LAN show up automatically under your list of multiplayer servers, so the kids can connect without manually entering IP addresses. This functionality should also work with IPv6.
Note that while it is possible to play multiplayer over IPv6, you still have to be dual stack, because IPv4 is required to download the jar files (
MCL-2627Launcher will not download game over IPv6) and to authenticate to MojangThis may be a manifestation or consequence of MC-98598 "LAN List does not populate reliably"
Steps to reproduce
- On server machine, turn off IPv4 (eg on MacOS, go to System Preferences -> Network -> Advanced -> TCP/IP -> Configure IPv4 = Off), but ensure that IPv6 is enabled and addressable.
- On client machine, turn off IPv4 as well, and IPv6 is enabled. Both hosts are now IPv6-only single stack hosts.
- On server machine, launch Minecraft session, enter a Minecraft world, hit escape to pause, and choose "Open to LAN" -> "Start LAN World"
- On client machine, choose "Multiplayer" from the title screen
Expected results
- Server machine session is seen at the bottom "local network" section of the "Play Multiplayer" server list
→ Note that if the session does show up, you might be able to connect at a low level, but you wouldn't be able to authenticate on an IPv6-only host, so you would not successfully join the session untilWEB-197is fixed. This report is only about populating LAN list, not connecting/authenticating.Actual results
- Server session is not seen
Bug
MC-3776(IPv6 Does Not Work) is marked as fixed, so I went to test out Minecraft between two IPv6-only hosts. While it is possible to connect to another multiplayer session over IPv6 by entering the IPv6 address manually in the "server address" box of the "direct connect" UI screen (you have to remember to enclose the IPv6 address in square brackets so the port number can be distinguished from the IP address segments delimited by colons (what are these called? IPv4 called the octets, since they were 8bits. So hexidectets for IPv6? Ed: sources suggest "hextet", "hexadectet", "hexadecatet", "quibble", "quartet", or "piece")).But IPv4 multiplayer servers on your LAN show up automatically under your list of multiplayer servers, so the kids can connect without manually entering IP addresses. This functionality should also work with IPv6.
Note that while it is possible to play multiplayer over IPv6, you still have to be dual stack, because IPv4 is required to download the jar files (
MCL-2627Launcher will not download game over IPv6) and to authenticate to MojangThis may be a manifestation or consequence of MC-98598 "LAN List does not populate reliably"
Steps to reproduce
- On server machine, turn off IPv4 (eg on MacOS, go to System Preferences -> Network -> Advanced -> TCP/IP -> Configure IPv4 = Off), but ensure that IPv6 is enabled and addressable.
- On client machine, turn off IPv4 as well, and IPv6 is enabled. Both hosts are now IPv6-only single stack hosts.
- On server machine, launch Minecraft session, enter a Minecraft world, hit escape to pause, and choose "Open to LAN" -> "Start LAN World"
- On client machine, choose "Multiplayer" from the title screen
Expected results
- Server machine session is seen at the bottom "local network" section of the "Play Multiplayer" server list
→ Note that if the session does show up, you might be able to connect at a low level, but you wouldn't be able to authenticate on an IPv6-only host, so you would not successfully join the session untilWEB-197is fixed. This report is only about populating LAN list, not connecting/authenticating.Actual results
- Server session is not seen
![[Mod] Neko](../../../data/avatars/users/92901.png){kind=small}
I haven't figured out how to get 100% reproducibility, but I see this bug in minecraft 1.8.8 and just saw it in current 1.9 snapshot 15w35e. Cost me a chorus flower.
This bug also applies to podzol, which is also not tillable. Also works as designed, I suppose.
Is there a bugreport for the LWJGL project for the changes necessary on their end? I didn't see anything on https://github.com/LWJGL/lwjgl3/issues
Confirmed for 15w46a
Confirmed for 15w46a
I would also like to see confirmation from Mojang that it is intended that mobs no longer spawn on pressure plates. The fix for
MC-64492seems to be trying to revert to previous spawning behavior, whereas not spawning on pressure plates is new behavior, and breaks many popular farm designs. Mojang can of course change the game any way necessary, including breaking mob farms, but let it at least be intentional?Confirmed for 15w47a
Confirm in 15w47a
Confirm in 15w47a
Confirm for 15w47a, launcher version 1.6.48 for Mac OS X. If I switch my computer to IPv6 only (turn off IPv4 in System Preferences) before launching the launcher, it cannot connect to server and launches me in "offline" mode. If I open the launcher and authenticate, then switch to IPv6-only, it tries to download the minecraft.jar but cannot
[11:34:59 INFO]: Queueing library & version downloads
{id='15w47a', updateTime=Wed Nov 18 10:53:41 EST 2015, releaseTime=Wed Nov 18 10:53:41 EST 2015, type=SNAPSHOT}[11:34:59 ERROR]: Couldn't get complete version info for PartialVersion
java.net.ConnectException: Network is unreachable
at java.net.PlainSocketImpl.socketConnect(Native Method) ~[?:1.8.0_60]
My guess is that the minecraft servers are just not connected to IPv6.
Confirm mobs not spawning on pressure plates in 15w47a
Confirm for 15w47a
Today (using 15w47a and launcher 1.6.48 for Mac OS X) I tried out Minecraft after switching two computers on my LAN to IPv6 only. In accordance with
MCL-2627, I was not able to download the jar files over IPv6, nor authenticate to Mojang over IPv6. So I reverted to IPv4, launched the launcher, downloaded the jar files, authenticated to Mojang, started Minecraft, and then switched them both to IPv6 only. On one, I started a world and "Opened to LAN". But the host did not show up in the multiplayer list on the other machine. So I entered the address manually in the "server address" box of the "Direct connect" multiplayer UI. I used square brackets to separate the IP address and port number like [1111:2222:3333:4444:5555:6666:7777:8888]:60505. With IPv6-only, I was not able to login, the message was "Failed to login: The authentication servers are currently down for maintenance". If I switch IPv4 back on, but direct connect to the IPv6 address, I am able to connect. If I turn off IPv4 after successfully joining a multiplayer session, I am able to remain in the session over IPv6.So in addition to
MCL-2627(unable to download jar files over IPv6) I see two more issues: the screen that scans for minecraft servers on the LAN is not checking IPv6 network, and the Mojang authentication servers are not accessible over IPv6. I don't fully understand the issue that was fixed in this bugreport (edit: on re-reading, I guess it was direct connect to an IPv6 address, which I did confirm), but until all three issues are resolved, it think it would be premature to say IPv6 works with Minecraft.I will enter a new bugreport for getting multiplayer sessions to show up on IPv6 LAN scans (edit: MC-92923). As for making the Mojang minecraft authentication servers accessible over IPv6 (edit:
WEB-197), should I also file a bug report for that? Since It doesn't relate to the game itself, it's more Mojang server infrastructure...How do you add a label to a bugreport? I want this to be in the IPv6 label https://bugs.mojang.com/browse/MC-2507?jql=labels%20%3D%20ipv6
This bugreport appears to be a duplicate of
MC-56782(Open to lan only listens on IPv4). I didn't find it because I was searching in the IPv6 label. Apologies for the duplication.But that bugreport was itself marked as a duplicate of
MC-3776(IPv6 Does Not Work). SinceMC-3776was recently resolved as fixed, but the game is still not listening for IPv6 multiplayer sessions, eitherMC-3776orMC-56782needs to be reopened. Or this one needs to be left open.@redstonehelper: thanks for the tip. I have filed two new bugreports, and edited my above comment to include links. I have since discovered that one is a duplicate, though the report it duplicates has been closed, perhaps improperly.
I have read that turning on IPv6 on a heavy traffic public server is risky; if you add an IPv6 address and an AAAA record with the same CNAME, then there is a risk that misconfigured hosts will try to connect to the IPv6 address and fail, leading to long load times, or no load at all, either way a bad user experience. It's why Google started out by turning on IPv6 only a little at a time, only for ISPs known to work with IPv6 (see [DNS whitelisting](https://en.wikipedia.org/wiki/IPv6_brokenness_and_DNS_whitelisting)). Then participated in those IPv6 day holidays a few years back. I believe many major internet hosts are now serving AAAA DNS queries to everyone, so it may be safe for Mojang to do so too, but I'm not a professional, so take these beliefs with a grain of salt.
The other option is to set a separate CNAME like ipv6.authserver.mojang.com or whatever, with only an AAAA record, no A record. The client can have an option to prefer one or the other, set by the user. This might be safer in the short run, but it's also more work, and in the long run we should be preparing all infrastructure to be dual stack.
I'm not very familiar with the various servers required for a minecraft session. I think in addition to the authentication server (authserver.mojang.com), there is the session server (sessionserver.mojang.com), and the skin server (???), as well as the main web portal minecraft.net, where you change your skin and username. Eventually one will want all four of them to be accessible over IPv6. Right now none of them has an AAAA DNS record.
Confirmed for 15w47a
Confirmed for 15w47a
Are the JAR files downloaded from S3 AWS hosting, as the URLs suggest? According to this serverfault question, as of September 2015, Amazon does not support IPv6, so there's little Mojang could do other than wait or switch providers.
@Torabi: Yes, any IPv6 provider today will give you a method of also accessing the IPv4-only internet. that method, for my particular provider, for now, at least, that method is an IPv4 connection, which are still available where I live. This is of course unusable by an IPv6-only host on my LAN.
Asia ran out of new IPv4 addresses in 2011, Europe ran out in 2012, and the US ran out this summer (2015). Some in the industry urge everyone to prepare for a near future where there are IPv6-only users, and for public services to transition to dual stack, so they can address all users, including IPv4-only users, IPv6 only users, and dual stack users.
Right now Amazon AWS (and hence also Mojang) can apparently only serve IPv4-only and dual stack users. Not IPv6-only users. If the belief is that there will never be IPv6-only users whose ISPs don't provide them some tunnel service to access the IPv4-only net, then I would agree that that reduces the immediate necessity to go dual stack. The need for Amazon and Mojang to switch to dual-stack is still somewhat hypothetical. I'll just point out that your proposed mitigating workaround (that IPv6 providers also provide a carrier-wide tunnel for IPv6-only users to access the IPv4-only net) is also hypothetical. My ISP offers IPv6 connectivity, but no provision for accessing the IPv4-only net from IPv6-only hosts (else I would not be filing this bugreport).
So the issue is still there, and the long term solution is dual stack IPv6 (and consider, for example, recent explosive growth of internet in China when deciding how far away this "long term" is).
@Torabi: Maybe I misunderstood you, and went a little off-topic. Sorry. Your point was that IPv6 providers will also provide some method of accessing IPv4-only net. I was skeptical, since my provider did no such thing, and then argued why we need to plan for IPv6-only users anyway.
But the original bugreport by Hugo mentions his provider has NAT64, which is exactly a translation mechanism to access IPv4-only net by IPv6-only users. It may be the case that Hugo's issue was the same as
MC-3776. The launcher won't use IPv6 because of the java.net.preferIPv4Stack property. But that was fixed in last week's snapshot, which may have also fixed Hugo's issue. (And if so, I apologize for giving a lecture on the general importance of IPv6, which is off-topic in a bugreport).If that is the case, then this should be closed as a duplicate, and I will file a new bugreport about the possibility of downloading JAR files via IPv6 by an IPv6-only user, which I believe cannot be acted upon since Mojang's hands are tied by Amazon. But still it may be useful to have a bugreport to track the issue. Or I may be incorrect about Mojang's or Amazon's options.
The redstone powering behavior was reverted in today's snapshot (15w47a). Does anyone know if "different fix" for this bug mentioned by Searge was also released?
Confirm for 15w50a
Confirm for 15w50a
Confirm for 15w50a
Yes, 15w50a, thanks.
Confirm for 15w50a
Are we sure that this is WAI, since the same issue was recently fixed for glass?
MC-35790Yeah, since the same issue was recently fixed for glass (
MC-35790), can we also re-confirm whether this is WAI for farmland (and the other transparent blocks at MC-91224)?Confirm for 15w50a.
Confirm for 15w50a.
gamemode 3 is spectator mode
Confirmed for 16w02a
Confirmed for 16w02a.
Confirmed for 16w02a
Confirmed for 16w02a
Confirmed for 16w02a.
Confirmed for 16w03a.
Confirmed for 16w03a.
Confirmed for 16w03a.
Confirmed for 16w03a.
Confirmed for 16w03a.
After my fullscreen Minecraft session froze in Win10, I am unable to alt-tab away from Minecraft or recover my system. CTRL-Alt-Delete doesn't pull up the task manager, and Alt-F4 has no effect. Does anyone have any other tips for killing the Minecraft session short of a hard reboot?
Edit: Nevermind. If you wait long enough (20 mins??), ctrl-alt-delete will kick in.
Confirmed for 16w03a
Confirmed for 16w03a.
I'm reproducing this bug more reliably now. You just have to stand right on the edge of the space where you are trying to place a block. If you're in just exactly the right place, when you place block, it makes the block placement sound, flashes for one instant, and then disappears. The block is then gone from your inventory. I've repeated it several times in 16w03a. This is an annoying bug that cost me a block of diamond ore when I was new to the game. I'd love to see it fixed. Which means also that I think this bug report should be reopened.
To reproduce it yourself, just put a block in your hand, try to place where you are standing, and very slowly walk backwards until you're right on the edge of blocking placement. If it places successfully, just walk backwards again and repeat. After the 3rd or 4th try, I am able to exhibit the bug. Sometimes if I stay right there, I can disappear 4 blocks in a row.
Do it in survival mode to see that the disappeared block is also gone from your inventory.
Upon more experimentation watching closely, it seems that when you do step back and successfully place a block, the missing blocks do get readded to your inventory. This makes the bug weirder but perhaps less detrimental to gameplay.
Confirmed for 16w04a.
Confirmed for 16w04a.
Confirmed for 16w04a.
Confirmed for 16w04a.
Confirmed for 16w04a. Made sure not to be in fullscreen this time. Windows is much better at ending the frozen program if you can click the X on the window chrome. Hope this bug gets fixed!
Confirmed for 16w04a. @Galaxy_2Alex, please reopen!
Confirmed for 16w04a.
Confirmed for 16w04a.
Confirmed mobs not spawning on pressure plates in 16w04a.
@redstonehelper. I'm sorry, but after searching several variations of "disappearing block" or "place block collision" and others, I did not find a duplicate of this bug. Several about switching inventory slots with number keys (all duplicating
MC-2912), some about chunk loading errors causing blocks to disappear. The title ofMC-62166("Breaking / placing / changing blocks has a delay to disappear / appear") seemed like it might encompass this, but the report was something else entirely. But I found nothing else for this issue, blocks disappearing because they were placed too close to the player's collision mask. Does the newer ticket have a very different title?Thanks redstonehelper. Yes, that looks like it is the same bug. Sorry for making you do the legwork. Not sure why I couldn't find that. I will put future comments on
MC-8471.Came here from
MC-44773. Can confirm this bug in 16w04a.@Oliver, are you sure about that? This bug was fixed in 1.9 snapshots. Also, what is DS Light and what does it have to do with Minecraft?
Confirmed for 16w05a.
Confirmed 16w05a.
Confirmed for 16w05a.
Confirmed for 16w05a.
Confirmed for 16w05a.
Confirmed for 16w05a.
Confirmed for 16w05a.
Confirmed for 16w05a.
Confirmed for 16w05a.
Confirmed 16w05b.
Confirmed 16w05b.
Confirmed 16w05b.
Confirmed 16w05b.
Confirmed 16w05b.
Confirmed 16w05b.
Confirmed for 16w05b.
Confirmed for 16w05b.
Confirmed for 16w05b.
Confirmed for 16w05b.
Confirmed 16w07a.
Confirmed 16w07a.
Confirmed 16w07a.
Confirmed 16w07a.
Confirmed in 1.9-pre1.
Confirm for 1.9-pre1
Confirm for 1.9-pre1
Confirm for 1.9-pre1
Thanks for pointing that out, Kumasasa. I'm kinda slow. But I've updated it to show 1.9-pre1 now.
Confirm for 1.9-pre1
Confirm for 1.9-pre1
Confirm for 1.9-pre1
Confirm for 1.9-pre1
@Marcono, if I'm reading it right, this code change would just not spawn anything, rather than changing to a sociable zombie pigman?
Seems fixed in 0.14 on my iphone5 running iOS 9.2, with MadCatz CTRLi
Confirm for 1.9-pre2
Confirm for 1.9-pre2
Confirm for 1.9-pre2
Confirm for 1.9-pre2
Oh good. That sounds like expected behavior. I guess that's what the EntityZombie.getClass() call is about. Perfect, thanks for explaining!
In other news, confirmed for 1.9-pre2
Confirm for 1.9-pre2
Confirm for 1.9-pre2
Confirm for 1.9-pre3
Confirm for 1.9-pre3
Confirm for 1.9-pre3
Confirm for 1.9-pre3
Confirm for 1.9-pre3
Confirm for 1.9-pre3
Confirm for 1.9-pre3
Confirm for 1.9-pre3
Is this a new manifestation of the same underlying issue of (fixed)
MC-185?Sometimes when this bug occurs for me (in 1.8.x, not 1.9 snapshots where it's fixed), if the title screen flicker is slow enough (which it often is), I click to enter the world a second time. Then the world loads, but something occurs so that my player slowly sinks through the floor (and no amount of switching gamemode to survival helps) and falls into the void and dies. This is a different behavior than is reported at
MC-48211, where they say entering the same world twice just causes the game to crash.I wonder whether the newly closed bug
MC-92079in 1.9-pre3 is the same or a related underlying bug.Confirm for 1.9-pre4
Confirm for 1.9-pre4
Confirm for 1.9-pre4
Confirm for 1.9-pre4
Confirm for 1.9-pre4
Confirm for 1.9-pre4
Confirm for 1.9-pre4
Confirm for 1.9
Confirm for 1.9
Confirm for 1.9
Confirm for 1.9
Confirm for 1.9 Edit: redstonehelper has already marked it, oops
Is this the bug that makes the zombie pigmen freeze in mid-air while falling in snocrash's pigman farm? If so, then it's still present in 1.9.
So is this a duplicate (or otherwise related to)
MC-17630? I thought that was the bug tracking the seizing up of zombie pigmen in snocrash's farm (and zombies more generally) in 1.9.I will add some of your details to the
MC-96521, to increase its searchability cross-section. Thank you for your effort.Saw today's release fixing
MC-100382, thought it might also fix this. But no, the zombie pigmans are still freezing in midair in 16w14aConfirm for 16w14a
Confirm for 16w14a. Wasn't this once marked as targetting fix for a 1.9 release?
Confirm for 16w14a
Confirm for 16w14a
Confirm for 16w14a
Confirm for 16w14a
Confirm for 16w14a
Confirm for 16w14a
I'm confused, because
MC-94554(Zombie Pigmen Anger = Lag+Server Crash) is marked as a duplicate of this bug. But another bugMC-17630(Zombie pathfinding to unreachable targets causes server lag), which appears to be the same issue, is not. For what it's worth,MC-17630is definitely not fixed in 16w14a: zombie pigmans are freezing in midair still. If that is somehow a duplicate of this bug, that one should be closed and this one reopened, but I may be confused as to how or whether these three bugs are related.The description of this bug is too vague for me to test, but
MC-94554which duplicates this bug (according to [Mod] redstonehelper) is easily verified to be still in 16w14a.So do you think my zombie pigmans freezing in midair is a different issue? There's a bug
MC-94554which it might be instead, but that one is closed as a dupe of something else.I don't know if it's useful to speculate on the bugtracker like this, but it's my impression that low-level stuff like modifier keybinding is handled not by minecraft, but by something lower in the stack. Like when we had a bug to improve Chinese keyboard input methods in Minecraft chat (
MC-2781), it turned out not to work with Macs (MC-91132), but according to comments there, this was something that had to be fixed by the LWJGL team. This issue could be similar. I know some of the Mojang team do use macs, so the assertion that they would fix it immediately is demonstrably false. It's possible that the fix is not that straightforward.Confirm for 16w15a
Confirm for 16w15a
Confirm for 16w15a
Confirm for 16w15a
Just got hit by this weird bug today. Two soundtracks are playing. If I pause the game, then one of the soundtracks stops, while the other continues.
Confirm for 16w15a.
Confirm for 16w15a
Confirm for 16w15a
Confirm for 1.9.4. I wonder whether a fix for this issue would also apply to leads. It'd be nice to use both nametags and leads on villagers. But maybe that would be a separate bug/feature request.
Confirm for 1.9.4
Confirm for 1.9.4
Confirm for 1.9.4
Confirm 1.9.4
Confirm 1.9.4
Confirm for 1.9.4
Confirm for 1.9.4
Confirm for 16w20a.
Confirm 16w20a.
Confirm 16w20a.
Confirm 16w20a
Confirm 16w20a.
Confirm 16w20a.
Confirm 16w20a.
@ilmango: this was once marked as WAI and closed, but then grum himself reopened the ticket.
Confirm 1.10.2
Confirm 1.10.2
Confirm for 1.10.2
Confirm 1.10.2
Confirm 1.10.2
Confirm that villagers can be named now, and the solution is not shift-right-click as expected, but just right-click, which means you cannot trade with a villager with a nametag in hand.
And still cannot attach leads to a villager. Is there a new ticket for that or?
Nametags on villagers were fixed (
MC-14525), but not leads. Since this ticket mentions leads explicitly, please reopen.Amazon enabled IPv6 on S3 instances in August 2016 (https://aws.amazon.com/blogs/aws/now-available-ipv6-support-for-amazon-s3/), and for EC2 hosts december 2016 (https://aws.amazon.com/blogs/aws/new-ipv6-support-for-ec2-instances-in-virtual-private-clouds/). Does this mean it will be possible to download jar files on an IPv6 single stack host?
confirm for 1.11
Confirm for 1.11
Confirm for 1.11
Confirm for 1.11
Confirm for 1.11
Confirm issue in 1.11
Related to
WEB-197andMCL-2627I went to test this today, but s3.amazonaws.com is not reachable over IPv6. According to the blog post at https://aws.amazon.com/blogs/aws/now-available-ipv6-support-for-amazon-s3/, the Amazon customer needs to switch over their S3 instances to the new endpoints that look like https://BUCKET.s3.dualstack.REGION.amazonaws.com or https://s3.dualstack.REGION.amazonaws.com/BUCKET. So Mojang will have to make that switch before progress can be made on this. Is this still a launcher issue or is it more of a web services issue? seems like the latter so I filed
WEB-632Oh right, thanks.
I'm not seeing this behavior in 17W43A, the new snapshot which updated to LWJGL 3. May be fixed?
Confirm for 17w50a
Confirm for 17w50a
Yes, the default skin issue does indeed seem to be fixed in 18w21a. Though for some reason I am not seeing LAN shared worlds in the multiplayer list, and had to direct connect. But that's another matter.
1.13pre2
I may be seeing the same issue. On the just-released latest launcher 2.1.1144. I'm on mac, so a crash looks a little different than the attached video. But I do have "keep launcher open while game runs" and "open output log" set to yes. Here is the Apple "Problem Report" dump
https://pastebin.com/L6F9UZps
I have been seeing this ever since the new launcher came out. And confirm still present in today's update. launcher 2.1.1144. I'm on macOS 10.13.5, 2016 MBP with no external monitor. But I do have "keep launcher open while game runs" and "open output log" set to yes. Here is the Apple "Problem Report" dump
https://pastebin.com/L6F9UZps
@Petr Only sometimes. Launched and exited 4 times successfully before crash on 5th. Seems to be more likely to happen if game session is longer.
Another one today https://pastebin.com/jcbvgFwx. version 1.13-pre4. launcher 2.1.1144. macos 10.13.5. Exited successfully with launcher remain running 5 times or so, before crash.
Confirm 1.13pre4. If you never stop sprinting through the water, you never stop the swimming animation, even after you leave the water.
My 18w31a world also seems fixed. If it's indeed not fixed as Kumasasa says, then maybe it's gotten more rare?
confirm for 18w31a
confirm for 18w31a
affects 18w31a
Like A. Mouse, my test was a 18w30b world exhibiting the bug frequently, loaded in 18w31b. Not a fresh 18w31b. Well also fixed in fresh 18w31b of course.
I think the services are listed at the mojang help page: https://help.mojang.com/customer/en/portal/articles/1452251-minecraft-java-edition-services
Ideally an IPv6 infrastructure change would address all six of these Mojang servers simultaneously, as well as switching over to IPv6 on Amazon Web Services for downloading JAR files, as per
WEB-632.On my macs, I can no longer reliably populate LAN multiplayer sessions, even if the host is not IPv6 only. I think that's MC-98598. The list also doesn't populate for IPv6-only hosts, but the discrepancy between "expected behavior" and "actual behavior" does not occur, so I cannot test this bug. Is MC-98598 a mac-only issue? Maybe this could be tested on windows boxes.