The bug
When an arrow is shot by a dispenser facing a half slab or stairs, the arrow cannot be picked up as item by the player until the block in front of the dispenser is removed. This is different to the behaviour of all other blocks where the arrow can be picked up.
The reason
The following is based on a decompiled version of Minecraft 1.10 using MCP 9.30.
The reason for this is that the method net.minecraft.entity.projectile.EntityArrow.onHit(RayTraceResult) sets the position of the arrow to NaN, NaN, NaN because
raytraceResultIn.hitVec.xCoord - this.posX= 0 (for y and z as well)MathHelper.sqrt_double(0, 0, 0)= 0 (=f2)this.motionX / (double)f2 * 0.05000000074505806D;=NaN
This causes the bounding box to be invalid as well. This cannot be seen in the NBT data because the method net.minecraft.world.World.updateEntityWithOptionalForce(Entity, boolean) sets the position to previous if it is either NaN or Infinite, however it does not correct the bounding box. Changing the onHit method which causes this first would probably be the better choice.
16w03a: Code deobfuscated by @unknown
Related issues
relates to
Comments
migrated
migrated
Ok, that's weird... For some reason the player collision is only registered by the client but not by the integrated server, which is responsible for handling the pickup.
migrated
It's because OnGround is set to 0b.
migrated
@No Name1 Both arrows have their OnGround tag set to 0 but the inGround tag is the important one 🙂
migrated
They both have inGround set to 1b.
migrated
Yes, as I said: No problem with the NBT data.
net.minecraft.entity.projectile.EntityArrow.onCollideWithPlayer(EntityPlayer)
...
if(!this.worldObj.isRemote && this.inGround && this.arrowShake <= 0) {
// pick up arrow
}
...As you can see, inGround and arrowShake (which maps to the NBT tag 'shake') do have the right values, however the first condition (!this.worldObj.isRemote) is never met.
The onCollideWithPlayer method should be executed twice per tick; Once by each the client and the integrated server.!this.worldObj.isRemote is true if the current execution is caused by the server, so because it always fails we can conclude that the server doesn't register the collision.
marcono1234
@unknown the code very likely changed due to MC-3330
migrated
@unknown You may be right, I'm referencing the 1.8.8 source.
migrated
Here's the updated source (deobfuscated manually, so some names might ne inacurate):
EntityArrow.onCollideWithPlayer(EntityPlayer)
public void onCollideWithPlayer(EntityPlayer player) {
if((this.worldObj.isRemote) || (!this.inGround) || (this.arrowShake > 0)) {
return;
}
boolean flag = (this.canBePickedUp == EntityArrow.pickupEnum.landed) || ((this.canBePickedUp == EntityArrow.pickupEnum.flying) && (player.capabilities.isCreativeMode));
if((this.canBePickedUp == EntityArrow.pickupEnum.landed) && (!player.inventory.addItemStackToInventory(j()))) {
flag = false;
}
if(flag) {
this.playSound(SoundLibrary.entityItemPickup, 0.2F, ((this.rand.nextFloat() - this.rand.nextFloat()) * 0.7F + 1.0F) * 2.0F);
player.onItemPickup(this, 1);
this.setDead();
}
}Is this still an issue in the latest snapshot 16w44a? If so please update the affected versions.
This is an automated comment on any open or reopened issue with out-of-date affected versions.
wobst.michael
Cannot confirm for 1.11.2. Please re-check if this is still an issue for you in 1.11.2
migrated
It's fixed in 18w50a.
Confirmed for 15w51b, after reentering the world the arrow can be picked up again, so there is indeed no problem with the NBT data.