I can confirm that the nether fortress generation has changed. We were experiencing the same symptoms on a SMP server. No Wither Skeletons in existing fortresses (generated in 1.3, no spawns in 1.4.7 or 1.5.2). However 1.5.2 fortresses generated wither skeletons in 1.5.2)
However In nether travels I encountered a fortress on the edge of newly generated chunks.
There fortress there was split along the 'chunk error' boundary, with bridges in different locations along those edges. Skeletons spawned in the new parts, but did not in the old parts.
To fix this problem for the SMP server without destroying the central hubs and tunnels. we simple deleted (after backup) all DIM-1 region files that had a number smaller than -2 or larger that 1. That deleted all chunks further than 1Km from 0,0 in the nether. (equivalent to roughly 8.5 K in overworld)
New fortresses found beyond those bounds since the reset are working just fine, players are happy to get Quartz and do Wither Skeleton Hunting.
For 1.6 with Horses tied to new chunks, we plan to do a similar reset of overworld for places further than 8Km from Spawn.
NOTE Region files are basically 1/2 Km square regions (actually 512x512 blocks) holding the equivalent of 32 chunks. Deleting the files is a lot simplier than using MCedit!
Basically if you fix the mapping of nether fortress to wither skeleton spawning for older maps. You screw it up for newer maps.
The only way they could fix this is to include the generation code for the old minecraft with the new minecraft, and apply it on a chunk by chunk bases to the generated world. Remember worlds can be a mix of old and new generated chunks.
If they do this for this, then they will need to do it for many other things, such as horse spawning, witch huts, and whatever else is added in the future, that has specific world object attachments. I doubt they see that as a good move.
So My suggestion... just reset (delete) parts of the world as I detailed in a previous comment, and go to the new chunks.
NOTE: the fortress locations has not changed, just the way the fortress is generated, as such you will often get a few spots where wither skeletons will spawn, where the old and new coexist, providing blocks for the wither to spawn on. If you find a spot, expand the levels and look for where they are spawning. Remember crossroads provide a 19x10x19 spawn volume, and if you can find it. great.
Compare coords in a new world (with creative) you re-generated with the same seed, the locating those same coords in your old world is another solution to finding a good 'wither skeleton spawn volumes', without resetting the chunks.
There are solutions folks!
Actually I would not mind knowing the fortress differences myself, by exploring the same fortress in two such world generations. I mean is the 'seed' point the lava room? (just as the 'well' is the seed point for overworld villages). If so perhaps the lava rooms match up?
Can anyone provide more concrete difference information? Rather than simply winge that things have changed!
I heard in the latest GenerickB Video that Dinnerbone told him that 1.7 will have major terrain generator re-working. Probably adding more biomes. So I would expect some major differences then.
Alejandro...
It was in the GenerkB's 'Final Tour of MindCrack'. But as it was a passing comment of a passing comment I would not put too much faith in it yet.
Jeb...
The big question is..
What is this change? Spawn within a distance of a nether fort? Only spawn on nether brick? (the latter would be logical)
It looks to me (not confirmed) like the 'fix' was simply to map 1.6.2 spawning with how fortresses now generate in1.6, which is different to fortress generation in 1.5.2 (and 1.4.7)
What a pain. It changed from 1.3.2 to 1.4.7, and now it has changed again.
Note that village generation also changed between these two releases, but villagers breed based on doors (houses - if you really could call them that) and not on village structure so the changes have no impact on spawning.
Really what a nether fortress needs is something that defines the spawning area. This way when fortress generation change, spawns don't change in already generated structures.
Tying the generation with the spawn area, was I think a bad idea.
The only other such 'tie' between generation and spawning, that I know about, is between mooshrooms and mushroom biome. But mooshrums also breed, are not generally killed, But they can spawn, but only spawn if server cap allows, and then only if a grass area is placed in a mushroom biome. Not really a problem as they generally don't 'spawn'.
Really the ideal solution that mojang could make, would be.. Make fort mobs spawn around a special spot (lava room? - is this the seed point for forts?) and only on nether brick. That would solve almost all the current 'fort generation changed' problems, that we are seeing.
But what version did you run when you generated the original fortress?
Both bits of information is important! Generation version and 'not-spawning' version.
Better still any zombie that hits a priest is either cured or destroyed on the spot (with a special effect), due to the all powerful nature of their God, Notch.
This means any village with a priest will generally have a pocket of safely around the priest of the village, though it would probably cease to be a village on hard mode as all the doors will have been removed, and the villagers all start wandering away.
Perhaps the blacksmith automatically replaces doors when he sees an appropriate doorway frame. And farmers automatically harvests and replants any full grow grown crop they walk over, but keeps the product! That means the farms get cycled, but players can not benefit! Unless they harvest the crop before the farmer walks on it.
I placed these around the edges of my artificial trading village and the zombie counts were kept very manageable. Since then I replaced the fences with carpet as per DocM's solution, to reduce pathing lag even further.
And sure it does not help much with zombies trapped underground, unless you create a path from underground caves to the surface, and lit up most of the caves, but it does make a big difference, especially if you live next to a desert, as I was in this situation.
That water entrance is just to stop mobs, nothing about preventing lag. It is also slow for the player to get through. There are other better open mob-proof entrance designs.
The zombie lag bug is triggered by zombies failing to find a path to a villager. It causes them to continuously look for and failing to find alternative paths.
That is not to say that a zombie will find a path that they can actually use to reach a villager! And that is the key to these zombie lag mitigation methods (and even some new zombie sorting techniques).
So things that will cause zombies to fail to find a path.....
While things zombies think is a path but does not let them through. That is zombies will generally try to use them and either mob at the blockage, or fall though.
open trapdoors (as a floor above a pit - must be two wide, or baby zombies get over)
Closed trapdoors (as a door) in a 2 block high doorway
floating carpet (no roof needed, neither villagers or zombies will jump up, you can)
snowblocks
one block of cactus with string on top and space to jump up.
a 8 block fall
The key fix needed is....
In this snapshot, are structures now being saved in the world file? Not just location (which would be fine for a witch hut), but actual fortress elements? If that is now being done, then this should be the last time it breaks. Otherwise, all bets are off!
This bug is starting to become very annoying. Currently everyone just accepts this as being 'normal play'. But really it just makes any form of trading village unsafe and impossible to mob proof.
It is time that this bug be properly fixed, especially as the fix is simple enough that it would only take mojang a minute or so to apply it for the next snapshot release.
Strongholds are not effected, as they currently do not have any structure specific spawning. End portal and Feesh is handled by the specific blocks that exist in the world, and not the structure location.
Same is true for mooshrums on mushroom biomes. It is biome related which is already saved as part of the world.
The problems are with Witch Huts (for witched), and Nether Forts (wither skeleton and blaze). Blaze however is not a big issue are fortresses also have blaze spawners.
Back ports for 1.4 and 1.5 would be nice to allow updates for those older worlds.
This bug becomes especially annoying when mapping. Mapping much faster to do from a boat, and with the multiple stops, starts, turns and close (cautious) land approaches, the desync between player and server seems to become quite large.
The desync seems to be due to speed and direction changes, not keeping inline. Having the server report the players real location (in boat, horse or otherwise) more often may resolve the issues.
The idea of a resync button, that not only re-loads your location from from server, but also reports yoru correct position to other clients, would be very useful. We have many other F3 re-sync functions are available and either attching this to one of those or as a extra key would be useful. Especially while the nether portal de-sync is present, or any other de-sync situations that may turn up in the future.
I did find one nice way of knowing where the server thinks you are while you are in a boat.
I started mapping using not just boats but a donkey (for extra storage). If you lead your donkey/mule/horse before getting in the boat, the animal will swim with you on the lead, just behind your REAL location. You can still travel just as fast as normal (which can look really funny) but the animal will track you real location, according to the server.
You can now navigate around islands and land by looking at the location of your animal, even if that animal is a LONG way away due to de-sync. Quite often I find myself boating behind my donkey, because the server thinks I am ahead of myself.
It is a good way of experimenting to see exactly what situations cause de-sync, expectantly with speed. Something you can not easily do using lily pads.
I do not think it is just speed, that causes de-sync, It also seems to be direction and acceleration dependant.
I found a way to let you know exactly where the server 'thinks' you are in the boat.
Attach a lead to an animal (any animal, except oclots, chickens or pigs are plentiful) before getting in the boat. I use my mule as I am typiclly using boats when mapping, and my mule carries extra goods.
As you travel the animal will always be just behind your REAL location according to the server, so as your location in the client de-syncs, you can still see using the animal your real location, especially as you approach that island. You can then slow down, hop out on the island, or relog, as you need without destorying your boat.
NOTE this does not help with preventing mid-ocean squid crashes, or lilly pad crashes, but it does make it easier to not crash your boat every time you approach land. It also can be used to figure out exactly what things cause you to de-sync (lag, turns, acceleration, whatever it is)
The MindCracker BdoubleO100 has a recent video (Mindcrack Epsiode 57) where he was experiencing this bug in a sever way. That is jumping out of the boat and appearing a long way off shore.
Simply put, because replacement trades only check for a lower price, the overall level of enchanted books only gets smaller until you are only left with a 'common', or cheap (5 Emerald) level 1 enchanted book.
Basically librarians offering the better and rare enchanted books such as Sharpness-V, Smite-V, etc, will change to 'cheaper' books with enchantments that are not nearly as good, and are far more 'common'.
A simple fix would be that if a enchanted book trade is 'changed', to ignore the price, and just change the enchantment, regardless of price or level of enchantment.
WARNING: There is a seperate bug in that the price of some level V enchants where the price requested is larger than 64 Emeralds and thus unpayable in the current trading interface. That should be fixed (capped at 64?) at the same time.
agilerelic... that is irrelevant to the discussion. The problem is not over population, or villagers building new houses. It is the problem that in a large village, the villagers like each other so much they all decide to live in one house, even though there are LOTS of houses in the village.
The crowding also causes them to climb ladders to village roofs, or even into jungle trees, which they otherwise would not do.
There is code that was added when villages were first created, to make villagers 'socalize'. This worked fine for normal small villages. But there is no code to make villagers want a bit of elbow room and spread out to prevent overcrowding.
We humans, like to socialize, but we also do not like to over crowd. Even in a 'party' everyone has a personal space. Of course we learned to suspend that instinct in special situations such as for lifts, or peak hour trains and buses, but generally we try not to 'crowd'. Especially in a home or other social situations.
@Cailan And why not. It is a bug, this is the fix. That is what bug forums are for.
Actually if they do fix it, they better fix the bug involving the start point of a zombie siege.
They should start at the edge of the villager radius, not in the middle of the village.
Actually it also gives village Iron Golems more of a chance to take care of a siege that is (with the bug fix) heading into the village toward the juicy villagers.
I have watched iron golems in a village with large dark areas. They handle quite large hordes (non seige) zombies that are approaching the villagers, quite well.
But Iron golem will not handle a bugged zombie seige that appears in the middle of the village in side the house that the villages are hiding in. I have seen large trading villages decimated by a single siege on bucket servers (siege start bug fixed, but not start location), when a horde appeared inside the building the villagers were piled into.
From tests seen on the forum so of the new 'spread' may be caused by farmers now migrating toward farms.
It is hard to say if it is fixed or not, except maybe in a village that has no farmers.
The general migration toward North-West is an issue with all mobs (and there should be a separate bug report about that). If villager AI is fixed this general migration should not be a problem with villagers.
This bug breaks more things in unexpected ways than it helps.
There are other ways to generate BUD's that does not involved this issue. So it will break devices that use it. These devices are only using it because that could. NOT because they should be using it.
Better to fix this problem once and for all than just stick your head in the sand!!!!
FIX IT!
If you are not sure... put it to the serious redstone players.... Sethbling, Etho, DocM, and other players on the ZipCrowd. Most of them have already said they would prefer it fixed, rather than the current illogical behaviour.
Even if the 0 items in slot problem is fixed, wouldn't you still get a problem in that farmers will eventually get clogged up with 8 slots of seeds. Wheat farming produces a lot of excess seed, as any player would know. So once all the land has been farmed, and everyone has enough bread, farmers would slowly become weighted down with excess seeds.
Most players who do farming only keeps one stack of seeds for replanting, after that seeds are either used for chicken breeding or ignored. Villager farmers really should do the same. One stack of seeds maximum. Actually one stack of anything should be AI limit for any villager, and picked up items should go to any existing stack, not just the first available slot (which produces the equivalent of a hopper clog). That way villagers can have up to 8 different items as appropriate for their continued "evolution".
This would also eliminate the '0 item slot' problem, as a way of reserving a slot for a particular item, but without a villager getting bogged down with 8 slots of 0 or 64 items of all the same type.
It may also allow farmers to specialize or prefer to plant one particular item (first non-empty plantable item slot). But will plant other items if they run out of there preferred item. Farmers then would have a slot for seed, wheat, bread, potatoes, and carrots and that is all. The order determining there farming preference.
Please fix the related (but not quite the same) bug MC-7488.
Without that bug being fixed as well, zombie sieges can be very annoying, as they can and will spawn in the middle of houses and trading booths.
All the wandering I have seen has mostly been the result of the north-west bias, which is supposedly fixed.
However the fact that even with this bais, mobs tended to swim out to sea shows that most passive mobs do not even try to stay in grassy areas. They do migrate toward sky lit areas, but not grass. or at least avoid 'water' area.
Ideally passive land mobs (sheep, cows, chickens, and now rabbits) should make a few random destination rolls, then pick preferentially sky lit, grass (mycellium for mooshrums), then dry land, and only select water, if all the random choices was water.
That is not to say mobs won't swim across rivers or lakes to get to the grass on the other side, but at least they shouldn't drift out to sea, unless left no choice.
Note that this bug is also probably what allows the current piston-less glass item elevators to work. Enities can go into the fence block, but then they want to rise up into the item elevator as they are now 'inside' a block.
Chickens stuck in a fence corner will lay eggs but the eggs are 'ejected' from that fenced block.
For sheep and cows, placing carpet on top of the fence post in the corner stops the issue, as they hit the carpet collision box.
Perhaps a solution is to have unbreaking enchant not work for the last use or last few uses.
That is when a pick only has one use left, it always breaks, regardless of unbreaking enchant. That way randomness caused by server-client sync does not play a part.
As this may happen quickly perhaps the last 5 or 10 uses of a tool does not allow unbreaking, so as to ensure client-servers are in sync in a tools last moments of life.
This happens all the time on multiplier servers where you have a Trading Village a lot of people use.
We have now lost on the order of a dozen perfect paper traders through this bug.
However as 1.8 changes everything, and resets at a 20% chance on any trade, I doubt this bug will ever be resolved.
The question is, and this is very hard to check, if on the rare occasion you had to trade all the villages trades, before the villager resets, if the disconnect (and chunk unload) happens, could you get a village with all trades permanently locked?
This would be a super rare occurence (more like 2 orders of magnitude rarer than 1.7), but I can see it being possible that this bug can happen in 1.8. However as you can not have perfect villagers, I doubt it is as important. The exception maybe with a librarian with one of the ultra good enchanted book trades (unbreaking III, sharpness V, etc).
This is NOT a bug. There is a ultra rare chance of a 9th slot gold trade. I myself have seen it.
also in 1.8 there are not perfect villagers, so even if classed as a bug, it will be of no consequence shortly.
However perfect paper traders (8th slot) has been determined to happen roughly 1 in 11 librarians (from a 100 million sample , if you can get all the librarian trades unlocked, which can take a lot of emeralds and work. So if this happens, you are better off just continuing your search.
PS: 2 perfect paper traders are better than 1, as you can then jump from one to the other, while they reset. Also I find written book traders better still, if you have a ink farm.
it is the same bug. but this one is more complete are to reasons and cause of the problem.
Bad inventory handling, with some stupid bugs involving dropping 'zero' items, due to a bad conditional.
James... Dedicated slots is a good idea, but as there is only 8, it may limit other posibilities in the future. Better for villagers to have a little more inventory management smarts, which is what this bug is really about.
Basically villagers need to merge slots, and limit the maximum amount of seeds they pick up. Also only farmers should actually be able to pick up seeds and wheat, which I thought (from the previous corrupt inventory bug) is what happened.
Farmers being able to craft bread for their own use, and then throw excess bread would also make a lot more sense than throwing wheat that turns into bread as part of the throw. It would however mean that farmers given lots of wheat to fill inventory slots, will instead fill one slot, then have the other slots filled with bread. It would mean more wheat would be needed to 'initialise' the farmer, and they would have enough food they they would not be interested in harvesting more wheat. Thus break some of the current wheat farmer, or bonemeal to wheat auto-farms they currently exist.
One thing. Farmers buying wheat (which essentially disappears rather then being used) to me makes no sense, when they have a full inventory of wheat. But it does help game play.
+Ryan Leach Mobs don't stand in shallows they swim!
if that was to change it would likely break a lot of things, especially mob-a-vators, something that has been in the game since it was beta!
However the AI has been resolved. There is a different bug involving mobs not swimming very fast if they decide to change direction while in water, resulting in mobs getting stuck in ponds and rivers, especially chickens, but that is not this bug.
Is this bug still a problem... That is a accelerating motion of items actually pushed into a block by piston or dropper?
Really it is a bigger problem for 'glass' item elevators than tree farms, and the main decription to be updated to reflect that.
This also does not appear to be the same as a motionless object that is suddenly inside a block due to a closing trapdoor or cobble fence connecting. In that case the items rise up VERY slowly without acceleration. But it can take about 4 to 5 minutesfor the items to rise up 100 blocks or more, making items despawn before reaching the top a very tall glass item elevator.
Ideally, what should happen is that item motion when inside a block degrades to a fixed vertical speed, say about double the speed you get from an item at rest finding itself inside a block. It should not accelerate.
md_5 said... "By killing the target of an angry pigmen, you make yourself the target."
Which does not really make sense. A gast hits a pigman, pigman gets angry at gast. you kill the gast, so pigmen get angry at you (or someone else that is closer). Really you helped the pigmen by killing the thing that hurt it. Why should it get angry at you!
At least they stopped pigmen continuously making more pigmen angry, unless you hit them again. That bug was the real nasty one of previous releases!
Anthony Thyssen
MC-26857
I can confirm that the nether fortress generation has changed. We were experiencing the same symptoms on a SMP server. No Wither Skeletons in existing fortresses (generated in 1.3, no spawns in 1.4.7 or 1.5.2). However 1.5.2 fortresses generated wither skeletons in 1.5.2)
However In nether travels I encountered a fortress on the edge of newly generated chunks.
There fortress there was split along the 'chunk error' boundary, with bridges in different locations along those edges. Skeletons spawned in the new parts, but did not in the old parts.
To fix this problem for the SMP server without destroying the central hubs and tunnels. we simple deleted (after backup) all DIM-1 region files that had a number smaller than -2 or larger that 1. That deleted all chunks further than 1Km from 0,0 in the nether. (equivalent to roughly 8.5 K in overworld)
New fortresses found beyond those bounds since the reset are working just fine, players are happy to get Quartz and do Wither Skeleton Hunting.
For 1.6 with Horses tied to new chunks, we plan to do a similar reset of overworld for places further than 8Km from Spawn.
NOTE Region files are basically 1/2 Km square regions (actually 512x512 blocks) holding the equivalent of 32 chunks. Deleting the files is a lot simplier than using MCedit!
I have extreme doubts that this will be fixed.
Basically if you fix the mapping of nether fortress to wither skeleton spawning for older maps. You screw it up for newer maps.
The only way they could fix this is to include the generation code for the old minecraft with the new minecraft, and apply it on a chunk by chunk bases to the generated world. Remember worlds can be a mix of old and new generated chunks.
If they do this for this, then they will need to do it for many other things, such as horse spawning, witch huts, and whatever else is added in the future, that has specific world object attachments. I doubt they see that as a good move.
So My suggestion... just reset (delete) parts of the world as I detailed in a previous comment, and go to the new chunks.
NOTE: the fortress locations has not changed, just the way the fortress is generated, as such you will often get a few spots where wither skeletons will spawn, where the old and new coexist, providing blocks for the wither to spawn on. If you find a spot, expand the levels and look for where they are spawning. Remember crossroads provide a 19x10x19 spawn volume, and if you can find it. great.
Compare coords in a new world (with creative) you re-generated with the same seed, the locating those same coords in your old world is another solution to finding a good 'wither skeleton spawn volumes', without resetting the chunks.
There are solutions folks!
Actually I would not mind knowing the fortress differences myself, by exploring the same fortress in two such world generations. I mean is the 'seed' point the lava room? (just as the 'well' is the seed point for overworld villages). If so perhaps the lava rooms match up?
Can anyone provide more concrete difference information? Rather than simply winge that things have changed!
I heard in the latest GenerickB Video that Dinnerbone told him that 1.7 will have major terrain generator re-working. Probably adding more biomes. So I would expect some major differences then.
Alejandro...
It was in the GenerkB's 'Final Tour of MindCrack'. But as it was a passing comment of a passing comment I would not put too much faith in it yet.
Jeb...
The big question is..
What is this change? Spawn within a distance of a nether fort? Only spawn on nether brick? (the latter would be logical)
Basically... Just saying it is fixed is not enough... What was fixed?
match generation of new fortresses? match generation of old fortresses
What version? What will break?
Generation version VS Spawning version?
It looks to me (not confirmed) like the 'fix' was simply to map 1.6.2 spawning with how fortresses now generate in1.6, which is different to fortress generation in 1.5.2 (and 1.4.7)
What a pain. It changed from 1.3.2 to 1.4.7, and now it has changed again.
Note that village generation also changed between these two releases, but villagers breed based on doors (houses - if you really could call them that) and not on village structure so the changes have no impact on spawning.
Really what a nether fortress needs is something that defines the spawning area. This way when fortress generation change, spawns don't change in already generated structures.
Tying the generation with the spawn area, was I think a bad idea.
The only other such 'tie' between generation and spawning, that I know about, is between mooshrooms and mushroom biome. But mooshrums also breed, are not generally killed, But they can spawn, but only spawn if server cap allows, and then only if a grass area is placed in a mushroom biome. Not really a problem as they generally don't 'spawn'.
Really the ideal solution that mojang could make, would be.. Make fort mobs spawn around a special spot (lava room? - is this the seed point for forts?) and only on nether brick. That would solve almost all the current 'fort generation changed' problems, that we are seeing.
But what version did you run when you generated the original fortress?
Both bits of information is important! Generation version and 'not-spawning' version.
So the only fortress that we know works in 1.6.2. had to be generated in 1.6.2
That really sucks!
Priests curing zombies. Nice idea.
Better still any zombie that hits a priest is either cured or destroyed on the spot (with a special effect), due to the all powerful nature of their God, Notch.
This means any village with a priest will generally have a pocket of safely around the priest of the village, though it would probably cease to be a village on hard mode as all the doors will have been removed, and the villagers all start wandering away.
Perhaps the blacksmith automatically replaces doors when he sees an appropriate doorway frame. And farmers automatically harvests and replants any full grow grown crop they walk over, but keeps the product! That means the farms get cycled, but players can not benefit! Unless they harvest the crop before the farmer walks on it.
What could librarians and butchers do?
Thank you!!! I had to open a new bug (
MC-26857) to report this bug was not fixed!Long before DocM started dealing with Zombies I had developed this solution
https://www.flickr.com/photos/antofthy/9345065373
I placed these around the edges of my artificial trading village and the zombie counts were kept very manageable. Since then I replaced the fences with carpet as per DocM's solution, to reduce pathing lag even further.
And sure it does not help much with zombies trapped underground, unless you create a path from underground caves to the surface, and lit up most of the caves, but it does make a big difference, especially if you live next to a desert, as I was in this situation.
That water entrance is just to stop mobs, nothing about preventing lag. It is also slow for the player to get through. There are other better open mob-proof entrance designs.
The zombie lag bug is triggered by zombies failing to find a path to a villager. It causes them to continuously look for and failing to find alternative paths.
That is not to say that a zombie will find a path that they can actually use to reach a villager! And that is the key to these zombie lag mitigation methods (and even some new zombie sorting techniques).
So things that will cause zombies to fail to find a path.....
solid block walls, fences, fence gates, iron doors, extended piston heads
While things zombies think is a path but does not let them through. That is zombies will generally try to use them and either mob at the blockage, or fall though.
open trapdoors (as a floor above a pit - must be two wide, or baby zombies get over)
Closed trapdoors (as a door) in a 2 block high doorway
floating carpet (no roof needed, neither villagers or zombies will jump up, you can)
snowblocks
one block of cactus with string on top and space to jump up.
a 8 block fall
Anything else?
The key fix needed is....
In this snapshot, are structures now being saved in the world file? Not just location (which would be fine for a witch hut), but actual fortress elements? If that is now being done, then this should be the last time it breaks. Otherwise, all bets are off!
Well this problem look like it is now a non-issue with the 1.7 snapshots. At least in first reports being seen on the forums.
This bug is starting to become very annoying. Currently everyone just accepts this as being 'normal play'. But really it just makes any form of trading village unsafe and impossible to mob proof.
It is time that this bug be properly fixed, especially as the fix is simple enough that it would only take mojang a minute or so to apply it for the next snapshot release.
Strongholds are not effected, as they currently do not have any structure specific spawning. End portal and Feesh is handled by the specific blocks that exist in the world, and not the structure location.
Same is true for mooshrums on mushroom biomes. It is biome related which is already saved as part of the world.
The problems are with Witch Huts (for witched), and Nether Forts (wither skeleton and blaze). Blaze however is not a big issue are fortresses also have blaze spawners.
Back ports for 1.4 and 1.5 would be nice to allow updates for those older worlds.
This bug becomes especially annoying when mapping. Mapping much faster to do from a boat, and with the multiple stops, starts, turns and close (cautious) land approaches, the desync between player and server seems to become quite large.
The desync seems to be due to speed and direction changes, not keeping inline. Having the server report the players real location (in boat, horse or otherwise) more often may resolve the issues.
The idea of a resync button, that not only re-loads your location from from server, but also reports yoru correct position to other clients, would be very useful. We have many other F3 re-sync functions are available and either attching this to one of those or as a extra key would be useful. Especially while the nether portal de-sync is present, or any other de-sync situations that may turn up in the future.
I did find one nice way of knowing where the server thinks you are while you are in a boat.
I started mapping using not just boats but a donkey (for extra storage). If you lead your donkey/mule/horse before getting in the boat, the animal will swim with you on the lead, just behind your REAL location. You can still travel just as fast as normal (which can look really funny) but the animal will track you real location, according to the server.
You can now navigate around islands and land by looking at the location of your animal, even if that animal is a LONG way away due to de-sync. Quite often I find myself boating behind my donkey, because the server thinks I am ahead of myself.
It is a good way of experimenting to see exactly what situations cause de-sync, expectantly with speed. Something you can not easily do using lily pads.
I do not think it is just speed, that causes de-sync, It also seems to be direction and acceleration dependant.
I found a way to let you know exactly where the server 'thinks' you are in the boat.
Attach a lead to an animal (any animal, except oclots, chickens or pigs are plentiful) before getting in the boat. I use my mule as I am typiclly using boats when mapping, and my mule carries extra goods.
As you travel the animal will always be just behind your REAL location according to the server, so as your location in the client de-syncs, you can still see using the animal your real location, especially as you approach that island. You can then slow down, hop out on the island, or relog, as you need without destorying your boat.
NOTE this does not help with preventing mid-ocean squid crashes, or lilly pad crashes, but it does make it easier to not crash your boat every time you approach land. It also can be used to figure out exactly what things cause you to de-sync (lag, turns, acceleration, whatever it is)
Stuart... this is not a forum for 'general lag' but for zombie pathing lag.
Loren.. same thing.
I have been seeing no issues with zombie pathing lag anymore either.
The MindCracker BdoubleO100 has a recent video (Mindcrack Epsiode 57) where he was experiencing this bug in a sever way. That is jumping out of the boat and appearing a long way off shore.
I wouldn't want this fixed! It makes a useful baby mob separator!
It is still a concern... nothing has changed.
Simply put, because replacement trades only check for a lower price, the overall level of enchanted books only gets smaller until you are only left with a 'common', or cheap (5 Emerald) level 1 enchanted book.
Basically librarians offering the better and rare enchanted books such as Sharpness-V, Smite-V, etc, will change to 'cheaper' books with enchantments that are not nearly as good, and are far more 'common'.
A simple fix would be that if a enchanted book trade is 'changed', to ignore the price, and just change the enchantment, regardless of price or level of enchantment.
WARNING: There is a seperate bug in that the price of some level V enchants where the price requested is larger than 64 Emeralds and thus unpayable in the current trading interface. That should be fixed (capped at 64?) at the same time.
Why not just cap the maximum number of emeralds needed for level V enchanted books to 64.
That would be a very very simple fix!
agilerelic... that is irrelevant to the discussion. The problem is not over population, or villagers building new houses. It is the problem that in a large village, the villagers like each other so much they all decide to live in one house, even though there are LOTS of houses in the village.
The crowding also causes them to climb ladders to village roofs, or even into jungle trees, which they otherwise would not do.
There is code that was added when villages were first created, to make villagers 'socalize'. This worked fine for normal small villages. But there is no code to make villagers want a bit of elbow room and spread out to prevent overcrowding.
We humans, like to socialize, but we also do not like to over crowd. Even in a 'party' everyone has a personal space. Of course we learned to suspend that instinct in special situations such as for lifts, or peak hour trains and buses, but generally we try not to 'crowd'. Especially in a home or other social situations.
Villagers need something similar.
@Cailan And why not. It is a bug, this is the fix. That is what bug forums are for.
Actually if they do fix it, they better fix the bug involving the start point of a zombie siege.
They should start at the edge of the villager radius, not in the middle of the village.
See related bug
MC-7488This is the problem with bucket/spigot servers. They fixed zombie sieges, bit not the siege spawn point.
Actually it also gives village Iron Golems more of a chance to take care of a siege that is (with the bug fix) heading into the village toward the juicy villagers.
I have watched iron golems in a village with large dark areas. They handle quite large hordes (non seige) zombies that are approaching the villagers, quite well.
But Iron golem will not handle a bugged zombie seige that appears in the middle of the village in side the house that the villages are hiding in. I have seen large trading villages decimated by a single siege on bucket servers (siege start bug fixed, but not start location), when a horde appeared inside the building the villagers were piled into.
From tests seen on the forum so of the new 'spread' may be caused by farmers now migrating toward farms.
It is hard to say if it is fixed or not, except maybe in a village that has no farmers.
The general migration toward North-West is an issue with all mobs (and there should be a separate bug report about that). If villager AI is fixed this general migration should not be a problem with villagers.
This bug breaks more things in unexpected ways than it helps.
There are other ways to generate BUD's that does not involved this issue. So it will break devices that use it. These devices are only using it because that could. NOT because they should be using it.
Better to fix this problem once and for all than just stick your head in the sand!!!!
FIX IT!
If you are not sure... put it to the serious redstone players.... Sethbling, Etho, DocM, and other players on the ZipCrowd. Most of them have already said they would prefer it fixed, rather than the current illogical behaviour.
Even if the 0 items in slot problem is fixed, wouldn't you still get a problem in that farmers will eventually get clogged up with 8 slots of seeds. Wheat farming produces a lot of excess seed, as any player would know. So once all the land has been farmed, and everyone has enough bread, farmers would slowly become weighted down with excess seeds.
Most players who do farming only keeps one stack of seeds for replanting, after that seeds are either used for chicken breeding or ignored. Villager farmers really should do the same. One stack of seeds maximum. Actually one stack of anything should be AI limit for any villager, and picked up items should go to any existing stack, not just the first available slot (which produces the equivalent of a hopper clog). That way villagers can have up to 8 different items as appropriate for their continued "evolution".
This would also eliminate the '0 item slot' problem, as a way of reserving a slot for a particular item, but without a villager getting bogged down with 8 slots of 0 or 64 items of all the same type.
It may also allow farmers to specialize or prefer to plant one particular item (first non-empty plantable item slot). But will plant other items if they run out of there preferred item. Farmers then would have a slot for seed, wheat, bread, potatoes, and carrots and that is all. The order determining there farming preference.
It is probably the same as
MC-56541which ZipKrowd members Kabo and Panda have provided a fix for,The problem effects torches which are part of the loop!
Also the image is of loops only consisting of torches.
Random update is for dealing with burned out torches, but the timing fault may result in torches remaining permanently on, which never gets fixed.
Yes definitely..
Please fix the related (but not quite the same) bug
MC-7488.Without that bug being fixed as well, zombie sieges can be very annoying, as they can and will spawn in the middle of houses and trading booths.
Thanks Mog for fixing this.
Beauty Bonsa.... Thanks Mojang... and specifically Mog... for fixing this.
Especially with the zombie seige start fix as well.
Are burnt out torches still being randomly updated to repair? A report on redit seems to indicate the they just stopped random update repair!
http://www.reddit.com/r/Minecraft/comments/28vnpy/
All the wandering I have seen has mostly been the result of the north-west bias, which is supposedly fixed.
However the fact that even with this bais, mobs tended to swim out to sea shows that most passive mobs do not even try to stay in grassy areas. They do migrate toward sky lit areas, but not grass. or at least avoid 'water' area.
Ideally passive land mobs (sheep, cows, chickens, and now rabbits) should make a few random destination rolls, then pick preferentially sky lit, grass (mycellium for mooshrums), then dry land, and only select water, if all the random choices was water.
That is not to say mobs won't swim across rivers or lakes to get to the grass on the other side, but at least they shouldn't drift out to sea, unless left no choice.
Note that this bug is also probably what allows the current piston-less glass item elevators to work. Enities can go into the fence block, but then they want to rise up into the item elevator as they are now 'inside' a block.
Chickens stuck in a fence corner will lay eggs but the eggs are 'ejected' from that fenced block.
For sheep and cows, placing carpet on top of the fence post in the corner stops the issue, as they hit the carpet collision box.
Perhaps a solution is to have unbreaking enchant not work for the last use or last few uses.
That is when a pick only has one use left, it always breaks, regardless of unbreaking enchant. That way randomness caused by server-client sync does not play a part.
As this may happen quickly perhaps the last 5 or 10 uses of a tool does not allow unbreaking, so as to ensure client-servers are in sync in a tools last moments of life.
For a single character bug fix, it seems ridiculous that this wasn't fixed almost immediately!
This happens all the time on multiplier servers where you have a Trading Village a lot of people use.
We have now lost on the order of a dozen perfect paper traders through this bug.
However as 1.8 changes everything, and resets at a 20% chance on any trade, I doubt this bug will ever be resolved.
The question is, and this is very hard to check, if on the rare occasion you had to trade all the villages trades, before the villager resets, if the disconnect (and chunk unload) happens, could you get a village with all trades permanently locked?
This would be a super rare occurence (more like 2 orders of magnitude rarer than 1.7), but I can see it being possible that this bug can happen in 1.8. However as you can not have perfect villagers, I doubt it is as important. The exception maybe with a librarian with one of the ultra good enchanted book trades (unbreaking III, sharpness V, etc).
This is NOT a bug. There is a ultra rare chance of a 9th slot gold trade. I myself have seen it.
also in 1.8 there are not perfect villagers, so even if classed as a bug, it will be of no consequence shortly.
However perfect paper traders (8th slot) has been determined to happen roughly 1 in 11 librarians (from a 100 million sample , if you can get all the librarian trades unlocked, which can take a lot of emeralds and work. So if this happens, you are better off just continuing your search.
See Forum discussion
http://www.minecraftforum.net/topic/1762291-/page__st__20#entry24298520
PS: 2 perfect paper traders are better than 1, as you can then jump from one to the other, while they reset. Also I find written book traders better still, if you have a ink farm.
I would probably say "Works as intended" rather than invalid!
it is the same bug. but this one is more complete are to reasons and cause of the problem.
Bad inventory handling, with some stupid bugs involving dropping 'zero' items, due to a bad conditional.
Additional. This problem while not a bug (works as intended) is also now moot.
Minecraft 1.8 completely revamped the trading system and you can no longer get 'perfect traders'.
This 'bug report' should be closed.
James... Dedicated slots is a good idea, but as there is only 8, it may limit other posibilities in the future. Better for villagers to have a little more inventory management smarts, which is what this bug is really about.
Basically villagers need to merge slots, and limit the maximum amount of seeds they pick up. Also only farmers should actually be able to pick up seeds and wheat, which I thought (from the previous corrupt inventory bug) is what happened.
Farmers being able to craft bread for their own use, and then throw excess bread would also make a lot more sense than throwing wheat that turns into bread as part of the throw. It would however mean that farmers given lots of wheat to fill inventory slots, will instead fill one slot, then have the other slots filled with bread. It would mean more wheat would be needed to 'initialise' the farmer, and they would have enough food they they would not be interested in harvesting more wheat. Thus break some of the current wheat farmer, or bonemeal to wheat auto-farms they currently exist.
One thing. Farmers buying wheat (which essentially disappears rather then being used) to me makes no sense, when they have a full inventory of wheat. But it does help game play.
The hopper in this case is looking at the stand and not the item drops.
In otherwords...
This is NOT a bug. Works as intended!
+Ryan Leach Mobs don't stand in shallows they swim!
if that was to change it would likely break a lot of things, especially mob-a-vators, something that has been in the game since it was beta!
However the AI has been resolved. There is a different bug involving mobs not swimming very fast if they decide to change direction while in water, resulting in mobs getting stuck in ponds and rivers, especially chickens, but that is not this bug.
Is this bug still a problem... That is a accelerating motion of items actually pushed into a block by piston or dropper?
Really it is a bigger problem for 'glass' item elevators than tree farms, and the main decription to be updated to reflect that.
This also does not appear to be the same as a motionless object that is suddenly inside a block due to a closing trapdoor or cobble fence connecting. In that case the items rise up VERY slowly without acceleration. But it can take about 4 to 5 minutesfor the items to rise up 100 blocks or more, making items despawn before reaching the top a very tall glass item elevator.
Ideally, what should happen is that item motion when inside a block degrades to a fixed vertical speed, say about double the speed you get from an item at rest finding itself inside a block. It should not accelerate.
md_5 said... "By killing the target of an angry pigmen, you make yourself the target."
Which does not really make sense. A gast hits a pigman, pigman gets angry at gast. you kill the gast, so pigmen get angry at you (or someone else that is closer). Really you helped the pigmen by killing the thing that hurt it. Why should it get angry at you!
At least they stopped pigmen continuously making more pigmen angry, unless you hit them again. That bug was the real nasty one of previous releases!