megascience

Judging from a recent reddit post, seems true. It looks like per-slot attributes were being implemented, but the general case wasn't specified. As such, when attributes are displayed, it runs through each slot and lists the general stats, instead of defaulting to the original behavior.

Been testing on my old setup.Seems pretty consistent right now. If I run into this issue again, I'll call for reopening.

Well it seems the issue is just that when checking if a villager is updated, it checks multiple tags. As such, applying one tag isn't enough. If it doesn't find all the applicable tags, it tries to update the villager manually and then increments the career number, which can cause overflow among other issues. It's just a problem where the Update Villager code hyperactive, and ignores some tags in the process. Shouldn't be difficult to fix, just need to finish the understanding of it.

I have a different compromise in mind: Iron Golems only attack Creepers if there is a player nearby. This is the only time a Creeper would be dangerous, and the Iron Golem should be able to recognize this... Or attack the player like "Get out of here before you cause trouble!"

I believe that doesn't work because you're supposed to put a "d" after each number... But Searge 'fixed' it anyway. Not sure how...? But to quote Minecraft Wiki's Chunk Format page:

> direction: List of 3 doubles. Should be identical to Motion.

The command would be:

/summon Fireball ~ ~ ~ {direction:[0.0d,0.0d,0.0d]}

/summon Ozelot ~ ~ ~ {Owner:MegaScience,Sitting:1b}

I just tested using the above command to spawn a bunch of Ocelots. I then spawned a bunch of Creepers around them, which kept distance. I went into survival mode in the middle of them. The Creepers started walking toward me for a second, only to abruptly run away the next second every time. This is only an issue with Iron Golems, it seems.

Edit: I just did more tests on open ground like you said. They do seem to avoid the Ocelots more often, but I noticed Creepers will walk closer before running from the Ocelot. Point being the Attack Iron Golem is still being factored sooner than Avoid, but it works better in the pen than in isolation.

In my tests, Creepers did run away from my Ocelots, although somewhat rarely. However, when presented with an Iron Golem, they would suddenly snap to facing it, walking up and past/through the cat.

Updated for 14w33a. Decided to do another test: I had a 7x7 platform 5 blocks above the void, with a single block path 5 blocks off the platform. I put a cat on the block where the platform meets the path, with a creeper at the end of the path. The creeper stayed at the end. I summoned an Iron Golem at the other end of the platform. The creeper walked into the Ocelot, shoving it out of the way, and blew up, killing the cat and tossing the Iron Golem into the void.

This happens with all items that spawn entities (Example: Spawn Eggs). The issue is that the selection area is in line with the visible surface of the fence, but the fence's collision is a half a block higher than that. As such, being inside the collision and not above it, it can just fall down.

I just checked, and while the issue is slightly different, it's actually helped me understand it better. As you might know, when the game finds a Villager from before the Career system, it will attempt to update it. It seems originally, this could happen when a Villager spawns/is summoned. Now, the Villager Career is correct until accessed. When the Villager is accessed, the game sometimes checks the Villager. It seems just the Career ID isn't enough, so the game believes the Villager is outdated and redoes their data, including Career. When it finishes, it increments the Career ID by 1 instead of setting it to 1. This is what causes Villagers to be set to invalid IDs outside the normal range, as well as changing the Career set by the player. Updated affected versions.

I just opened Snapshot 14w21b and it appears this has been fixed. This can be marked as such. Thank you all, by the way.

Second-hand apologies for that. Suppose it'd be a little more work for an exact solution AI-wise, since it'd be looking for the data saying how tall the snow is. Hopefully it isn't too complicated to adjust for.

Not sure how relevant that image is...

Sigh. Can you give me an alternative for clearing cauldrons that doesn't require me spamming full water bottles everywhere during testing? The only reason I can think of this would be an issue is if you attempt to right-click leather armor on while looking at a cauldron, which if the armor is dyed you'd be actively avoiding and otherwise would be unlikely to occur. As others had noted, all this does is use up water, which you can refill into it as needed. But methods of removing water are cumbersome.

I remember watching redstoners who told me using cauldrons as door-control mechanisms was impractical since emptying them was a pain, and when I told them you could use leather armor, they became interested. It's a simple way of controlling cauldron water level, I don't see why it needs to be changed.

I personally used this as a feature. Since cauldrons with comparators give off signal, I'd use undyed leather armor to test different strengths when incorporating them into redstone contraptions. I know you can lower the water level via using empty bottles and putting out burning entities, but resetting is a pain. The ability to hold leather armor and right click to adjust levels as needed was actually incredibly useful.

This complicates the process of adjusting water level when using cauldrons in this way. Now, you must always have a valid method set up, which makes adjusting water level more cumbersome. You must either dye armor for EACH water level you want to remove, have a bottle you must keep drinking to empty/lots of bottles, or just start burning tons of entities and dropping them in. This is far less than preferable. Idea-wise you could say you are washing the armor, but I believe this should stay in the game to help those putting cauldrons to use in such ways.

Could someone give me reason why this shouldn't be possible? I understand this was originally intended for undying, but as I've stated above, it has other uses.

Edit: Not to mention I had JUST set this up last snapshot as a test for different data values on cauldrons, after watching a video on concepts for them. If this does not get reverted, setting up arrangements will become painfully impractical: http://i.imgur.com/MaL9TtS.png

Edit2: http://i.imgur.com/dJlChQx.png This was a system I made long ago. Whenever the cauldron empties, the droppers give you a water bucket to refill it. I always used undyed leather armor to test it, but now I'll have to keep redying armor or have lots of empty bottles I'll have to re-empty afterward.

Forgot to fix my typos here, but yes, the correct tag won't work. Defeats the purpose of its existence. CustomName works similarly, but PersistenceRequired should as well.

While testing in 14w11b, I realized that while walking up layered snow, they seem to try to path off. Yet they will still try to path onto it when not on... I'm confused.

Can not confirm. Tested with:
/kill @e[type=Endermite]
/tp @e[type=Endermite] @p
/say @e[type=Endermite]

The issue is they utilize a Lifetime tag. This prevents them from existing for more than about 2400 ticks, in case someone has something like an Enderman farm. This tag overrides and normal despawn-prevention methods.

Edit: This was fixed in 14w11b, although PersistanceRequired is still ignored.

Well it can easily be converted, the issue is you're downgrading. They can't retroactively change a version to support converting between formats. That's why we have to have 1.7.6 for instance.

However, you can manually fix this. All you have to do is remove the dashes, if you still have the original file.