Okay, I have a custom monster placer (spawn egg) which pretty much just extends/copies the vanilla monster placer code.

 

I have a custom entity that is a giant, so the bounding box size is set to setSize(1.0F, 4.5F).

 

I found that when placing the giant right next to something, it will start to take damage of DamageSource.inWall (I check this by printing out console statements in the LivingAttackEvent) until it dies.

 

However, if visually the bounding box doesn't really look like it is in the wall.  See pic: http://i.imgur.com/L2GyMHK.png

 

So I followed the code for the inWall damage and it is caused by a check to isEntityInsideOpaqueBlock() which has kinda interesting code as follows:

    public boolean isEntityInsideOpaqueBlock()
    {
        for (int i = 0; i < 8; ++i)
        {
            float f = ((float)((i >> 0) % 2) - 0.5F) * this.width * 0.8F;
            float f1 = ((float)((i >> 1) % 2) - 0.5F) * 0.1F;
            float f2 = ((float)((i >> 2) % 2) - 0.5F) * this.width * 0.8F;
            int j = MathHelper.floor_double(this.posX + (double)f);
            int k = MathHelper.floor_double(this.posY + (double)this.getEyeHeight() + (double)f1);
            int l = MathHelper.floor_double(this.posZ + (double)f2);

            if (this.worldObj.getBlock(j, k, l).isNormalCube())
            {
                return true;
            }
        }

        return false;
    }

 

I noticed that it includes a getEyeHeight() call and in my custom entity I didn't override that so it is inherited from EntityLivingBase which sets eye height to 85% of the bounding box height (which is 4.5F, so 85% is 3.82F) .  I tried reducing the height of the bounding box and voila! the damage stopped if I had the height at at 3.5F. 

 

I can't quite wrap my head around the bit shifting operations though.  But I'm suspicious about it.  It only counts to 7, gets shifted by 1 (which I think is equivalent to divide by 2), then does a % (modulus) with 2 which gives the remainder after dividing by 2 again.

 

If I step through the iteration of the for loop, the float f1 = ((float)((i >> 1) % 2) - 0.5F) * 0.1F should be like this:

  i = 0, then f1 = -0.05F

  i = 1, then f1 = -0.05F

  i = 2, then f1 = -0.05F

  i = 3, then f1 = -0.05F

  i = 4, then f1 = -0.05F

  i = 5, then f1 = -0.05F

  i = 6, then f1 = 0.05F

  i = 7, then f1 = 0.05F

 

Not sure what it means, but I guess it is just a clever way of checking just a little bit around the eye height location.

 

Other than that, I'm stumped.  I'm going to check to see if for some reason the isNormalCube() function is actually returning true in the eye height location.

 

I can work around this by just canceling the damage from inWall in the LivingHurtEvent, but I'd like to understand what's happening.  I'm also going to play around with overriding the getEyeHeight() to see if my hunch is correct that it is related to the issue.

Okay, I solved it.  Apparently I had already overridden the getEyeHeight() and was multiplying it by a scale factor I was using in the rendering (I was planning to have the bounding box set by the model's scale factor but never got around to properly adjusting that).  There was some blocks higher up above the entity, which I guess after scaling caused the inWall damage.

 

But I guess the thing I learned was that the inWall damage is only calculated in the block at the eye height.