Moritz
- puchm
- puchm
- Europe/Stockholm
- Yes
- No
MC-82614
If I teleport a armor stand to a certain direction (Like /tp @e[type=ArmorStand,c=1]) It sometimes looks into the wrong direction.
Here's a video:
Also, that "message me on Twitter" thing is'nt true, I decided to upload a schematic. If you've loaded it you have to add some scoreboards:
/scoreboard objectives add legs dummy
/scoreboard objectives add speed dummy
/scoreboard objectives add direction dummyThen just place A Standing Banner (Color is not important) At Y=1 and a wool on top (green, yellow or orange) like you can see it at the beginning of the video. Last step is to place a armor Stand on the wool. Then it'll walk and you can (hopefully) see the bug.
If I teleport a armor stand to a certain direction (Like /tp @e[type=ArmorStand,c=1]) It sometimes looks into the wrong direction.
Here's a video: https://youtu.be/ZktELeeIpqI
Also, that "message me on Twitter" thing is'nt true, I decided to upload a schematic. If you've loaded it you have to add some scoreboards:
/scoreboard objectives add legs dummy
/scoreboard objectives add speed dummy
/scoreboard objectives add direction dummyThen just place A Standing Banner (Color is not important) At Y=1 and a wool on top (green, yellow or orange) like you can see it at the beginning of the video. Last step is to place a armor Stand on the wool. Then it'll walk and you can (hopefully) see the bug.
Thanks for fixing, puchm
If I teleport a armor stand to a certain direction (Like /tp @e[type=ArmorStand,c=1] ~0.1 ~ ~ 180 0) It sometimes looks into the wrong direction.
Here's a video: https://youtu.be/ZktELeeIpqI
Also, that "message me on Twitter" thing is'nt true, I decided to upload a schematic. If you've loaded it you have to add some scoreboards:
/scoreboard objectives add legs dummy
/scoreboard objectives add speed dummy
/scoreboard objectives add direction dummyThen just place A Standing Banner (Color is not important) At Y=1 and a wool on top (green, yellow or orange) like you can see it at the beginning of the video. Last step is to place a armor Stand on the wool. Then it'll walk and you can (hopefully) see the bug.
Thanks for fixing, puchm
Hey! I have a pretty weird bug for you. A minecart with a entity in it starts moving randomly, even if it is on a powered rail. I expected it to stop on the powered rail. How to recreate it and everything else can be seen in this video:
https://youtu.be/uo2OMuzX6jwThank you for fixing! ~puchm
Hey! I have a pretty weird bug for you. A minecart with a entity in it starts moving randomly, even if it is on a powered rail. I expected it to stop on the powered rail. How to recreate it and everything else can be seen in this video:
https://youtu.be/Qjmod2EeMbgThank you for fixing! ~puchm
Hey! I have a pretty weird bug for you. A minecart with a entity in it starts moving randomly, even if it is on a powered rail. I expected it to stop on the powered rail. How to recreate it and everything else can be seen in this video:
https://youtu.be/Qjmod2EeMbg (YouTube is having some issues, might take a bit.)Thank you for fixing! ~puchm
Hey! I have a pretty weird bug for you. A minecart with a entity in it starts moving randomly, even if it is on a powered rail. I expected it to stop on the powered rail. How to recreate it and everything else can be seen in this video:
https://youtu.be/Qjmod2EeMbg (YouTube is having some issues, might take a bit.)Thank you for fixing! ~puchm
Moritz: If you can recreate this reliably please create a new ticket for this.
Nice Data Moritz!
I don't think this issue is disputed. It's been marked as plausible, and assigned to Hendrik who we know is dealing with the world generation issues - of which they have been revising every snapshot. They also said that the change in world height had caused a lot of deep issues in the generation - so much so it contributed to splitting the releases in two. The fact the issue persists in a lot of the snapshots suggests to me, some deep rewriting of old code is being undertaken probably caused by world height changes.
Besides all you have to do is create a few worlds in 1.16 and then in the snapshots and enter spectator mode and fly around in the ravines. You'll notice visible iron is often absent entirely in ravines in the snapshots and you'll only find a few blocks in the deep dark.
However - What I'd like to add this thread is that this issue is also in 21w18a, the latest snapshot, but hasn't been marked as so yet.
It works, if I'm not teleporting very frequently. And yes, it's the same as MC-76463 . I was checking, if there's the same bug reported already, but I couldn't find anything! Thanks for helping!
What does that mean in English?
I had the same issue. I created a Amplified world in 15w51b (Seed:318041875063143073). (I've got Windows 10 and Java 8 Update 45)
And please reopen the bug...
I created the world, teleported to 900 64 4300 (Thats the place where one ocean monument is). Then I saved the world, Logged in it again and everything was gone but there was still Guardians spawning. (So maybe it has something to do with
MC-88989;MC-70466;MC-70582orMC-70582Thx for fixingHey! I just wanted to tell You, that I dont think that that is a duplicate of
MC-64836!!! Because that bug is about path finding ans This one is about Minecarts which are not stopping. I might be wrong but I dont think so.I told all my Friends to vote for This. Also I told many creators of big Iron farms which Are using This principle to vote and tell their Friends. And yesterday I tweeted it to Searge. That's everything I can so and what You could do too.
I know. But I Want it to get fixed for 1.9
Hello, this happens in Vanilla as well. When killing a Redstone Torch, which was dropped on the ground, it does indeed show "Killed item.tile.notGate". However, I don't think this is a bug.
~puchm
I found an easier setup to reproduce this. When pressing the buttons, one Minecart is stopped by another minecart when they meet each other for the second time. This is the case in Minecraft 1.12.2, Java 8 Update 161 (although I don't think the Java version affects this), running Windows 10.
UPDATE: This is still the case in 18w14b.
I tried it in a few different version and can confirm that this is also happening in the following versions:
I didn't try any prior versions, but I guess this has been in the game for quite some time.
That's good to know. If mango says that changing this would break existing contraptions then I believe him
Curious why it is like this though...
Can someone mark this as resolved?
I didn't analyze it but it feels like this is still the case in 21w17a when using the data pack for the new generation. I've been mining on Y=32 and copper is 4-5 times more common than iron.
Edit: I have now analyzed it. I was in fact mining on the wrong layers. On Y=32 copper is more than twice as common as iron and the higher it gets the more extreme it gets, e.g. around Y=40 copper is 4-5 times as common.
The distribution seems to be accurate to the graphic from 21w10a: link
Here are the results of my analysis. I measured in blocks of 10 y coordinates in a 100x100 region with few caves. The numbers are the total numbers from each corresponding 100x10x100 area:
Coal
>60 1055
>50 1305
>40 959
>30 757
>20 688
>10 231
>0 41
.. 0
Iron
>60 0
>50 84
>40 135
>30 228
>20 303
>10 422
>0 300
>-10 201
>-20 96
>-30 12
>-40 56
>-50 84
>-60 90
>-70 9
Copper
>60 169
>50 637
>40 603
>30 637
>20 570
>10 424
>0 370
>-10 77
.. 0
Gold
>60 0
>50 0
>40 0
>30 3
>20 25
>10 96
>0 105
>-10 148
>-20 208
>-30 197
>-40 145
>-50 93
>-60 20
>-70 1
Lapis
>60 14
>50 29
>40 47
>30 66
>20 65
>10 106
>0 138
>-10 153
>-20 140
>-30 45
>-40 53
>-50 57
>-60 35
>-70 1
Redstone
>60 0
>50 0
>40 0
>30 0
>20 0
>10 0
>0 75
>-10 122
>-20 80
>-30 96
>-40 272
>-50 368
>-60 422
>-70 66
Diamond
>10 4
>0 11
>-10 31
>-20 23
>-30 53
>-40 61
>-50 44
>-60 50
>-70 4
I looked at the pie chart that appears when pressing shift + F3 and it appears that the section "scheduledExecutables" grows every time you cross a border. Especially when you walk back and forth a lot it gets to >30% really fast and it takes several minutes to get back down.
Maybe that might help.
I believe this happened because my SSH session ended while I was in the server console. Everything has been working fine since I detached from the console before disconnecting.
So I think this can be closed.
The only case I have been able to reliably observe this bug is when I restart my server while they are in their nests. Bees outside of nests don't seem to despawn so as mentioned before it might have something to do with nests/hives not getting saved correctly. I tested this in 1.18.
On another note: If you have an enclosure with one-block walls and ceiling, lightning seems to be able to kill bees through the ceiling/walls so I would put a lightning rod somewhere a few blocks away. This is something that could also lead to bees disappearing (intentionally I suppose) but they definitely also disappear without any reason.
I have a feeling this might have something to do with the client maybe not being vanilla?
I could not reproduce the issue but found a similar issue with the Fabric client (see screenshots with red / yellow glass).
In vanilla you can see all of the borders where different kinds of stained glass touch. Fabric (or some mod I have installed - not sure) doesn't display these except on chunk borders.
In that case this would not be an issue with vanilla Minecraft but with Fabric or one of the mods I am using. @Mark Morosan can you confirm whether you are using vanilla or another client?
I think this might be an issue with Fabric. Please confirm that this was tried in vanilla without Fabric. See this issue: https://github.com/FabricMC/fabric/issues/2836