While searching the web, I finally found this bug report and it appears to be what I'm seeing:
Description: Exception ticking world
java.lang.IllegalArgumentException: n must be positive
...
I encountered this error when playing a custom map (Vechs' Sunburn Island Super Hostile) and have downloaded other custom maps (Vechs, Sethbling, etc) and had them all crash with the above error when nearing the map's border with what seems to be all 1.7.x clients, including 1.7.10. I was able to approach the map borders under the 1.6.4 client without crashing.
I know this is not the best bug report, but the OP appears to already have a handle on the cause and reproduction of this bug. Seeing the low "votes" on this issue and what appears to be no hurry to fix it, I wanted to let you guys know the kind of impact this has. [Minecraft] Map makers have all been doing the same thing in that they take a map and customize it and then create some type of border that usually involves removing all blocks and possibly replacing them with something like bedrock. This bug affects users trying to play these custom maps with a 1.7.x version and I had to search pretty hard to find this bug, but found several hits of flustered users crashing all types of custom maps when approaching the map's borders and most of them sounded like typical end users who wouldn't even know what an issue tracker is, let alone how to search or submit to one.
While searching the web, I finally found this bug report and it appears to be what I'm seeing:
Description: Exception ticking world
java.lang.IllegalArgumentException: n must be positive
...
I encountered this error when playing a custom map (Vechs' Sunburn Island Super Hostile) and have downloaded other custom maps (Vechs, Sethbling, etc) and had them all crash with the above error when nearing the map's border with what seems to be all 1.7.x clients, including 1.7.10. I was able to approach the map borders under the 1.6.4 client without crashing.
I know this is not the best bug report, but the OP appears to already have a handle on the cause and reproduction of this bug. Seeing the low "votes" on this issue and what appears to be no hurry to fix it, I wanted to let you guys know the kind of impact this has. I know that technically a custom map is no longer "vanilla" Minecraft, but using this excuse to dismiss the coding bug also dismisses most of the custom map maker community.
[Minecraft] Custom Map Makers have always done the the same thing by customizing a normal map/seed and clearing an area where they build their custom map and then making a border that usually involves removing blocks and/or replacing them with something like bedrock. This bug affects users trying to play these custom maps with a 1.7.x version and I had to search pretty hard to find this bug, but found several hits of flustered users crashing all types of custom maps when approaching the map's borders and most of them sounded like typical end users who wouldn't even know what an issue tracker is, let alone how to search or submit to one.
@Tokes:
I was reading other bug reports that have been closed as duplicate of this one and some of those bugs referenced using 3rd party tools and were flagged as "not vanilla" because of that.
It appears to boil down to the error:
...
Description: Ticking memory connection
java.lang.IllegalArgumentException: n must be positive
...
Which is something in the 1.7.x code (and in the 1.8 snapshots) that tries to divide by zero when it loads a chunk containing modifications the way some map makers make an impenetrable border to their custom map "sandboxes."
The point of my post is that this bug probably has a much bigger impact on the Minecraft community than any of the previous posts indicate. I can only speculate that users crash when approaching the border of some custom maps and blame the map maker as a bad designer without trying to get at the root cause or providing a useable bug report to Mojang. Basically the typical game playing end user will at most post something like these:
Bug still present in 1.7.10 and 14w26c.
When exiting a boat, the player appears to "land" too close and strike the boat, sending it off in [a random?] direction and can break it if it is pushed into a solid object.
Confirmed in 1.7.10. This is especially troublesome when you attempt to "beach" a boat onto Soul Sand or Half Slabs to avoid it shooting off as reported in MC-42027.
Confirmed. With Advanced OpenGL: On this bug causes most chunks, except ones near you when entering the game, to not load. Changing Render Distance from any value to any other value causes the chunks close to the player to load, but moving to a new area, new visible chunks fail to load.
Setting Advanced OpenGL:Off most chunks load, except the occasional problem noted in MC-129
Confirmed in 14w27b. Blacksmith shop spawns with the half slabs on the roof floating as normal half slabs half a block above the cobblestone as shown in 2014-07-05_21.01.29.png. In stable Minecraft 1.7.x and below, the blacksmith shop has "upside down" half slabs on the roof with no gap as shown in 2014-07-02_11.19.38.png
Confirmed in 14w27b villages generated in plains biome appear with the oak logs forming the corners of all the wooden structures facing sideways instead of vertical.
In 14w28a observed a village in a plains biome with the correct vertical orientation of logs. The roof slabs on the blacksmith shop also appear to be normal again.
Confirmed in 14w28a. Torches on the black wool/fence posts generated in villages "float" instead of being attached to the block. In the snapshots, this is also observed in the "church" in villages.
FYI torches have been observed sometimes "floating" on black wool [in villages], in mineshafts and strongholds as far back as at least Minecraft 1.4.7.
I wonder if the code noted in MC-59211 could be modified to detect where the solid block is and self-orient generated torches?
I hope this is a fancy way of saying, "we changed stuff, let us know what broke."
In 14w29b There is massive block lag:
-When breaking crops (wheat, pumpkins, etc) and blocks, it shows as still there although it does drop as an invisible entity that can be picked up. After a few seconds, the block will disappear and the entity will be visible (if not already picked up.)
-When placing blocks, there is similar lag in that the entity is invisible but can be interacted with ie placing cobblestone, you can't see it for a few seconds, but it has a hitbox so you can't walk through it but you can stand on it. Torches are similar except you can see the flame particles and it takes a few seconds for the lighting update.
-Fence gates and doors also lag and can be walked through after opening them, but take a second to display as being open.
This is more pronounced the longer the game has been running or when exploring new areas. This does not happen with 14w29a or earlier snapshots.
From http://minecraft.gamepedia.com/Slime :
"In swamps, slimes may spawn at night between the heights of 50 and 70 provided the light level is 8 or less. They spawn most often on a full moon, and never on a new moon."
Have you verified the above conditions? I have had slimes spawn in swamps in these conditions in 1.7.x and the 1.8 snapshots 14wxxx.
Marcono1234 summed it up well. Floating torches can sometimes be observed in villages, mineshafts and strongholds, pretty much all world gen.
I don't have the best seed to test, but seed 133 has a village at x-360, z360 and a mineshaft if you dig straight down at x-31, z177
Please reopen, this is not resolved.
Observed in 1.8 snapshots up to 14w31a. See http://youtu.be/rlpEBRLMrT8
This bug is more than just an annoyance of the hitbox being slightly offset, I first became aware of it because some flowers couldn't be broken until you targeted off the flower.
Notice in the video that the hitboxes for all flowers (that I could find in survival) are offset from the flowers themselves. The hitbox can be off either way on the X or Z axis and can be so far off that it's hard to target flowers (see poppy in the video.)
I noticed this comment in MC-48362:
> [Mod] Anon Ymus added a comment - 13/Feb/14 4:48 PM
> Being off-center is intended, but the hitbox can't be placed to match it.
This implies that flowers are placed randomly offset from the center of the block they are on and the hitbox is not moveable. if this is the case, the hitbox should be expanded to compensate for variable placement.
/worldborder is a great [new] tool, but it will not fix maps already in existence that fall prey to this bug.
If the cause is the code noted by the OP, it should be possible to either not drop into the loop or bug out of it under divide by 0 conditions or even go back and see how it's done in 1.6.x and earlier versions that don't crash.
I still see this in 14w31a too. I think the reduced likelihood that David Wheatley mentions may be due to strange MOB pathing in this snapshot in general, more than anything that resolves this bug.
If you build a 1 wide fence pen, they escape through the less than full blocks when the chunks unload/reload. If you build a 2 wide fence pen, they still escape by moving to the middle on one chunk reload and escaping on another.
An alternative is to pen animals in a 2 deep hole, but MOBs can still move into the solid block walls when chunks reload. This causes them to escape unless the walls are 2 or more blocks thick, then they suffocate instead.
Confirmed still in 14w31a.
I was able to reproduce this when facing North or South, but not East or West by getting as close as possible and then attempting to place the block. See the first part of http://youtu.be/EsHf9usSs2Y
Notice the player is not standing in the same space that you want the block to be, just close to it.
Confirmed in 14w31a.
In 1.7.x and I think 1.6.x and 1.5.x, bonemeal was changed so that it takes multiple bonemeal to grow things. As part of this change, it was also made so that bonemeal would not be consumed when it was activated on a crop that was fully mature.
In the snapshot, it still takes multiple bonemeal to grow crops, but it is also being consumed when used on mature crops. See the middle of http://youtu.be/EsHf9usSs2Y
Confirmed in 14w31a. Observed with passive and aggressive MOBs, but not 100% of the time. What happens is sometimes the MOB gets stuck and is unable to climb up a 1 block high gap and will stay there jumping. Have seen this with led animals including sheep and pigs and with aggressive zombies following a player.
I noticed this when breaking double chests. Looking back at 1.7.10 release, there is no breaking animation. In the snapshots (confirmed in 14w30a and 14w32b) when you break half of a double chest, both halves have the breaking animation.
IMO if the animation doesn't "fit" the chests, that's a minor display bug, but when you break half of a double chest and both halves have the breaking animation, it appears as if you will break both halves.
Blocks can't be placed when the player is too close.
What I expected to happen was...:
When placing a block, the block appears where it was placed.
What actually happened was...:
When placing a block, the block flashes in place and does not get placed. The block gets removed from inventory and some "fiddling" with inventory (place another block, place a torch, etc) sometimes makes the missing block reappear in inventory.
Steps to Reproduce:
Place a block at your feet
Stand as close to that block as possible
Attempt to place a block on top of this block, at your head level, and it will disappear.
Additional Information:
The same effect is observed when placing a block at foot level, it is just easier to reproduce when there is a block at foot level to ensure the player is not occupying the space where the block will go.
In 14w32b this happens when facing North, East and West, but I was not able to reproduce it facing South.
In 14w31a this happens when facing North or South, but I was not able to reproduce it facing East or West.
This should be enough detail, if an admin could change the description, or should a new bug be submitted?
I have observed bug MC-8471 with repeaters and this bug happens under different conditions, so (to me) it appears to be a separate issue. MC-60446 does have a better description, but it has been closed as a duplicate of MC-8471.
Confirmed in...well I've seen this since as long as I can remember playing (1.4.x?) Repeaters (and Comparators since they were introduced) have always been glitchy to place. This happens for me with Repeaters and Comparators when laying out complex redstone and appears to be different than MC-58153, which I notice when building in general. The more I think about it, This seems to have been around for awhile and I've only recently tried to reproduce and report it since my 1.8 snapshot LP. With the new launcher, I will have to go back and attempt to reproduce MC-8471 and MC-58153 in previous version.
Darin Triplett
MC-65132
While searching the web, I finally found this bug report and it appears to be what I'm seeing:
Description: Exception ticking world
java.lang.IllegalArgumentException: n must be positive
...
I encountered this error when playing a custom map (Vechs' Sunburn Island Super Hostile) and have downloaded other custom maps (Vechs, Sethbling, etc) and had them all crash with the above error when nearing the map's border with what seems to be all 1.7.x clients, including 1.7.10. I was able to approach the map borders under the 1.6.4 client without crashing.
I know this is not the best bug report, but the OP appears to already have a handle on the cause and reproduction of this bug. Seeing the low "votes" on this issue and what appears to be no hurry to fix it, I wanted to let you guys know the kind of impact this has. [Minecraft] Map makers have all been doing the same thing in that they take a map and customize it and then create some type of border that usually involves removing all blocks and possibly replacing them with something like bedrock. This bug affects users trying to play these custom maps with a 1.7.x version and I had to search pretty hard to find this bug, but found several hits of flustered users crashing all types of custom maps when approaching the map's borders and most of them sounded like typical end users who wouldn't even know what an issue tracker is, let alone how to search or submit to one.
Attached is the crash report from the same thing (approach border of an adventure map) with the 14w26c snapshot.
While searching the web, I finally found this bug report and it appears to be what I'm seeing:
Description: Exception ticking world
java.lang.IllegalArgumentException: n must be positive
...
I encountered this error when playing a custom map (Vechs' Sunburn Island Super Hostile) and have downloaded other custom maps (Vechs, Sethbling, etc) and had them all crash with the above error when nearing the map's border with what seems to be all 1.7.x clients, including 1.7.10. I was able to approach the map borders under the 1.6.4 client without crashing.
I know this is not the best bug report, but the OP appears to already have a handle on the cause and reproduction of this bug. Seeing the low "votes" on this issue and what appears to be no hurry to fix it, I wanted to let you guys know the kind of impact this has. I know that technically a custom map is no longer "vanilla" Minecraft, but using this excuse to dismiss the coding bug also dismisses most of the custom map maker community.
[Minecraft] Custom Map Makers have always done the the same thing by customizing a normal map/seed and clearing an area where they build their custom map and then making a border that usually involves removing blocks and/or replacing them with something like bedrock. This bug affects users trying to play these custom maps with a 1.7.x version and I had to search pretty hard to find this bug, but found several hits of flustered users crashing all types of custom maps when approaching the map's borders and most of them sounded like typical end users who wouldn't even know what an issue tracker is, let alone how to search or submit to one.
@Tokes:
I was reading other bug reports that have been closed as duplicate of this one and some of those bugs referenced using 3rd party tools and were flagged as "not vanilla" because of that.
It appears to boil down to the error:
...
Description: Ticking memory connection
java.lang.IllegalArgumentException: n must be positive
...
Which is something in the 1.7.x code (and in the 1.8 snapshots) that tries to divide by zero when it loads a chunk containing modifications the way some map makers make an impenetrable border to their custom map "sandboxes."
The point of my post is that this bug probably has a much bigger impact on the Minecraft community than any of the previous posts indicate. I can only speculate that users crash when approaching the border of some custom maps and blame the map maker as a bad designer without trying to get at the root cause or providing a useable bug report to Mojang. Basically the typical game playing end user will at most post something like these:
http://bugs.mojang.com/browse/MC-55498
http://www.minecraftforum.net/topic/191908-ctmcollection-vechs-super-hostile-series/page__st__60620
http://www.minecraftforum.net/topic/1818607-puzelementsco-op174/
http://www.planetminecraft.com/forums/ticking-memory-connection-t402397.html
http://www.minecraftforum.net/topic/2770100-help-me/
http://www.minecraftforum.net/topic/2281720-ticking-memory-connection-crash/#entry27796384
Bug still present in 1.7.10 and 14w26c.
When exiting a boat, the player appears to "land" too close and strike the boat, sending it off in [a random?] direction and can break it if it is pushed into a solid object.
Confirmed in 1.7.10. This is especially troublesome when you attempt to "beach" a boat onto Soul Sand or Half Slabs to avoid it shooting off as reported in
MC-42027.Confirmed. With Advanced OpenGL: On this bug causes most chunks, except ones near you when entering the game, to not load. Changing Render Distance from any value to any other value causes the chunks close to the player to load, but moving to a new area, new visible chunks fail to load.
Setting Advanced OpenGL:Off most chunks load, except the occasional problem noted in MC-129
NVIDIA GeForce GTS 450
Win7 SP1
Java 7u60 x64
Minecraft 14w27b
Confirmed in 14w27b. Blacksmith shop spawns with the half slabs on the roof floating as normal half slabs half a block above the cobblestone as shown in 2014-07-05_21.01.29.png. In stable Minecraft 1.7.x and below, the blacksmith shop has "upside down" half slabs on the roof with no gap as shown in 2014-07-02_11.19.38.png
Confirmed in 14w27b villages generated in plains biome appear with the oak logs forming the corners of all the wooden structures facing sideways instead of vertical.
In 14w28a observed a village in a plains biome with the correct vertical orientation of logs. The roof slabs on the blacksmith shop also appear to be normal again.
Confirmed in 14w28a. Torches on the black wool/fence posts generated in villages "float" instead of being attached to the block. In the snapshots, this is also observed in the "church" in villages.
FYI torches have been observed sometimes "floating" on black wool [in villages], in mineshafts and strongholds as far back as at least Minecraft 1.4.7.
I wonder if the code noted in MC-59211 could be modified to detect where the solid block is and self-orient generated torches?
I hope this is a fancy way of saying, "we changed stuff, let us know what broke."
In 14w29b There is massive block lag:
-When breaking crops (wheat, pumpkins, etc) and blocks, it shows as still there although it does drop as an invisible entity that can be picked up. After a few seconds, the block will disappear and the entity will be visible (if not already picked up.)
-When placing blocks, there is similar lag in that the entity is invisible but can be interacted with ie placing cobblestone, you can't see it for a few seconds, but it has a hitbox so you can't walk through it but you can stand on it. Torches are similar except you can see the flame particles and it takes a few seconds for the lighting update.
-Fence gates and doors also lag and can be walked through after opening them, but take a second to display as being open.
This is more pronounced the longer the game has been running or when exploring new areas. This does not happen with 14w29a or earlier snapshots.
14w29b
Win7 x64 SP1
JRE 7u60 x64
From http://minecraft.gamepedia.com/Slime :
"In swamps, slimes may spawn at night between the heights of 50 and 70 provided the light level is 8 or less. They spawn most often on a full moon, and never on a new moon."
Have you verified the above conditions? I have had slimes spawn in swamps in these conditions in 1.7.x and the 1.8 snapshots 14wxxx.
Marcono1234 summed it up well. Floating torches can sometimes be observed in villages, mineshafts and strongholds, pretty much all world gen.
I don't have the best seed to test, but seed 133 has a village at x-360, z360 and a mineshaft if you dig straight down at x-31, z177
Please reopen, this is not resolved.
Observed in 1.8 snapshots up to 14w31a. See http://youtu.be/rlpEBRLMrT8
This bug is more than just an annoyance of the hitbox being slightly offset, I first became aware of it because some flowers couldn't be broken until you targeted off the flower.
Notice in the video that the hitboxes for all flowers (that I could find in survival) are offset from the flowers themselves. The hitbox can be off either way on the X or Z axis and can be so far off that it's hard to target flowers (see poppy in the video.)
I noticed this comment in
MC-48362:> [Mod] Anon Ymus added a comment - 13/Feb/14 4:48 PM
> Being off-center is intended, but the hitbox can't be placed to match it.
This implies that flowers are placed randomly offset from the center of the block they are on and the hitbox is not moveable. if this is the case, the hitbox should be expanded to compensate for variable placement.
/worldborder is a great [new] tool, but it will not fix maps already in existence that fall prey to this bug.
If the cause is the code noted by the OP, it should be possible to either not drop into the loop or bug out of it under divide by 0 conditions or even go back and see how it's done in 1.6.x and earlier versions that don't crash.
I still see this in 14w31a too. I think the reduced likelihood that David Wheatley mentions may be due to strange MOB pathing in this snapshot in general, more than anything that resolves this bug.
If you build a 1 wide fence pen, they escape through the less than full blocks when the chunks unload/reload. If you build a 2 wide fence pen, they still escape by moving to the middle on one chunk reload and escaping on another.
An alternative is to pen animals in a 2 deep hole, but MOBs can still move into the solid block walls when chunks reload. This causes them to escape unless the walls are 2 or more blocks thick, then they suffocate instead.
Confirmed still in 14w31a.
I was able to reproduce this when facing North or South, but not East or West by getting as close as possible and then attempting to place the block. See the first part of http://youtu.be/EsHf9usSs2Y
Notice the player is not standing in the same space that you want the block to be, just close to it.
Confirmed in 14w31a.
In 1.7.x and I think 1.6.x and 1.5.x, bonemeal was changed so that it takes multiple bonemeal to grow things. As part of this change, it was also made so that bonemeal would not be consumed when it was activated on a crop that was fully mature.
In the snapshot, it still takes multiple bonemeal to grow crops, but it is also being consumed when used on mature crops. See the middle of http://youtu.be/EsHf9usSs2Y
Confirmed in 14w31a. Observed with passive and aggressive MOBs, but not 100% of the time. What happens is sometimes the MOB gets stuck and is unable to climb up a 1 block high gap and will stay there jumping. Have seen this with led animals including sheep and pigs and with aggressive zombies following a player.
MC-3073and all other flower hitbox bugs I could find are flagged resolved but the issue still exists.I noticed this when breaking double chests. Looking back at 1.7.10 release, there is no breaking animation. In the snapshots (confirmed in 14w30a and 14w32b) when you break half of a double chest, both halves have the breaking animation.
IMO if the animation doesn't "fit" the chests, that's a minor display bug, but when you break half of a double chest and both halves have the breaking animation, it appears as if you will break both halves.
in 14w32b bonemeal is no longer consumed when used manually on mature crops. Have not confirmed dispensers in this snapshot.
Blocks can't be placed when the player is too close.
What I expected to happen was...:
When placing a block, the block appears where it was placed.
What actually happened was...:
When placing a block, the block flashes in place and does not get placed. The block gets removed from inventory and some "fiddling" with inventory (place another block, place a torch, etc) sometimes makes the missing block reappear in inventory.
Steps to Reproduce:
Place a block at your feet
Stand as close to that block as possible
Attempt to place a block on top of this block, at your head level, and it will disappear.
Additional Information:
The same effect is observed when placing a block at foot level, it is just easier to reproduce when there is a block at foot level to ensure the player is not occupying the space where the block will go.
In 14w32b this happens when facing North, East and West, but I was not able to reproduce it facing South.
In 14w31a this happens when facing North or South, but I was not able to reproduce it facing East or West.
This should be enough detail, if an admin could change the description, or should a new bug be submitted?
I have observed bug
MC-8471with repeaters and this bug happens under different conditions, so (to me) it appears to be a separate issue.MC-60446does have a better description, but it has been closed as a duplicate ofMC-8471.Confirmed in...well I've seen this since as long as I can remember playing (1.4.x?) Repeaters (and Comparators since they were introduced) have always been glitchy to place. This happens for me with Repeaters and Comparators when laying out complex redstone and appears to be different than
MC-58153, which I notice when building in general. The more I think about it, This seems to have been around for awhile and I've only recently tried to reproduce and report it since my 1.8 snapshot LP. With the new launcher, I will have to go back and attempt to reproduceMC-8471andMC-58153in previous version.