Dan Shemp
- DanShemp
- danshemp
- Europe/Stockholm
- Yes
- No
MC-75290
Confirmed 1.8.7/Mac. Definitely looks like the push vector is stuck as described by Dan Shemp.
Observations with a 12x12 loop of track:
- furnace cart started at southwest corner while facing northeast comes to rest at northwest corner (about 10 blocks from northeast corner where its motion vector presumably gets set to 0)
- furnace cart started at southwest corner while facing southeast comes to rest at northeast corner (about 10 blocks from southeast corner where its motion vector presumably gets set to 0)
Please link to this comment in the description
The following is based on a decompiled version of Minecraft 1.9 using MCP 9.24 beta.
What Dan Shemp said is correct, the method net.minecraft.enchantment.EnchantmentThorns.onUserHurt(EntityLivingBase, Entity, int) reduces the durability of the item by 1 although the Thorns enchantment did not damage the attacking mob.
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.
Possibly linked to this bug, the bedrock blocks are no longer generating at the top of the towers.
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.
Confirmed for 14w31a.
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.
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:
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.
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.
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.
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.
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.
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
Looks like a dupe of MC-30730.
I think this one is fixed after testing on 15w43b.