Dan Shemp
Assigned
Reported
Comments
PrimedTNT now has its "centre" at the bottom of the entity, which means the block code for TNT summons the entity 0.5 of a block too high. When "+ 0.5f" is removed from the y-argument for PrimedTNT's constructor call, this bug is resolved. Dispensers also had this problem but it was fixed in separate code.
Somewhat related: Ender Crystal entity spawning 1 block too low
When you say the Nether was "reset", I assume that means the region files were erased. If you do this without deleting the relevant structure.dat files (Fortress.dat in this case), it can lead to strange consequences.
It seems to be a quirk that allows redstone wire to point asymmetrically (see piston_extension.png).
If you replace the lime wool with redstone, the piston/TNT turns on.
There are a few distinct definitions of a "solid block".
The most common is whether it will conduct redstone power and block a sloping signal. TNT doesn't do this. Before 1.8, this definition also exclusively determined whether players could suffocate inside the block, so TNT was used commonly in X-ray devices.
There is also the definition of whether a block visually occupies the entire cube, which is used by the renderer to decide if the top wire should connect to the bottom, or be isolated.
Glowstone, TNT and Blocks of Redstone are blocks which satisfy the second definition but not the first.
Some details for those who are interested:
The code which describes how entities centre themselves along the y-axis has changed, and as a result, Ender Crystals no longer attempt to offset themselves upwards when they're initialised. This can be observed by running the command "/summon EnderCrystal" while standing on flat ground in versions 1.7 and 1.8.
Bedrock is still successfully generated at the head of the obsidian tower. However, Ender Crystals will attempt to place a fire block at their centre every gametick, and since that centre is now 1 block lower, the bedrock is overwritten as soon as the player enters The End.
Aside: Never place Ender Crystals in the air. The block at their centre will constantly alternate between fire and air, and the lighting updates will make the server thread quite unhappy.
In case this point isn't clear, when you are wearing a piece of armour with the Thorns enchantment and you are attacked:
If the Thorns spell does not activate, the armour takes 2 damage.
If the Thorns spell successfully activates, the armour takes 4 damage.
If your armour doesn't have Thorns, it takes 1 damage.
The code for the enchantment in MCP is vaguely,
if the spell is successful, damage the armour 3 points and cast Thorns on the aggressor,
else, damage the armour 1 point.
It could have easily been overlooked that standard damage has already been applied to the item at this point.
To the commenter above me, thank you very much for this data! I've had similar concerns to the OP since I'm playing on a world with BiomeSize 3, but I think the main problem is that there aren't really any known seeds for structures on different biome sizes. This makes it difficult to verify whether they're generating properly.
I have three questions about your data:
1) What is the second number after the biome name? Is it the raw X/Z area? I know the number in round brackets is the ID.
2) Your sample is about 1,000,000 chunks. Assuming a perfect square, that's roughly a square-radius of 8,000 blocks from (0, 0), correct?
3) Does your script verify that each structure has been successfully placed into the world, or does it just check the structure.dat files? I have a hunch that the generation is able to fail but still be recorded, although your Ocean Monument data says otherwise.
You are correct in deducing that the location of structures does not "compress" to (0, 0) like biomes do. Each chunk has an independent chance of spawning a structure, and one of the success conditions is obviously the biome.
Ocean Monuments are the only structure which require a certain amount of space around their starting point to also be within Ocean-like biome, so as you decrease the biome size, failure becomes more likely.
Interesting observations about biomes:
JungleEdge M is indeed the rarest biome
Extreme Hills Edge and Frozen Ocean no longer generate as they did in 1.6
An explanation of why this happens:
When a player right-clicks the furnace cart, it is given a push vector based on where the player is stood relative to the cart. In versions prior to 1.8, this vector would be updated every gametick to face in the direction that the minecart is moving - however in 1.8, the push vector is stuck in the direction that the player initially set it to.
If the angle between the push and motion vectors is over 90 degrees (i.e. scalar product is negative), the push vector is set to 0 and the cart will come to a halt.
For example, if you are facing South-West when you right-click the cart, it won't lose power on tracks which take it South or West, and there can be many corners alternating between those two directions.
Confirmed for 14w31a.
This error stems from the assumption that numerical truncation in Java is equivalent to flooring (it isn't). Until this is sorted, make your suspended Nether/End rails 3+ blocks wide for sure.
Possibly linked to this bug, the bedrock blocks are no longer generating at the top of the towers.
I've noticed on the 1.8 snapshots that minecarts will now occasionally put you 1 unit West of the block you're supposed to land on, as opposed to 1 unit North in 1.7.
EDIT: Disregard the above, it depends on where you are in the world only.
Tried ElNounch's fix for MCP903; can confirm it solves the problem.
Is there a reason why the algorithm doesn't aim to put the player in a half-integer X/Z position above the valid block, opposed to adding an integer to their current position? I wrote a Bukkit plugin using this method a few months ago; just seems like the easier way to do it.
I think this one is fixed after testing on 15w43b.