Anomie X
- anomie x
- anomie x
- America/New_York
- Yes
- No
MC-56653![[Mojang] Grum (Erik Broes)](../../../data/assets/gravatar/grum.png){kind=small}
![[Mojang] Nathan Adams](../../../data/assets/gravatar/dinnerbone.png){kind=small}
![[Mojang] Maxime Lebrot](../../../data/avatars/users/18941.svg){kind=small}
![[Mojang] Searge (Michael Stoyke)](../../../data/assets/gravatar/searge.png){kind=small}
If these are intended changes, that's fine. But filing a bug to be sure.
- Can no longer use Redstone to turn a tier-II potion into an extended potion (or to revert to base if no extended version exists).
- Can no longer use Glowstone to turn an extended potion into a tier-II potion (or to revert to base if no tier-II version exists).
- Can no longer make Potions of Weakness from Mundane or Thick potions.
- Can no longer make Potions of Weakness by adding fermented spider eye to Strength or Regeneration potions.
- Can no longer place splash potions into a brewing stand (but they work fine if they're already in there).
If these are intended changes, that's fine. But filing a bug to be sure.
- Can no longer use Redstone to turn a tier-II potion into an extended potion (or to revert to base if no extended version exists).
- Can no longer use Glowstone to turn an extended potion into a tier-II potion (or to revert to base if no tier-II version exists).
- Can no longer make Potions of Weakness from Mundane or Thick potions.
- Can no longer make Potions of Weakness by adding fermented spider eye to Strength or Regeneration potions.
- Can no longer place splash potions into a brewing stand (but they work fine if they're already in there).
- Can no longer brew potion of water breathing (from
MC-84073)
If these are intended changes, that's fine. But filing a bug to be sure.
- Can no longer use Redstone to turn a tier-II potion into an extended potion (or to revert to base if no extended version exists).
- Can no longer use Glowstone to turn an extended potion into a tier-II potion (or to revert to base if no tier-II version exists).
- Can no longer make Potions of Weakness from Mundane or Thick potions.
- Can no longer make Potions of Weakness by adding fermented spider eye to Strength or Regeneration potions.
- Can no longer place splash potions into a brewing stand (but they work fine if they're already in there).
If these are intended changes, that's fine. But filing a bug to be sure.
- Can no longer use Redstone to turn a tier-II potion into an extended potion (or to revert to base if no extended version exists).
- Can no longer use Glowstone to turn an extended potion into a tier-II potion (or to revert to base if no tier-II version exists).
- Can no longer make Potions of Weakness from Mundane or Thick potions.
- Can no longer make Potions of Weakness by adding fermented spider eye to Strength or Regeneration potions.
Can no longer place splash potions into a brewing stand (but they work fine if they're already in there).(seems to have been resolved asMC-85865)
Placing an awkward potion in the bottom slot and a pufferfish in the top results in a water bottle rather than a potion of water breathing.
The same happens trying to add redstone to a potion of fire resistance.
The cause might be that the strings are mismatched between obfuscated classes 'acd' and 'acf': "water_breathing" and "long_fire_refistance" versus "breathing_water" and "long_fire_resistance".
Brewing a potion of water breathingdoesn't workPotions of water breathing, extended fire resistance bugged
The code for the new "damaged armor doesn't protect as well" feature seems broken. In particular, the code looks something like this:
int protection = ((ItemArmor)itemStack.getItem()).protectionAmount; int durability = itemStack.getDurability(); int damage = itemStack.getDamage(); if ( damage > durability / 2 ) { protection = Math.ceiling( (float)(durability - damage) / (float)(durability / 2) ); }The code seems pretty clear that it's trying to gradually decrease the protection, full protection until half-damaged then decreasing linearly to no protection when fully-damaged. But as it is it instead sets the protection to 1 as soon as the armor hits half-damaged. To calculate that correctly, it should be
protection = Math.ceiling( protection * (float)(durability - damage) / (float)(durability / 2) );(Mods: If "set to 1 at half-damaged" were the intended behavior, it would just do that as "protection = 1" instead of the formula shown).
The code for the new "damaged armor doesn't protect as well" feature seems broken. In particular, the code looks something like this:
int protection = ((ItemArmor)itemStack.getItem()).protectionAmount; int durability = itemStack.getDurability(); int damage = itemStack.getDamage(); if ( damage > durability / 2 ) { protection = Math.ceiling( (float)(durability - damage) / (float)(durability / 2) ); }The code seems pretty clear that it's trying to gradually decrease the protection, full protection until half-damaged then decreasing linearly to no protection when fully-damaged. But as it is it instead sets the protection to 1 as soon as the armor hits half-damaged. To calculate that correctly, it should be
protection = Math.ceiling( (float)protection * (float)(durability - damage) / (float)(durability / 2) );(Mods: If "set to 1 at half-damaged" were the intended behavior, it would just do that as "protection = 1" instead of the formula shown).
With the change to loot tables, the code for having mobs drop worn armor or held items is no longer called.
Easy enough to test, just summon a mob with equipment and set the corresponding HandDropChances or ArmorDropChances to 1.0. Or put a saddle on a pig or horse.
With the change to loot tables, the code for having mobs drop worn armor or held items is no longer called.
Easy enough to test, just summon a mob with equipment and set the corresponding HandDropChances or ArmorDropChances to 1.0. Or put a saddle on a pig
or horse.
This was
MC-86283, but it was too confusing for Kusama so he closed it as invalid.Only some explosions can be blocked: for example, creeper explosions and TNT set by other players is blockable, but TNT ignited by redstone cannot be blocked. Explosions from TNT set by the player himself also cannot be blocked, but that's due to
MC-92017rather than this bug.This can be tested easily enough by seeing if the shield loses durability or not from the explosion.
This was
MC-86283, but it was too confusing for Kumasasa so he closed it as invalid.Only some explosions can be blocked: for example, creeper explosions and TNT set by other players is blockable, but TNT ignited by redstone cannot be blocked. Explosions from TNT set by the player himself also cannot be blocked, but that's due to
MC-92017rather than this bug.This can be tested easily enough by seeing if the shield loses durability or not from the explosion.
This was
MC-86283, but it was too confusing for Kusama so he closed it as invalid.The "direction" of the damage is treated as coming from wherever the source entity is now, not where the attack was fired from. This is most (and only?) visible with TNT explosions: if Player A sets TNT and Player B is between A and the TNT, B can only block the explosion by turning his back on the TNT and facing towards A! And a player cannot block TNT he himself set, since the source is the player himself and so has no "direction" relative to that player to be tested.
This can be tested easily enough by seeing if the shield loses durability or not from the explosion.
This was
MC-86283, but it was too confusing for Kumasasa so he closed it as invalid.The "direction" of the damage is treated as coming from wherever the source entity is now, not where the attack was fired from. This is most (and only?) visible with TNT explosions: if Player A sets TNT and Player B is between A and the TNT, B can only block the explosion by turning his back on the TNT and facing towards A! And a player cannot block TNT he himself set, since the source is the player himself and so has no "direction" relative to that player to be tested.
This can be tested easily enough by seeing if the shield loses durability or not from the explosion.
This was
MC-86283, but it was too confusing for Kusama so he closed it as invalid.Shields suffer from a sort of gimbal lock: if a player faces straight down, the shield doesn't block any direction. Straight up seems to work ok in my testing, probably due to rounding error of some sort making the facing-vector still have a slight horizontal component.
Easy test: summon a trapped skeleton and stand above and slightly to the side. Arrows are blocked when facing 89.9 down (or at -89.9 almost straight up), but at 90.0 you'll be hit.
This was
MC-86283, but it was too confusing for Kumasasa so he closed it as invalid.Shields suffer from a sort of gimbal lock: if a player faces straight down, the shield doesn't block any direction. Straight up seems to work ok in my testing, probably due to rounding error of some sort making the facing-vector still have a slight horizontal component.
Easy test: summon a trapped skeleton and stand above and slightly to the side. Arrows are blocked when facing 89.9 down (or at -89.9 almost straight up), but at 90.0 you'll be hit.
Snowballs and eggs go through glass, stairs, and other solid non-opaque blocks
Snowballs and eggs go through glass, stairs, and other solid non-opaque blocksProjectiles go through glass, stairs, and other solid non-opaque blocks
Build a wall of glass and throw snowballs at it: you'll clearly see they go right through as if the wall weren't there.
Same happens with eggs, ender pearls, bottles o enchanting, and thrown potions.
Projectiles go through glass, stairs, and other solid non-opaque blocksThrown projectiles go through glass, stairs, and other solid non-opaque blocks
To reproduce:
- Generate a world in a version before 1.9, and kill the dragon so that the exit portal is generated somewhere other than at (0,0).
- Load the world in 1.10.1 or later.
- Place the end crystals. See that the respawning process does not start.
It works fine in 1.10.
Further, as each crystal is placed, the following will be logged:
[08:53:13] [Server thread/FATAL]: Error executing task java.util.concurrent.ExecutionException: java.lang.NullPointerException at java.util.concurrent.FutureTask.report(FutureTask.java:122) ~[?:1.8.0_91] at java.util.concurrent.FutureTask.get(FutureTask.java:192) ~[?:1.8.0_91] at h.a(SourceFile:46) [1.10.1.jar:?] at net.minecraft.server.MinecraftServer.D(SourceFile:598) [1.10.1.jar:?] at net.minecraft.server.MinecraftServer.C(SourceFile:554) [1.10.1.jar:?] at bzl.C(SourceFile:155) [1.10.1.jar:?] at net.minecraft.server.MinecraftServer.run(SourceFile:458) [1.10.1.jar:?] at java.lang.Thread.run(Thread.java:745) [?:1.8.0_91] Caused by: java.lang.NullPointerException at atq.e(SourceFile:461) ~[1.10.1.jar:?] at adj.a(SourceFile:60) ~[1.10.1.jar:?] at adz.a(SourceFile:143) ~[1.10.1.jar:?] at lv.a(SourceFile:339) ~[1.10.1.jar:?] at me.a(SourceFile:627) ~[1.10.1.jar:?] at jj.a(SourceFile:55) ~[1.10.1.jar:?] at jj.a(SourceFile:11) ~[1.10.1.jar:?] at fl$1.run(SourceFile:13) ~[1.10.1.jar:?] at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511) ~[?:1.8.0_91] at java.util.concurrent.FutureTask.run(FutureTask.java:266) ~[?:1.8.0_91] at h.a(SourceFile:45) ~[1.10.1.jar:?] ... 5 moreWhat seems to be happening (using MCP names) is that the fix for
MC-103497made `DragonFightManager.respawnDragon()` always try to use `exitPortalLocation`, even though `findExitPortal()`only sets this field when the detected portal is at (0,0). It should instead use the value returned by`findExitPortal()`, properly offset of course.To reproduce:
- Generate a world in a version before 1.9, and kill the dragon so that the exit portal is generated somewhere other than at (0,0).
- Load the world in 1.10.1 or later.
- Place the end crystals. See that the respawning process does not start.
It works fine in 1.10.
Further, as each crystal is placed, the following will be logged:
[08:53:13] [Server thread/FATAL]: Error executing task java.util.concurrent.ExecutionException: java.lang.NullPointerException at java.util.concurrent.FutureTask.report(FutureTask.java:122) ~[?:1.8.0_91] at java.util.concurrent.FutureTask.get(FutureTask.java:192) ~[?:1.8.0_91] at h.a(SourceFile:46) [1.10.1.jar:?] at net.minecraft.server.MinecraftServer.D(SourceFile:598) [1.10.1.jar:?] at net.minecraft.server.MinecraftServer.C(SourceFile:554) [1.10.1.jar:?] at bzl.C(SourceFile:155) [1.10.1.jar:?] at net.minecraft.server.MinecraftServer.run(SourceFile:458) [1.10.1.jar:?] at java.lang.Thread.run(Thread.java:745) [?:1.8.0_91] Caused by: java.lang.NullPointerException at atq.e(SourceFile:461) ~[1.10.1.jar:?] at adj.a(SourceFile:60) ~[1.10.1.jar:?] at adz.a(SourceFile:143) ~[1.10.1.jar:?] at lv.a(SourceFile:339) ~[1.10.1.jar:?] at me.a(SourceFile:627) ~[1.10.1.jar:?] at jj.a(SourceFile:55) ~[1.10.1.jar:?] at jj.a(SourceFile:11) ~[1.10.1.jar:?] at fl$1.run(SourceFile:13) ~[1.10.1.jar:?] at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511) ~[?:1.8.0_91] at java.util.concurrent.FutureTask.run(FutureTask.java:266) ~[?:1.8.0_91] at h.a(SourceFile:45) ~[1.10.1.jar:?] ... 5 moreWhat seems to be happening (using MCP names) is that the fix for
MC-103497made DragonFightManager.respawnDragon() always try to use exitPortalLocation, even though findExitPortal() only sets this field when the detected portal is at (0,0). It should instead use the value returned by findExitPortal(), properly offset of course.
If an allay has items in its inventory, and the game is exited and reloaded or the entity is unloaded (e.g. due to distance) and reloaded, the items in the allay's inventory are lost.
This is due to a change in 22w42a, class `net.minecraft.world.entity.animal.allay.Allay`, method `readAdditionalSaveData`:
- this.inventory.fromTag(compoundTag.getList("Inventory", 10)); + if (compoundTag.contains("Inventory", 10)) { + this.inventory.fromTag(compoundTag.getList("Inventory", 10)); + }The "Inventory" tag is a List, which is type 9. So the added check for `contains("Inventory", 10)` will never succeed.
P.S. This is the same type of error that's causing
MC-198493.If an allay has items in its inventory, and the game is exited and reloaded or the entity is unloaded (e.g. due to distance) and reloaded, the items in the allay's inventory are lost.
This is due to a change in 22w42a, class net.minecraft.world.entity.animal.allay.Allay, method readAdditionalSaveData:
- this.inventory.fromTag(compoundTag.getList("Inventory", 10)); + if (compoundTag.contains("Inventory", 10)) { + this.inventory.fromTag(compoundTag.getList("Inventory", 10)); + }The "Inventory" tag is a List, which is type 9. So the added check for contains("Inventory", 10) will never succeed.
The same error was made in net.minecraft.world.entity.monster.piglin.Piglin and net.minecraft.world.entity.npc.AbstractVillager.
P.S. This is the same type of error that's causing
MC-198493.
Allays, Piglins, and Villagers lose inventory if unloaded and reloaded
Setup
Create a pen, maybe 10×10. Spawn one villager in the pen, and trap them in a minecart on one side. Spawn a second villager in the pen, allowed to run around. Place a job site block in the pen on the other side from the minecart. See first attached image.
Alternatively, trap one villager with trapdoors such that it can path out but can't actually leave. See second attached image.
Expected result
The free-running villager will claim the jobsite reasonably quickly.
Actual result
Half the time, the free-running villager will claim it immediately.
The other half of the time, the trapped villager will stare intently at the jobsite while the free-running villager ignores it for a long time. The free-running villager may finally claim it after many minutes; at a guess this is probably a result of a ~1/30 chance rolled once per minute.
Analysis
I think what's going on here is something like this
1. Both villagers are running AcquirePoi for POTENTIAL_JOB_SITE once every 20–39 ticks.
2. The jobsite is placed. In the failure case, the trapped villager's AcquirePoi runs first.
3. Since the villager can path to it, they take the POI. This prevents the other villager from even considering it.
4. The villager's GoToPotentialJobSite begins running to try to get the villager to the job site, but since the villager can't actually move they just stare. Meanwhile, AcquirePoi no longer runs as it is inhibited by the POTENTIAL_JOB_SITE memory being set.
5. After 1200 ticks, GoToPotentialJobSite times out. Its stop method erases the POTENTIAL_JOB_SITE memory and release the POI.
6. Since the trapped villager's AcquirePoi has not been run in 1200 ticks, it runs right away next tick and we're back at step 2. The "~1/30 chance" mentioned above would be the chance that the free-running villager's AcquirePoi's20–39 tick delay expires exactly when the POI is released.If that's right, one fix could be to set nextScheduledStart in AcquirePoi to 0 when taking the POI. That would trigger the if (this.nextScheduledStart == 0L) case in checkExtraStartConditions to delay step 6 by 20 ticks, giving the other villager a chance (~25% I think) to grab the POI before the trapped villager claims it again.
Or each instance of AcquirePoi could remember the last taken POI and not take that specific POI again for something longer than 1240 ticks. It already has the JitteredLinearRetry thing, but that's only 400 ticks max.
But both of those could probably still be problematic if there are multiple trapped villagers in range.
Another could be to not have AcquirePoi actually take the POI, instead have that happen by AssignProfessionFromJobSite when the villager actually reaches it and sets the JOB_SITE memory (with an extra check in there in case some other villager just claimed it in the same tick).
That last could also enable "villager races": trap several villagers, place one jobsite, then use redstone to release them all at once and see which manages to claim it.
I wouldn't recommend changing the path-finding to avoid the trapped villager being able to path to the jobsite in the first place. That seems too likely to break existing villager trading halls, and maybe other mob farms too.
Setup
Create a pen, maybe 10×10. Spawn one villager in the pen, and trap them in a minecart on one side. Spawn a second villager in the pen, allowed to run around. Place a job site block in the pen on the other side from the minecart. See first attached image.
Alternatively, trap one villager with trapdoors such that it can path out but can't actually leave. See second attached image.
Expected result
The free-running villager will claim the jobsite reasonably quickly.
Actual result
Half the time, the free-running villager will claim it immediately.
The other half of the time, the trapped villager will stare intently at the jobsite while the free-running villager ignores it for a long time. The free-running villager may finally claim it after many minutes; at a guess this is probably a result of a ~1/30 chance rolled once per minute.
Analysis
I think what's going on here is something like this
- Both villagers are running AcquirePoi for POTENTIAL_JOB_SITE once every 20–39 ticks.
- The jobsite is placed. In the failure case, the trapped villager's AcquirePoi runs first.
- Since the villager can path to it, they take the POI. This prevents the other villager from even considering it.
- The villager's GoToPotentialJobSite begins running to try to get the villager to the job site, but since the villager can't actually move they just stare. Meanwhile, AcquirePoi no longer runs as it is inhibited by the POTENTIAL_JOB_SITE memory being set.
- After 1200 ticks, GoToPotentialJobSite times out. Its stop method erases the POTENTIAL_JOB_SITE memory and release the POI.
- Since the trapped villager's AcquirePoi has not been run in 1200 ticks, it runs right away next tick and we're back at step 2. The "~1/30 chance" mentioned above would be the chance that the free-running villager's AcquirePoi's20–39 tick delay expires exactly when the POI is released.
If that's right, one fix could be to set nextScheduledStart in AcquirePoi to 0 when taking the POI. That would trigger the if (this.nextScheduledStart == 0L) case in checkExtraStartConditions to delay step 6 by 20 ticks, giving the other villager a chance (~25% I think) to grab the POI before the trapped villager claims it again.
Or each instance of AcquirePoi could remember the last taken POI and not take that specific POI again for something longer than 1240 ticks. It already has the JitteredLinearRetry thing, but that's only 400 ticks max.
But both of those could probably still be problematic if there are multiple trapped villagers in range.
Another could be to not have AcquirePoi actually take the POI, instead have that happen by AssignProfessionFromJobSite when the villager actually reaches it and sets the JOB_SITE memory (with an extra check in there in case some other villager just claimed it in the same tick).
That last could also enable "villager races": trap several villagers, place one jobsite, then use redstone to release them all at once and see which manages to claim it.
I wouldn't recommend changing the path-finding to avoid the trapped villager being able to path to the jobsite in the first place. That seems too likely to break existing villager trading halls, and maybe other mob farms too.
Setup
Create a pen, maybe 10×10. Spawn one villager in the pen, and trap them in a minecart on one side. Spawn a second villager in the pen, allowed to run around. Place a job site block in the pen on the other side from the minecart. See first attached image.
Alternatively, trap one villager with trapdoors such that it can path out but can't actually leave. See second attached image.
Expected result
The free-running villager will claim the jobsite reasonably quickly.
Actual result
Half the time, the free-running villager will claim it immediately.
The other half of the time, the trapped villager will stare intently at the jobsite while the free-running villager ignores it for a long time. The free-running villager may finally claim it after many minutes; at a guess this is probably a result of a ~1/30 chance rolled once per minute.
Analysis
I think what's going on here is something like this
- Both villagers are running AcquirePoi for POTENTIAL_JOB_SITE once every 20–39 ticks.
- The jobsite is placed. In the failure case, the trapped villager's AcquirePoi runs first.
- Since the villager can path to it, they take the POI. This prevents the other villager from even considering it.
- The villager's GoToPotentialJobSite begins running to try to get the villager to the job site, but since the villager can't actually move they just stare. Meanwhile, AcquirePoi no longer runs as it is inhibited by the POTENTIAL_JOB_SITE memory being set.
- After 1200 ticks, GoToPotentialJobSite times out. Its stop method erases the POTENTIAL_JOB_SITE memory and release the POI.
- Since the trapped villager's AcquirePoi has not been run in 1200 ticks, it runs right away next tick and we're back at step 2. The "~1/30 chance" mentioned above would be the chance that the free-running villager's AcquirePoi's20–39 tick delay expires exactly when the POI is released.
If that's right, one fix could be to set nextScheduledStart in AcquirePoi to 0 when taking the POI. That would trigger the if (this.nextScheduledStart == 0L) case in checkExtraStartConditions to delay step 6 by 20 ticks, giving the other villager a chance (~25% I think) to grab the POI before the trapped villager claims it again.
Or each instance of AcquirePoi could remember the last taken POI and not take that specific POI again for something longer than 1240 ticks. It already has the JitteredLinearRetry thing, but that's only 400 ticks max.
But both of those could probably still be problematic if there are multiple trapped villagers in range.
Another could be to not have AcquirePoi actually take the POI in this case, instead have that happen by AssignProfessionFromJobSite when the villager actually reaches it and sets the JOB_SITE memory (with an extra check in there in case some other villager just claimed it in the same tick).
That last could also enable "villager races": trap several villagers, place one jobsite, then use redstone to release them all at once and see which manages to claim it.
I wouldn't recommend changing the path-finding to avoid the trapped villager being able to path to the jobsite in the first place. That seems too likely to break existing villager trading halls, and maybe other mob farms too.
The bug
When saving witch hut structure data the game wrongly assumes all witch huts generate at the same height. As a result, witch huts generated higher than usual will allow regular mobs to spawn inside.
How to reproduce
Observe spawning in the witch hut at 8832, 9456 on seed "Witch hut test", pointed out by Anomie X in the comments.
/tp @p 8832 100 9456
See attached screenshots: One showing three layers of witch spawning floors built in a witch hut generated at its usual height, one showing three layers built at the same height (relative to the witch hut) which generated above Y=100. One spawns witches, the other spawns all kinds of mobs.
Code analysis
Code analysis by Xcom6000 can be found in this comment.
If you walk into a nether portal, you don't spawn at the right position in the nether and the other way around. You always spawn some blocks beside the portal and get suffocated if there is a wall.
To recreate the bug, i created a fresh world, built a nether portal and go through it. Then i got stuck in the netherrack some blocks under and beside the portal. But the portal was created just fine. When i wanted to go back to the overworld, i spawned 2 blocks in front of the portal in the overworld.
Adapted from Anomie X's comment:
On 1.8.3, the cause of this issue is located in the class named "adv", which handles portal travel:
In the code for placing the player there's a bit like this, which seems to be for adjusting the X/Z position from the corner portal-block of the destination portal to more closely match where the entity entered the source portal. var31 is X, var33 is Z.
if(var16.b().k() == cr.a.a) { var31 += (double)var16.b().g(); // !!! var33 = var18 + (1.0D - var1.aG().a) * (double)var16.d() * (double)var16.b().e().c().a(); } else { var31 = var18 + (1.0D - var1.aG().a) * (double)var16.d() * (double)var16.b().e().c().a(); var33 += (double)var16.b().i(); // !!! }
The lines I've commented with "!!!" are the problem, they move the entity 1 block in the "facing" direction of the portal without bothering to check for ground underneath, blocks in the way, or anything else. Modding the class to remove those two lines restores the expected behavior of spawning within the destination portal itself.
Please link to this comment by Anomie X for a way to reproduce this
You can try using the possible solutions Anomie X provided
@Socks you are probably right. That is what Anomie X described in this comment.
This report probably duplicates then MC-104736:
2. The <Gateways> tag when regenerated contains the entire original list of gateways, thus killing the dragon will recreate existing gateways before opening new ones.
I am not sure whether this is the right place to post this, but I couldn't find a better place on the bug tracker and doubt it belongs anywhere else then on the bug tracker.
Situation: World created pre-1.9 and dragon slain pre-1.9. In 1.10.2 trying to respawn dragon for first time with four ender crystals at the normal positions on the single existing portal. The level.dat file shows a <DragonFight> tag, it also has the <Gateways> tag and the other two tags indicating whether a dragon fight is underway and how often the dragon was slain. The <ExitPortalLocation> tag is missing.
What happens: After placing the end crystals they are back in the inventory after re-logging or clicking the now empty inventory slot. Like if there are connection issues and the client thinks ahead wrongly. The placed end crystals (they have fire beneath, not sure whether intended) don't re-spawn the dragon, but are explosive.
Solution: When I place a single end crystal one block lower (breaking the bedrock beforehand) - I don't even have to place more then this single end crystal - a new portal gets generated in the middle of the island. The <ExitPortalLocation> tag is then created. The old portal still works. The new portal then behaves correctly, re-spawning the ender dragon as soon as the end crystals are placed correctly at this new portal.
Around the time when I place the end crystals at the position I would expect them to be placed (before forcing the creation of the second portal by removing bedrock and placing crystals on block lower) and nothing actually happens, the following errors get reported:
[21:05:16] [Server thread/FATAL]: Error executing task java.util.concurrent.ExecutionException: java.lang.NullPointerException at java.util.concurrent.FutureTask.report(FutureTask.java:122) ~[?:1.8.0_101] at java.util.concurrent.FutureTask.get(FutureTask.java:192) ~[?:1.8.0_101] at h.a(SourceFile:46) [minecraft_server.jar:?] at net.minecraft.server.MinecraftServer.D(SourceFile:598) [minecraft_server.jar:?] at ld.D(SourceFile:338) [minecraft_server.jar:?] at net.minecraft.server.MinecraftServer.C(SourceFile:554) [minecraft_server.jar:?] at net.minecraft.server.MinecraftServer.run(SourceFile:458) [minecraft_server.jar:?] at java.lang.Thread.run(Thread.java:745) [?:1.8.0_101] Caused by: java.lang.NullPointerException at atq.e(SourceFile:461) ~[minecraft_server.jar:?] at adj.a(SourceFile:60) ~[minecraft_server.jar:?] at adz.a(SourceFile:143) ~[minecraft_server.jar:?] at lv.a(SourceFile:344) ~[minecraft_server.jar:?] at me.a(SourceFile:627) ~[minecraft_server.jar:?] at jj.a(SourceFile:55) ~[minecraft_server.jar:?] at jj.a(SourceFile:11) ~[minecraft_server.jar:?] at fl$1.run(SourceFile:13) ~[minecraft_server.jar:?] at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511) ~[?:1.8.0_101] at java.util.concurrent.FutureTask.run(FutureTask.java:266) ~[?:1.8.0_101] at h.a(SourceFile:45) ~[minecraft_server.jar:?] ... 5 more [21:05:20] [Server thread/FATAL]: Error executing task java.util.concurrent.ExecutionException: java.lang.NullPointerException at java.util.concurrent.FutureTask.report(FutureTask.java:122) ~[?:1.8.0_101] at java.util.concurrent.FutureTask.get(FutureTask.java:192) ~[?:1.8.0_101] at h.a(SourceFile:46) [minecraft_server.jar:?] at net.minecraft.server.MinecraftServer.D(SourceFile:598) [minecraft_server.jar:?] at ld.D(SourceFile:338) [minecraft_server.jar:?] at net.minecraft.server.MinecraftServer.C(SourceFile:554) [minecraft_server.jar:?] at net.minecraft.server.MinecraftServer.run(SourceFile:458) [minecraft_server.jar:?] at java.lang.Thread.run(Thread.java:745) [?:1.8.0_101] Caused by: java.lang.NullPointerException at atq.e(SourceFile:461) ~[minecraft_server.jar:?] at adj.a(SourceFile:60) ~[minecraft_server.jar:?] at adz.a(SourceFile:143) ~[minecraft_server.jar:?] at lv.a(SourceFile:344) ~[minecraft_server.jar:?] at me.a(SourceFile:627) ~[minecraft_server.jar:?] at jj.a(SourceFile:55) ~[minecraft_server.jar:?] at jj.a(SourceFile:11) ~[minecraft_server.jar:?] at fl$1.run(SourceFile:13) ~[minecraft_server.jar:?] at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511) ~[?:1.8.0_101] at java.util.concurrent.FutureTask.run(FutureTask.java:266) ~[?:1.8.0_101] at h.a(SourceFile:45) ~[minecraft_server.jar:?] ... 5 more [21:06:54] [Server thread/FATAL]: Error executing task java.util.concurrent.ExecutionException: java.lang.NullPointerException at java.util.concurrent.FutureTask.report(FutureTask.java:122) ~[?:1.8.0_101] at java.util.concurrent.FutureTask.get(FutureTask.java:192) ~[?:1.8.0_101] at h.a(SourceFile:46) [minecraft_server.jar:?] at net.minecraft.server.MinecraftServer.D(SourceFile:598) [minecraft_server.jar:?] at ld.D(SourceFile:338) [minecraft_server.jar:?] at net.minecraft.server.MinecraftServer.C(SourceFile:554) [minecraft_server.jar:?] at net.minecraft.server.MinecraftServer.run(SourceFile:458) [minecraft_server.jar:?] at java.lang.Thread.run(Thread.java:745) [?:1.8.0_101] Caused by: java.lang.NullPointerException at atq.e(SourceFile:461) ~[minecraft_server.jar:?] at adj.a(SourceFile:60) ~[minecraft_server.jar:?] at adz.a(SourceFile:143) ~[minecraft_server.jar:?] at lv.a(SourceFile:344) ~[minecraft_server.jar:?] at me.a(SourceFile:627) ~[minecraft_server.jar:?] at jj.a(SourceFile:55) ~[minecraft_server.jar:?] at jj.a(SourceFile:11) ~[minecraft_server.jar:?] at fl$1.run(SourceFile:13) ~[minecraft_server.jar:?] at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511) ~[?:1.8.0_101] at java.util.concurrent.FutureTask.run(FutureTask.java:266) ~[?:1.8.0_101] at h.a(SourceFile:45) ~[minecraft_server.jar:?] ... 5 more [21:06:57] [Server thread/FATAL]: Error executing task java.util.concurrent.ExecutionException: java.lang.NullPointerException at java.util.concurrent.FutureTask.report(FutureTask.java:122) ~[?:1.8.0_101] at java.util.concurrent.FutureTask.get(FutureTask.java:192) ~[?:1.8.0_101] at h.a(SourceFile:46) [minecraft_server.jar:?] at net.minecraft.server.MinecraftServer.D(SourceFile:598) [minecraft_server.jar:?] at ld.D(SourceFile:338) [minecraft_server.jar:?] at net.minecraft.server.MinecraftServer.C(SourceFile:554) [minecraft_server.jar:?] at net.minecraft.server.MinecraftServer.run(SourceFile:458) [minecraft_server.jar:?] at java.lang.Thread.run(Thread.java:745) [?:1.8.0_101] Caused by: java.lang.NullPointerException at atq.e(SourceFile:461) ~[minecraft_server.jar:?] at adj.a(SourceFile:60) ~[minecraft_server.jar:?] at adz.a(SourceFile:143) ~[minecraft_server.jar:?] at lv.a(SourceFile:344) ~[minecraft_server.jar:?] at me.a(SourceFile:627) ~[minecraft_server.jar:?] at jj.a(SourceFile:55) ~[minecraft_server.jar:?] at jj.a(SourceFile:11) ~[minecraft_server.jar:?] at fl$1.run(SourceFile:13) ~[minecraft_server.jar:?] at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511) ~[?:1.8.0_101] at java.util.concurrent.FutureTask.run(FutureTask.java:266) ~[?:1.8.0_101] at h.a(SourceFile:45) ~[minecraft_server.jar:?] ... 5 more
I am posting this because it look very similar to the issue described here, but is still different. According to the description of Anomie X here my world would be in "state #3", which should be fixed, however it is not fixed apparently. The only faulty behaviour is expected from a world in "state #4" according to this description, but this is apparently not the case exclusively.
Villagers become unable to move when their workstation is placed nearby. Placing the workstation will cause villagers to freeze immediately, and they will only return to normal once the workstation has been broken.
After the workstation has been broken, they will walk over to where it had been placed, and then turn around and walk back to whatever they were doing before.
Only seems to affect librarians but have not tested all villager types. All librarians in my survival world were affected, but farmers and fletchers have not done it at all.
Some users report that even breaking the workstations does not unfreeze the villagers, and that they are missing data.
Code analysis can be found in this comment by Anomie X.
I posted this analysis on the forum, but apparently if I want it here I'll have to create an account and do it myself since no one is considerate enough to copy it over for me.
An even easier way to reproduce the bug is to create one villager, give him 1 potato, and then give him plenty of bread or carrots. Then create a second villager and enough doors. The first will throw potatoes, and both their inventories will fill up with slots containing 0 potatoes. The "potato" entities on the ground will be more instances of "0 potatoes".
After decompiling the 14w21b code, it looks like the main problem is in class "xo", this line:
if(agu1 == ahl.P || agu1 == ahl.bG || agu1 == ahl.bF && ahk1.b > 3)
Which translates as "if(item == bread || item == potato || item == carrots && qty > 3)". That should obviously be "if((item == bread || item == potato || item == carrots) && qty > 3)". As is, the villager will happily try to throw half of 1 bread/potato, which rounds to 0, so the villager throws "0 bread" or "0 potatoes". Which surprisingly doesn't throw an exception.
Then the pick-up-item routine in class "ti" gets confused: Because "picking up 0 of the item" and "can't fit any more in this inventory slot" both result in 0 for the quantity-to-add-to-this-inventory-slot variable, it doesn't harmlessly merge that "0 bread" with an existing bread slot. Instead, it puts it in the first empty slot, resulting in the villager's inventory quickly filling up with "0 bread" and "0 potatoes" as reported here.
Now, once that's fixed, there are still other ways that things can go wrong, although they're much less likely since they'll need villagers to get many stacks of various items in particular combinations and aren't self-perpetuating to newly-born villagers:
If I were trying to fix these, I'd have villagers be able to recombine their inventory slots (e.g. 3 potatoes in one slot + 6 potatoes in another would be turned into 9 potatoes in one slot and the other empty). And I'd have villagers throw out some of something they have at least 2 stacks of to pick up something they don't have any of if they have no empty slots after recombining (and plan to implement some "preference" AI if villagers ever get the ability to pick up more than 8 different kinds of things, so they can be smart enough to throw out their least-valuable item in order to pick up something they really need). And I'd fix the non-farmer seed issue one way or the other.
Then there's the weirdness where only farmers count wheat in the "do I have enough food to breed?" check, but all villagers will craft wheat into bread for throwing, but no one will craft wheat into bread to eat for themselves. If only farmers should be able to make bread, I'd have other villagers either not bother to pick it up or give it all to farmers (same as seeds). If everyone should be able to make bread, then they should all count it as food. And either way, whoever can make bread should be able to do so if they need it themselves, not only when throwing it at someone else.
I too have seen slimes appearing and then instantly disappearing in my superflat world, and in a swamp in a normal world. I didn't see a reduction in magma cube spawning in a very quick test, nor does it seem likely since they don't have the chance to randomly fail to spawn that slimes do.
It appears that the earlier comment is correct: when randomly-spawning mobs, it checks if the mob can spawn at the location. And then for slimes it checks again after spawning. The problem appears to be that slime spawning has a probability of just randomly failing, and this is applied each time the "can spawn" method is called.
So for slime chunks, each "can spawn" check has only a 10% chance of succeeding. Making it pass the chance twice reduces the successful spawn rate to only 1%. Swamps are more complicated, as there are three random number checks (a 50% chance of failing, a chance based on moon phase, and a chance based on light level) that all get repeated. Superflat reduces the chances further by failing on 75% of calls, meaning a superflat that's hitting the slime chunk spawning chance has its probability reduced from a normal 2.5% to only a 0.0625% chance.
Speaking of the slimes' reduced chances of spawning success, I wonder if these need to be rebalanced or even eliminated since slimes now despawn like other mobs when over 32 blocks away, instead of staying around until all players are 128 blocks away.
It looks like the fix for
MC-30877probably did add the same test. But one of the functions that test uses changed behavior from "sky light level in full sun" to "current sky light level", probably in 14w02a.While this bug to this point only mentions crops, I note that flowers, saplings, and pumpkin/melon stems showed the same behavior change between 1.6.4 and 1.7. I don't know if you'd prefer that to be part of this bug, or a new bug, or if those others are working as intended in not popping off.
Digging through decompiled code, it seems the bug is simple. There are two classes for generating glowstone formations ("bam" and "bas" in 14w21b), and the coordinate calculation for one ("bam") is missing a '-' so it tries to generate the glowstone formation above the seed block rather than below.
Note it's not just iron golems. I've personally tested skeletons, and I suspect any mob that you can get to attack the zombie pigmen would work.
I see this is marked as fixed now, but
MC-7488isn't. Please fix that one too!Looks fixed in 14w25b to me. It appears they split the "can spawn" check into two parts, only one of which is called twice. So the "random chance to fail" can go in the called-once part and the "does the mob actually fit here?" can go in the called-twice part.
It looks like they also adjusted things so that there won't be the flicker of the mob spawning and then immediately despawning anymore in cases where the second "does the mob actually fit here?" check fails.
This seems to come from the fix for
MC-55260: it appears that fix was to split the "can mob spawn here?" check into two functions, one for checks that should only be done once (e.g. random failure chances) and one for checks that can be done multiple times (e.g. whether the mob fits and satisfies light levels).The code for spawners is calling only the first, where it should probably either call both or just the second (depending on what the actual semantics of the first are).
> The problem is not that the buckets disappear, the problem is that you can put more than one
> in the fuel slot in the first place. This will be solved differently, but the behavior that you
> describe is WAI.
Reopen this bug and retitle it "Furnaces allow more than 1 empty bucket to be placed in the fuel slot." Or mark it as duplicate to some other bug that already tracks the issue from that perspective. But don't pretend that it's intended behavior that placing a stack of buckets in the fuel slot destroys all but one of them when you yourself just said that bucket destruction is not intended.
This bug appears to have been fixed in 14w25a; it looks to me like the fix was a side effect of changes for the new block metadata format.
Since it doesn't seem anyone has explained the bug yet: The bug was because the lava flowing process looked something like this:
1. The flowing lava calls the function to replace the redstone block with flowing lava (block ID "flowing_lava", metadata value somewhere between 1 and 7).
2. The "replace block" function sets the block ID in the world with Lava, but does not update the block metadata yet.
3. The "replace block" function calls a method on the old block type, so it can react to the replacement.
4. The "replace block" function, if the call from step 3 didn't change the block ID again, updates the block metadata.
Certain blocks will do a "block tick" on adjacent blocks in step 3; among other things, redstone does this to update the power state. And the block tick handler for flowing lava checks if there is water adjacent and the block metadata value is 0 (meaning a source block), and if so replaces the lava with obsidian.
This bug is not a duplicate of
MC-55534. That bug is basically "hey, I built a redstone-to-obsidian contraption wrong and it doesn't work". This bug is reporting "bugMC-4239was fixed in 14w25a" as a bug.> the obsidian generators were not working in v1.7.2
False.
I note this bug has been fixed in 14w26a, in the manner Searge described.
Still exists in 14w26c
This is probably intended. There appears to be a 1 in 7 chance that spawning a rabbit will spawn 2 additional rabbits, much like how there is a 1 in 7 chance that spawning an ocelot will spawn two baby ocelots.
This is probably invalid. I just spawned a bunch of rabbits and killed them with a Looting III sword, and did receive all the items rabbits are supposed to drop (hides, meat, and feet).
I noticed the same teleportation issue with cats and dogs in 14w27b. It's probably that rabbits are also being affected by
MC-55661.But if tamed rabbits will teleport and cannot be made to sit, it's going to be very difficult to actually keep tamed rabbits around. So I'd keep that part of things open as a separate bug.
Duplicate of
MC-59871In my testing, I've found that tamed rabbits breed fine. Wild rabbits will not breed, same as wild ocelots.
Taming rabbits works the same as taming ocelots, BTW, except that you use carrots rather than fish.
Experimenting a bit and looking at a decompilation, it appears that the delay is being counted down 10 times as fast: the delay counter is being decremented by 10 per tick instead of just 1 per tick.
Still present in 14w28b.
Still occurs in 1.7.10, 14w28b, and 14w29b. Also applies to cocoa beans.
I note that most other items that place blocks pass 3 as the last parameter to the method that actually places the block in the world, while skulls and cocoa beans pass 2. And looking into that function, it appears that bit 0 clear does specifically prevent the place-block method from triggering an update.
Door items also pass 2 to that method, but they trigger updates "manually" immediately after placing the door-blocks into the world.
The issue (rabbits will teleport but cannot be made to sit) still exists in 14w30c.
This appears to have been fixed in 14w28a or 14w28b; I can reproduce in 14w27b but not 14w28b.
At least the "throws 0 potatoes" part of this bug still exists in 14w30c. I didn't bother to do further testing.
I don't think this is really fixed. I think it's just that
MC-55661is broken even worse in 14w31a.I dug into this a little. Prior to 14w05b, the test for which blocks would cause "inWall" damage when a mob's head is inside was something like "material is solid and not transparent and Block.d() is true". I'm not sure what Block.d() is supposed to mean. In 14w05b, that was changed to something like "material is solid and Block.d() is true". But the test for whether a block was safe for dogs and cats to teleport into wasn't changed to match, causing
MC-50821since they'd still teleport into solid blocks with transparent material.Then in 14w21a, the check for a safe teleport-into blocks was changed, but instead of using the same method added in 14w05b for inWall damage (testing "material is solid and block fills the cube) it only tested Block.d(). And air returns true for Block.d(), causing this bug. This explains why I observed in 14w30 and earlier that they would teleport into glass.
But it looks like it's even more broken now in 14w31a. If I'm reading it right, the code for teleporting is trying to find a path to the player (within the mob's followRange), and if that fails it will try to teleport. In 14w31a that pathfinding method now always claims success (after scheduling the threaded pathfinding), so the mobs will never try to teleport.
While the additional bug added in 14w31a has been fixed in 14a32a, the original bug added in 14w21a (preventing mobs from teleporting to air blocks) has not yet been fixed.
Since the total-teleportation-breakage in 14w31a was fixed, rabbits will teleport again in 14w32a if you walk near a wall of appropriate blocks (e.g. a wall of glass blocks at least 2 high). They still won't teleport into air blocks (nor will dogs or cats) due to the remaining problems behind
MC-55661.Please reopen this bug. It was never actually fixed, just hidden by a different bug.
The recent title edit by [Mod] Anon Ymus is incorrect. In particular, I created a 23x23 portal with trapdoors at Y=30 above a Superflat world in 14w32d, cranked up randomTickSpeed, and watched zombie pigmen walk off and die. None dropped experience or any rare drops.
The key is that a pigman must be damaged by a non-player entity; any passive pigmen within the anger distance will be marked as "damaged by the player" and will therefore drop XP on death.
Yes, it still occurs in 14w33c.
Bug still exists in 14w34b.
Still exists in 14w34b
Still present in 14w34b.
Still exists in 14w34b.
Still exists in 14w34b
At least the "throws 0 potatoes" part of this bug still exists in 14w34b. I didn't bother to do further testing.
This bug was still occurring in 14w33c, but appears to have been obsoleted as of 14w34b since rabbits are no longer tamable.
Getting hit by a snowball counts as player damage (even though it does 0 damage), so any death within 5 seconds counts as a player kill. Whether all the rest of the pigmen that get angered from hitting one with a snowball should also count as player kills is a good question, though.
In the Temples.dat NBT file, there's a <BB> node at the top level for the whole structure and a <BB> node on each child piece of the structure. For the hut in the attached zip, these differ in the Y coordinates.
Glancing through decompiled code for 1.7.10 and for 14w34d, the issue seems to be that in 1.7 it ignored the Y coordinates on the outer <BB> tag while in 14w34d it's checking it when matching the spawn coordinate against the bounds of the structure.
Still present in 1.8-pre1.
Still present in 1.8-pre1. This one makes me sad, since it makes the corners of one of my builds look ratty.
Still present in 1.8-pre1.
Still present in 1.8-pre1.
Note that witch huts first generated in 14w34d have the same Y-coordinate situation. So it's not just old huts.
Still present in 1.8-pre1.
Still present in 1.8-pre1.
At least the "throws 0 potatoes" part of this bug still exists in 1.8-pre1. I didn't bother to do further testing.
I'm surprised at least that part of this bug hasn't been fixed yet, it seems both serious and easy to fix.
> Not sure if it's related but animals that usually teleport to you, such as wolves and cats,
> are unable to keep up
Teleporting being broken in 1.8-pre1 is
MC-55661.At least the "throws 0 potatoes" part of this bug still exists in 1.8-pre2. I didn't bother to do further testing.
Still present in 1.8-pre2.
Still present in 1.8-pre2.
Still present in 1.8-pre2.
Still present in 1.8-pre2.
Still present in 1.8-pre2.
Still present in 1.8-pre2.
No, it's not intentional. It seems that many structures are internally generated at a constant Y level and then moved up or down to fit the terrain. If some part of the moving is skipped but doesn't cause any major issues, it's unlikely to be fixed (e.g.
MC-954).Also, it's (probably) possible for a witch hut to generate at such an elevation that there would be no overlap at all in the Y coordinate ranges.
Still present in 1.8-pre3.
Still present in 1.8-pre3.
Still present in 1.8-pre3.
Still present in 1.8-pre3.
Still present in 1.8-pre3.
Still present in 1.8-pre3.
At least the "throws 0 potatoes" part of this bug still exists in 1.8-pre3. I didn't bother to do further testing.
Hooray for the throwing 0 potatoes and 0 bread being fixed!
Unless these were fixed too (which it doesn't sound like), there are still some less-serious issues:
Still in 1.8. As far as I'm concerned this may as well be closed as "WAI", since no one has bothered to respond here at all.
Still present in 1.8.
Still present in 1.8. Boo.
Still present in 1.8.
Still present in 1.8. Boo.
Duplicate of
MC-14521(controls) andMC-2931(position desync leading to seemingly-random breaking)This sounds like the intended behavior: locked trades get unlocked (and new tiers get opened, if applicable) 100% when making a trade for the first time or 20% every subsequent time. So you probably hit the 100% or 20% to have the villager unlock trades while you were trading to lock the one trade.
This one will be annoying if it gets fixed, as it will mean I'll have to turn farther to close the door behind me after walking farther to get out of the way.
The librarian will accept the books if you give them a stack of 2, either by making identically-titled books with identical content or by making copies.
It may be time to fix
MC-30415.Boats desyncing are
MC-2931This sounds like WAI to me since the addition of "generations" to books: the original book is an "original" and won't stack with the new books that are "copy of original". Similarly, a "copy of copy" won't stack with either "original" or "copy of original".
To stack without losing the NBT data, written books must be identical: same author, same title, same contents, and same generation.
If you're going to mark this as a duplicate of
MC-30415, you should probably reopen that until Mojang developers decide if the current confusing behavior (2 of a mostly-non-stackable item needing to be stacked) is really intended.Cannot reproduce, my slime farm in a slime chunk is working exactly as well in 1.8 (final) as it did in 1.7.10.
I did design it with the new 1.8 slime behavior in mind; any farm that depends on slimes never despawning if the player is within 128 blocks or that depends on slimes not swimming is going to be broken.
@Searge: I find it hard to understand how you can close this as "works as intended". It's intended that with huts that spawn with their floor at Y=65 spawn only witches, while huts that spawn on top of a hill will spawn other mobs? That makes little sense.
I'm also unclear on whether you actually fixed the bug (that the bounding box used for the hut doesn't match where the hut was actually generated) or whether you merely increased the height of the incorrect bounding box so the hut has to spawn on top of a bigger hill for the bug to be noticed.
MC-72126is too vague to be able to test it, but this bug has not returned in 1.8.> Please actually test behaviour before coming with illogical conclusions.
I did.
Whatever is going on in bug
MC-72126may have some similarities, but is not the same as this bug.Considering that every other mob that drops a raw meat food item will drop the cooked version when killed with fire, there's good reason to consider this a bug rather than a feature request. If they had forgotten to have rabbits drop cooked rabbit meat when killed with fire, would you also consider that a feature request rather than a bug?
This could be WAI if the fish drop is supposed to be the contents of the Guardian's lunchbox rather than actual Guardian meat or something like that, but absent that clarification this seems a valid bug report.
Could not reproduce in 1.8 SSP. First I circumnavigated a continent and docked on slabs without damage, then I tried idling in a boat for 4 minutes before docking on slabs (as suggested by one of the comments here) and again took no damage.
Still present in 1.8.1-pre2.
Still present in 1.8.1-pre2.
Still present in 1.8.1-pre2.
Confirmed in 1.8.1-pre2 using a world generated with Default settings. So it's not just customized worlds (but we already knew that).
Confirmed in 1.8.1-pre3. Seed "Witch hut test" (-1777352604), witch hut generates with bounding box [ 8832, 77, 9456, 8840, 83, 9462 ], well outside the recorded structure bounding box of [ 8832, 64, 9456, 8840, 70, 9462 ].
From the NBT in pseudo-XML:
<[552,591]>
<id>Temple</id>
<ChunkX>552</ChunkX>
<BB>[ 8832, 64, 9456, 8840, 70, 9462 ]</BB>
<ChunkZ>591</ChunkZ>
<Children>
<>
<id>TeSH</id>
<GD>0</GD>
<HPos>77</HPos>
<BB>[ 8832, 77, 9456, 8840, 83, 9462 ]</BB>
<Height>7</Height>
<Witch>1</Witch>
<Width>7</Width>
<O>1</O>
<Depth>9</Depth>
</>
</Children>
</[552,591]>
If it were intended then why not skip the calculation of local difficulty entirely for Easy? Why pretend the local difficulty rises from 0.75 to 1.5 when it has no effect?
I note mobs would spawn with armor and so on in 1.7 on Easy.
@Robert Johnston: Pet teleporting works fine here in 1.8.1-pre4.
@Jack Manley: Have you actually checked their inventories in an NBT editor? It could be the inventories are just filled with wheat and bread.
This is most likely Works As Intended. The villager code specifically checks for "do I have enough food" and doesn't harvest if so; once the villager eats or gives away enough food to get under the threshold, they will begin harvesting again.
BTW, besides 60 carrots or potatoes, also 15 bread or 45 wheat cause this effect.
As far as the "CanPickUpLoot" flag issue described in this bug's description, it appears that even as far back as 14w04a newly-spawned villagers would have the flag set. It appears to have been fixed in 14w05a for existing villagers.
Discussion where farming worked fine and then stopped is likely either mobGriefing=false or
MC-48735.@Felipe Fernandez: Took me a while to get to it, but
MC-74407.Yes. And one is missing from that list, which is how I noticed this in the first place.
The point is that there is a recipe that logically should work but it's missing from the game. There's no reason for Red + Blue + Red + White to make Magenta, and Pink + Red + Blue to make Magenta, and Pink + Purple to make Magenta, but not Purple + Red + White.
Yes, I'm sure they intended to omit one recipe while including all other permutations.
Yes, still occurs in 1.8.2-pre1.
Seed "Witch hut test" still generates mismatched bounding boxes for the hut at 8832,9456 in 1.8.2-pre1.
Still present in 1.8.2-pre1
Still present in 1.8.2-pre1.
Just because someone didn't understand it well enough to not be able to reproduce it (or, for that matter, because you don't see the logic that points to it being unlikely to be "works as intended") doesn't mean it doesn't exist. Unfortunately there's very little that can be done when a mod makes a wrong closure like this.
I dug into this a bit more today. When a vine block attempts to grow downwards and the block below has vines, then:
But the update is skipped if the above results in none of the horizontal sides having vines.
The logic here looks something like this:
It would make more sense for the code to be 50% chance of setting sides that are set on the block above, rather than clearing sides:
Since 14w32b, beacons need a clear line of sight up to Y=255 in the Overworld and Y=127 in both the Nether and the End, and ignores any blocks above that. Also the beam only travels to that height, so beacons above that height have the truncated beacon as shown here.
It seems odd for the beacon not to look for blocks all the way to the build limit.
Since 14w32b, beacons now consistently don't work in the Nether unless the bedrock ceiling is broken. The remaining issues being mentioned here seem to be
MC-67727and possiblyMC-73406.If by "documented behavior" you're referring to the wiki, note (1) that's not official documentation by any stretch of the imagination and (2) the whole bit there about "naturally generated" blocks being allowed seems likely to have been poorly describing the effect of bugs in the initialization of the chunk's "HeightMap" data (as recently as 1.7.10 it would be set to not include the topmost bedrock layer, and it seems to have been even worse in some 1.4.2 beta versions).
I have no idea why you're ranting about the fact that the wiki isn't official documentation.
MC-73406is an actual bug where the beacon basically ignores the top half of the dimension. When it comes down to it, this is a feature request that the behavior of beacons should change, at least in the Nether.This was actually fixed in 1.7.2, not 1.8.2-pre1.
Still present in 1.8.2-pre3.
Still present in 1.8.2-pre3.
Still present in 1.8.2-pre3.
Still present in 1.8.2-pre3.
Still present in 1.8.2-pre3.
Still present in 1.8.2-pre3.
I've attached a simpler reproduction, better suited for a bug report than in-game exploits. When you push the button, the powered rail will drop into 2 powered rail items. It doesn't matter which side of the hole the normal rail is on or which type of rail it is, as long as it's not facing into the hole.
What seems to be happening is that the powered rail getting pushed which has two effects: (1) the adjacent rails are checked for needing-to-rotate, and (2) the pushed rail updates itself, presumably to update its power level. But when the adjacent rail rotates during step 1 it updates all of its adjacent blocks, including the pushed rail which causes it to drop. And then step 2 doesn't notice that the pushed rail has already been broken and so drops it again.
Written books must have the same title, author, contents, and generation ("original", "copy of original", "copy of copy") in order to stack. You're probably not paying attention to the generation.
Still present in 1.8.3.
Still present in 1.8.3.
Still present in 1.8.3.
In 1.8.3, single Jungle saplings will now grow if planted on farmland. Acacia still will not, nor will 2x2 trees if the northwest sapling is on farmland.
Still present in 1.8.3.
Still present in 1.8.3.
Still present in 1.8.3.
Confirmed for 1.8.3.
Also, if you hold a stack of the item and click on the stack in the beacon GUI, all but one of the stack in the beacon will move into your hand even if that results in you holding more than a full stack.
I saw
MC-46771, but I've had no luck with getting any attention for closed bugs in the past.So I decompiled the code for 1.8.3 class "adv", which is what handles portal travel.
In the code for placing the player there's a bit like this, which seems to be for adjusting the X/Z position from the corner portal-block of the destination portal to more closely match where the entity entered the source portal. var31 is X, var33 is Z.
The lines I've commented with "!!!" are the problem, they move the entity 1 block in the "facing" direction of the portal without bothering to check for ground underneath, blocks in the way, or anything else. Modding the class to remove those two lines restores the expected behavior of spawning within the destination portal itself.
@KingSupernova: Wasn't the spawning too low part fixed in 1.8.1-pre5?
This is not the case in 1.8 (i.e. before this bug was introduced), and very likely is not the case in 1.8.3 either. The post-teleportation "cooldown" timer is reset any time it hasn't expired and the entity is within a portal. For players this timer is only half a second, so stepping out and immediately back in is usually enough to let it expire.
Much of the rest of your wall of text is based on this faulty premise.
Yes it would be. Only your imagined "expected" behavior would not be fixed.
Also false. That block isn't cleared except in the last-resort case where the game couldn't find any valid location to place a portal. Nor would it be the case for built portals, for example many of mine are against a wall.
I came across some code that would explain why I couldn't reproduce this earlier but other people still report the problem.
It appears they attempted to fix this sometime between 1.6.4 and 1.7.2 by having boats not accumulate fall distance when they're above a water block. But the test is slightly bugged: the boat isn't actually on top of the surface water block, it's slightly inside of it (the boat's Y is about 3.9 on a water block at Y=3, rather than 4.0 like standing on solid ground), so the block "below" is actually the block under the surface water block (at Y=2). When I tested I was in deep water the whole time so no fall distance accumulated, but whenever you're in shallow water (e.g. a swamp) the block underneath is not water so the fall distance will accumulate as the boat bobs. And deep water doesn't reset fall distance, it just doesn't make it worse.
Further, the normal "reset fall damage when in water" doesn't usually apply to boats because that only occurs when the entity is farther into the water block than boats normally get. It looks like it would have to get down to about Y=3.599 in that water block at Y=3 for that to happen.
Safest, yes, but maybe not the most desired when that isn't the case.
Presumably the future fix will be something along the lines of checking for any liquid or any solid blocks intersecting where the player would be placed outside of the portal plus ensuring there are solid blocks just under where the player would be placed. If the check fails (maybe try it on both sides of the portal just in case?) then it would have to fall back to the current behavior.
Then be ready to respond to bug reports in case there's any bugs like certain non-solid blocks accidentally being considered solid.
It seems that sometime around 1.0.0 the check for allowing wolves to despawn was changed from "is tamed" to "is angry", which probably caused
MC-1407. Then in 1.5.2 it was changed to "is angry and not tamed", which seems good.But then in 1.6.1 it changed to "is not tamed and loaded more than 2 minutes" for some reason, which is the code that Larry Blackburn identified above.
Ocelots, meanwhile, have despawned when not tamed since 1.2.2, and in 1.6.1 it was changed to "is not tamed and loaded more than 2 minutes" (I haven't checked what went on in the 1.6 development versions). In light of this, I suspect someone made the change for ocelots, saw similar code in wolves, and didn't realize that what makes sense for one doesn't for the other.
This makes sense for Ocelots, since they are in the hostile mob spawn list for jungles so they'll respawn frequently. But as long as wolves are in the passive mob spawn list for the biomes they spawn in, it doesn't make sense for them and should probably be changed back to only allowing despawning when angry and not tamed (and keep the 2-minute delay if you want).
Works fine when I try it, generating a new world in 1.8.4.
The behavior you describe sounds like you're somehow using activator rails rather than powered rails.
Or fishing, or trading, or various other chests besides dungeons.
It appears that in 1.8.2 they changed the "generate big mushroom" class from storing 0 for brown or 1 for red or -1 for choose randomly to storing the blockstate for brown/red and null for choose randomly.
But at the same time they changed the choosing randomly from storing in a local variable to updating the field on the "generate big mushroom" instance, which has the effect that it chooses randomly exactly once for all the mushrooms in all the mushroom islands in that play-session.
Works fine when I try it.
Probably works as intended. Web diffuses sunlight like leaves, unlike glass, torches, etc.
Despite this being closed as "works as intended", having a zombie pick up a diamond thrown in survival mode does give the achievement in 1.8.4.
I can't even reproduce this bug in 14w27b, for that matter.
Works fine for me in 1.8.7. Your issues are probably something different.
> Results: No slimes spawning on either pad, travelled a distance of 25 blocks away from the edge of the chunk and witnessed. Cleared mobs by switching to peaceful and back to hard, same results.
You also didn't light up any caves or the surface, so low spawn rates are expected even if you switch to peaceful and back. And you didn't specify whether you tested in survival/creative or spectator mode (the latter won't work, IIRC).
I suspect this is WAI; it seems they're changing it from using strange numbers to using a Potion NBT tag on the item.
If they continue to support /give commands with the old number ids, it'll probably be fixed at the same time they fix upgrading old worlds (which is
MC-82925).No, it's not. The ultimate plan is to have to craft some variant of the Ender Crystals to cause it to respawn, but for now you're supposed to make a creeper face out of clay.
And if it were intended, why is there specifically a test that causes the dragon to not automatically respawn if you have end portal blocks in the correct quadrant of the End?
The fix should be simple, they just need to check chunks -8 to 8 (on both axes) instead of only 0 to 8.
It's not just ships, the rest of the structure can be cut off too.
For that matter, the same bug may be what's preventing many of the cities from generating at all (I go to the coordinates stored in EndCity.dat and nothing is there). There's no reason these structures should be cut off at chunk boundaries.
Not a duplicate. This bug is about a recipe failing to work correctly, while that is about recipes that were just completely removed.
@[Mod] redstonehelper:
MC-84073doesn't belong here. The recipe for potion of water breathing still exists and "works" (i.e. the brewing stand attempts to brew), there's just a bug that makes it somehow not produce the correct result.This does not seem to be fixed in 15w31c. OTOH, in 15w31c using the creeper-face does turn the old portal to endstone instead of ignoring it.
I see three places in the 'apd' class that iterate from 0 to 8: purposes appear to be "find if there are any portal blocks", "replace existing portal structure with endstone", and "make sure chunks are still loaded". Only one (the "replace portal with endstone" one) was changed to iterate -8 to 8 in 15w31c.
Considering the screenshots are showing beetroot, duplicate of
MC-83002?Both wheat and beetroot, when fully grown, will attempt to drop 3 seeds (plus 1 per level of fortune). The difference is that the chance of each seed drop succeeding depends on the "age": each of the three drops for wheat has an 8/15 chance to succeed (so we expect an average of 1.6 seeds per block) while for beetroot it's only 4/15 (so only an average of 0.8 seeds per block).
Fortune I would make it barely sustainable (1.07 seeds per block) while Fortune III should make it as sustainable as wheat is without use of Fortune.
It's actually not: any block that breaks instantly with bare hands (including all crop blocks) doesn't take durability from a tool, unless it's a special case like shears on tripwire or various plants.
In my 1.8 world I use a Fortune III pickaxe to harvest carrots and potatoes (but not wheat, since I don't have any use for extra seeds), and it's still undamaged.
A shulker has to be adjacent to a solid, opaque block (I think it's basically anything you can put a torch on the side of, although the shulker uses the test for up/down too where torches use a different test for placing on top of a block), and the block it's in must be air. If either of these is not true, it will try to teleport to someplace where it is true.
This is probably working as intended.
What, the portal turning to endstone? Yeah, that's supposed to happen. But that's not at all what this bug report is about.
Glancing at the code, the bug here seems simple enough: in the random-enchanted-book generating function in 1.8.8, it fetches the list of enchantments for the item before it upgrades the minecraft:book to minecraft:enchanted_book. In 15w31c it upgrades the book before fetching the list of enchantments. Since a minecraft:enchanted_book has zero "enchantability" it gets an empty list of enchantments in the latter case.
The not dying part might be intended; I see code that even includes a debug message "Dragon died whilst in the air, ignoring damage and going in to land".
I can't reproduce the light beam in 15w31c.
Still present in 15w32b
Seed "Witch hut test" still generates mismatched bounding boxes for the hut at 8832,9456 in 15w32b.
FYI, this "bug" doesn't affect 15w31c. And in 15w32a and later, the snowballs still hit but just don't do damage or make the dragon flash red.
FYI, people: One person confirming it still exists in 15w32c is enough. There's no need for five more "me too"s that add nothing new.
Possibly fixed in 15w33a? I see changed code that looks like it might have to do with this, but I'm not in a position to test it myself at the moment.
I'm guessing someone read it on the wiki (http://minecraft.gamepedia.com/index.php?title=Splash_Potion&oldid=875610 or earlier) and assumed it was true.
Crossed out the bit about splash potions, since
MC-85865didn't get marked as a duplicate before Dinnerbone fixed it there.Found it! In 1.8.8, the "create potion effect class from metadata ('damage') number" method multiplied the duration by 0.75 at that step (MCP 9.10 PotionHelper.getPotionEffects(int, boolean), line 412), then the thrown potion just used that already-adjusted value.
The 1.9 beta versions change how that works entirely, now we have a few known PotionEffect objects shared by everything instead of creating new ones for every potion.
May be fixed in 15w34a?
Fixed in 15w34c.
After looking into the decompiled code, it looks very much like a bug.
Using MCP names, EntityAINearestAttackableTarget (uh in 15w36d) has a parameter to determine whether the mob should require line-of-sight to start tracking a target. This flag is checked by EntityAITarget.isSuitableTarget().
The AI rearrangement in 15w36a moved most of the checking for "find visible entities" into a separate function more along the lines of "find nearest visible player", and it split the logic to run different code when the AI routine is looking for players versus other mobs. In the target-player code path it lost the bit that calls EntityAITarget.isSuitableTarget(), hence it never checks for line-of-sight anymore when targeting players.
In the other code path, BTW, it looks like it lost the bit that checks for invisibility (and sneaking, although I don't think mobs ever sneak). So when a mob is looking for another mob to target, it'll find invisible mobs as if they weren't invisible.
Duplicate of
MC-87946.This seems to have been fixed in the 1.9 beta versions. It looks like 15w31a added tests for duplicate entities and logs a warning (i.e. log messages in
MC-82945) rather than adding the duplicate entities into the world.@Adrian Laschet:
You're wrong. This bug's description has three seeds that you could have used to check.
Actually, it is a bug. See class afh in 15w41b, look for recipes with "#/#" and "###" as the layout-codes. The crafting recipes exist in the code for 4 of the other 5 types but instead of saying that '#' in the pattern is one X-type plank (where X=0 to 5 as in the chart on http://minecraft.gamepedia.com/Wood_Planks/DV) they used the wrong constructor and it's saying "X oak planks". And apparently the crafting recipe code ignores the stack-size entirely, so the first matching recipe (for oak boats) gets used.
For some reason they left out a recipe for dark oak boats, which is probably another bug.
That seems unlikely.
What appears to be going on is that spawning of entities with passengers is screwed up. For example, when the spider spawner is lit it will be trying every tick to spawn spiders, but none of these spiders will be able to spawn because of the light levels. 1% of these spiders, however, will be skeleton jockeys, and apparently the skeletons wind up being half-placed in the world (there, but not in a way that they'll be ticked or saved) even though the spiders themselves aren't.
It's likely the same can happen when a natural spider jockey tries to spawn. Being able to hit the skeleton once then not again is likely because the one hit sets the temporary invulnerability which never goes away because the skeleton isn't ticked.
Zombie spawners seem similar but different: chicken jockeys will spawn the chickens, while the baby zombies will not be correctly added to the world but will be saved. Logging out and back in results in these babies being properly added to the world. The difference is probably because here the zombies (rider) are spawned first then the chicken (mount) is added, while for the skeletons it's the spider (mount) that's spawned first then the skeleton (rider) is added.
@DF: Is this a newly-created world, or is it an old world where you are finding books in chests generated in earlier versions?
You would assume wrong, because local difficulty has no effect on spawn rates on any difficulty level.
But as of 15w38a there is now one effect: chance of a lightning bolt spawning skeleton trap horses is affected by local difficulty even in easy.
It looks like they'll now drop 0–3 gunpowder and 0–2 tears, up to 0–6 gunpowder and 0–5 tears with Looting III. No idea if that's an intended change or if they accidentally added 1 to the limits when converting to loot tables.
Also zombie pigmen's flesh and nugget drops, skeletons' arrows and bones, and wither skeletons' coal and bones.
The effect of Looting on spiders' and cave spiders' eye drops was changed from increasing the percentage chance to increasing the drop amount. Same for guardians' raw fish or crystal drop.
Ghasts, skeletons, and zombie pigmen are changed back in 15w43b. Wither skeletons' bone drop is also changed back.
Wither skeletons' coal drop is now 0–2, versus 0–1 (with a 66% chance of 0) in 15w42a and earlier.
Fixed in 15w43b.
Also, BTW, squid now drop 0–2 instead of 1–3 ink sacs in 15w43b.
The change to the code does appear to be something intentional rather than an accidental breakage, as they specifically added a percentage check to the fire tick routine where nothing similar existed before. Comparing the code, with variables and functions renamed to something human-readable:
(in both cases, you can search for "doFireTick" to find the right method, this bit of code is slightly further down).
Looks like it was fixed for Guardians in 15w44b, but not Elder Guardians.
A workaround: /give @p minecraft:tipped_arrow 64 0 {Potion:minecraft:empty} will give tipped arrows that the game treats as normal for the purpose of shooting into lingering potions.
This seems like intended behavior: When a frosted ice block receives a neighbor-changed update (MCP names the method onNeighborBlockChange), it specifically checks if the neighbor that changed was also frosted ice and melts the current frosted ice block if it now has less than two frosted ice neighbors remaining.
15w44b, see class ali, method a(aho,cj,aqv,ajn).
Depends on how you define "one issue".
Still present in 15w45a.
I haven't tested it, but I suspect that since 15w43a the possibility of rare drops has been removed. They still drop XP as described here, though.
https://twitter.com/Dinnerbone/status/656854318474240001
Did this bug ever exist in the first place? Or was it just that villagers will replant whatever is in the first slot that has a seed item, so if most villagers happened to get potatoes first you'd wind up with a feedback loop that eventually eradicated other crops?
Comparing the relevant AI class between 1.8-pre2 (ze) and 15w45a (ti), the only substantive changes seem to be adding beetroots and adjusting how "fully-grown" is detected (since beetroots are fully-grown at 3 rather than 7, they added a method that could be called "isFullyGrown" instead of fetching the age and comparing to 7).
I filed
MC-92595for that issue, so this can remain focused on "please revert the change".Sigh. Given the fact that
MC-64492as filed doesn't say anything about where mobs actually spawn (it's about where the pack can start trying to spawn) and the fix for it introduced new, different spawn restrictions without correcting the situation described in the report itself without any statement as to what was intended to be changed, I find it impossible to determine what is an intentional result of the fix for that bug and what is accidental. If you heard that it was intended from a Mojangsta you should say so, otherwise let's let a Mojangsta say whether it's "works as intended".As I originally explained, it's entirely plausible that the intended result was to change "isOpaque" to "blocksMovement" (to prevent spawning within leaves, grass, cactus, and so on) and to add rails (the real new logic is more like !(!isSolidFullCube() && !canProvidePower() && !isLiquid() && !isAnyKindOfRail()) but I didn't want to get into all the extra detail to avoid confusing people), and the change to prevent spawning within a large number of redstone components was an unintentional "direct result" due to a mistake in refactoring the code.
Just making shears lose durability when breaking all blocks was enough to fix this, except for cobweb that alone makes it better to put Silk Touch on a diamond tool for general use instead. People with Silk Touch shears left from 1.8 don't matter much since those shears will lose durability and break soon enough.
Removing the need to get a Silk Touch book to make Silk Touch shears to get cobwebs is just a bonus, IMO. Slightly disappointing that 15w47b has unobtainable cobwebs that will be fixed in 15w47c/15w48a/whatever instead of just fixing that in 15w47b too (and makes me wonder if they're doing something more complicated than just making them obtainable with ordinary shears), but oh well.
Perhaps, but if so this is a better explanation of the bug than that is.
It looks like they did revert the fix for
MC-73884in 15w49b. My guess would be that they left this open because their 1.9 development branch still hasMC-73884and they only removed it from 15w49b to not have snapshots with such a crazy bug.As for "Fixed in 1.10", it was momentarily closed that way (I'd guess that was just an accident of some sort) and apparently the "fixed version" field doesn't automatically get cleared when the bug is reopened.
@Skylinerw: In 15w49a the second line of the pseudocode you quote changed to something along the lines of FireballCollisionData.theHitEntity != null && !FireballCollisionData.theHitEntity.isImmuneToFire(), probably as the fix for
MC-70327. But since, as you noted, FireballCollisionData.getBlockPos is null when the fireball hit an entity, it breaks when it gets into the other code path.More specifically, before loot tables you had a weight-1 chance of catching a stack of 10 ink sacs. Now you have a weight-10 chance of catching a single ink sac.
All in all, that reduces the probability of other junk to 83/92 of the previous chances due to the increased chances of catching ink sacs. Although the expected total ink sacs caught over many fishing attempts is also reduced to 83/92 of the previous total.
Still present in 15w50a.
I created a world with the same seed (-1338829855858950965) in 1.9.1-pre3, went to the same chunk and cleared out a room, made sure to prevent spawning everywhere else within 128 blocks of the AFK point (by flooding it all with lava, in this case), and made sure to AFK at least 24 blocks away from the room. This guy spawned in under a minute.
Generated the same seed in 1.7.2, went to the coordinates to make sure the terrain generated, then updated to 1.9.1-pre3, dug out the room, filled everything with lava, and got slimes again. Sorry.
Can't reproduce even in 1.9.2, tossing a diamond to a Zombie with CanPickUpLoot does give "Diamonds to you" when I have the prerequisite achievements.
"Resolved" and "fixed for 1.9.4" implies that there was actually a bug to begin with and that it's now fixed. In this case, it appears there never was an actual bug.
I confirm Brian McNamara's comment, though: the achievement works in 1.9.2 and 1.9.4 if you use Q to drop the diamond, but not if you drag it out of your inventory. But that's already filed as
MC-64119.Sure they do: someone needs to to add a recipe for crafting magma. They open the file that defines all the recipes, and intend to copy the last line in the list (for end stone bricks) and modify it. But they accidentally modify it without copying the line first, thus deleting the recipe for end stone bricks, and no one else looks because it's supposed to be a simple change.
If you compare the decompiled source of the recipe class between 1.9.4 (class aga) and 16w20a (class agg), it looks like this could well be what happened. Thus this bug, asking Mojang to either confirm the removal or fix it.
Sounds like it was a zombie siege and
MC-59440.Duplicate of
MC-8361.This is not fixed in the 1.10 release.
It looks like it was fixed in 16w20a with some of the refactoring for the mob variant spawn eggs, then unfixed when that was removed in 1.10-pre2.
The root of the problem seems to be that the height only gets set when the skeleton type gets set, but the code path for natural spawning never explicitly sets the skeleton type if it's a normal skeleton, so the height stays at the default (1.8) from the base "entity" class instead of getting set to 1.99 like it should be. The refactoring in 16w20a made it always call the "setSkeletonType" method, even for normal skeletons, thus fixing this bug.
Reading the skeleton's data from NBT will set the skeleton type if the "SkeletonType" tag is present, which is why reloading the world works around this bug. Spawn eggs save the new entity's data to NBT then reload it to apply anything in the EntityTag tag to the newly-spawned entity, which is why egg-spawned skeletons don't exhibit the bug. If you /summon a skeleton with SkeletonType explicitly set, that too works around the bug.