[1.10.2] Custom Block Model and onFallenUpon() Behavior

[FenixFyreX]

Hello, I've been writing new blocks and items into the game via forge that do various things as a way for me to get accustomed to the forge environment, and I've noticed some weird behavior when it comes to custom block models and various Block class methods like onFallenUpon().

 

I have a custom Block class called BlockPitTrap, and this pit trap's model has 1/16 block height (1 texel high, Minecraft blocks are 16x16x16 texels, right?), and the model is on the bottom of the render space (so the player's BlockPos is 'within' the 16x16x16 texel space of the block). Whenever any living entity falls on this block (either by falling, jumping, etc) then the block is supposed to break and let the entity fall down. However, this is not the case it seems. The block does not break, however if I place the same type of block above and jump on that one, the one below it breaks.

 

Here is my code:

public class BlockPitTrap extends Block
{
private static final AxisAlignedBB COLLISION_BOX = new AxisAlignedBB(0, 0, 0, 1.0, 0.0625 * 1, 1.0);
private static final AxisAlignedBB BOUNDING_BOX = new AxisAlignedBB(0, 0, 0, 1.0, 0.0625 * 2, 1.0);

public BlockPitTrap() {
	super(Material.WOOD);
	setUnlocalizedName(Reference.Blocks.TRAPBLOCK.getUnlocalizedName());
	setRegistryName(Reference.Blocks.TRAPBLOCK.getRegistryName());
	setCreativeTab(Tutorial.CREATIVE_TAB);
}

@Override
public void onFallenUpon(World worldIn, BlockPos pos, Entity entityIn, float fallDistance) {
	if(!worldIn.isRemote)
		worldIn.destroyBlock(pos, false);

	super.onFallenUpon(worldIn, pos, entityIn, fallDistance);
}

@Override
public AxisAlignedBB getBoundingBox(IBlockState state, IBlockAccess source, BlockPos pos)
{
	return BOUNDING_BOX;
}

@Override
public void addCollisionBoxToList(IBlockState state, World worldIn, BlockPos pos, AxisAlignedBB entityBox, List<AxisAlignedBB> collidingBoxes, Entity entityIn)
{
	super.addCollisionBoxToList(pos, entityBox, collidingBoxes, COLLISION_BOX);
}

@Override
public boolean isFullCube(IBlockState state) {
	return false;
}

@Override
public boolean isOpaqueCube(IBlockState state) {
	return false;
}
}

 

Can anyone shed some light as to what is happening, and why the onFallenUpon() method only gets called when there is a second instance of my block above the first?

 

Also, I've noticed that if I move the model to the top of the block space in my *.json file, and edit the collision / bounding boxes accordingly, it works perfectly. This leads me to wonder if there is special code for blocks anchored to different sides of the block space, or if Forge has a bug~ (possibly rounding the entity's BlockPos down instead of up?)

 

I can also upload screenshot(s) and json files if need be, no privacy needed for tutorial stuffs

[Animefan8888]

I doubt it is a bug because if you do round the players position, it would round down after being near the bottom. Just use pos.up () instead of pos. But use a print line to check if the code gets called with just one. Mainly because i dont know how onFallen works.

[FenixFyreX]

That's why I mentioned it before; the code does not get called when there is just one present; however, it does get called if the model is at the top of the texel space. It's very odd. Also, that's why I think if there is a bug, it'd be a rounding issue, because if I jump on just one of my blocks, I think the block below it is actually getting the onFallenUpon() event? At least when I place a second pit trap above the first, the one below breaks when the one on top is jumped on. It is pretentious of me to label this as a bug on Forge's part, as I'm sure I am just missing something. Just thought I'd throw it out in case.

 

EDIT: Confirmed, I've created a new block solely to test whether or not the block below the pit trap is receiving the onFallenUpon, and I was right; it seems that if the collision box of the block is lower than the top half of the cube space, then the block below is the one that receives the event? Which doesn't make any sense at all...hmmm

 

EDIT 2: It seems that if a block's collision box top is not higher than the bottom quarter of any given block space, onFallenUpon() is called for the block below the one the entity is standing, which seems to be a bug. This issue is nonexistent when using onEntityCollidedWithBlock(), so I'll be using that for the time being. I'll go report/query this to Forge's github soon.

[Animefan8888]

That's why I mentioned it before; the code does not get called when there is just one present; however, it does get called if the model is at the top of the texel space. It's very odd. Also, that's why I think if there is a bug, it'd be a rounding issue, because if I jump on just one of my blocks, I think the block below it is actually getting the onFallenUpon() event? At least when I place a second pit trap above the first, the one below breaks when the one on top is jumped on. It is pretentious of me to label this as a bug on Forge's part, as I'm sure I am just missing something. Just thought I'd throw it out in case.

 

EDIT: Confirmed, I've created a new block solely to test whether or not the block below the pit trap is receiving the onFallenUpon, and I was right; it seems that if the collision box of the block is lower than the top half of the cube space, then the block below is the one that receives the event? Which doesn't make any sense at all...hmmm

 

EDIT 2: It seems that if a block's collision box top is not higher than the bottom quarter of any given block space, onFallenUpon() is called for the block below the one the entity is standing, which seems to be a bug. This issue is nonexistent when using onEntityCollidedWithBlock(), so I'll be using that for the time being. I'll go report/query this to Forge's github soon.

It is most likely not a forge bug, it is most likely a Minecraft bug. Not sure if they will/can help.