I have a block that (configurable) allows to block/pass through items, passive mobs, hostile mobs and players. To do this I override addCollisionBoxesToList() to return nothing in case I recognize one of the entities above. This works great for passive mobs, hostile mobs and players. I can configure my block to let through passive mobs but block hostile mobs for example.

 

However with items it doesn 't work as well. If I set my block to allow items to pass through (so basically let addCollisionBoxesToList do nothing in case it is an EntityItem) then the items seem to jump up and down on my block as soon as I throw one down. I checked Entity.moveEntity() which seems to be the main code that handles this collision detection and I can't find why items can't fall through my block.

 

Any clue what could be wrong here?

 

Thanks!

I just found out that mobs also seem to have a small hickup when going through my blocks. But they manage to get through. Perhaps items can't get through because they are too small. But that means that some other kind of collision detection is going on besides addCollisionBoxesToList. Any clues?

Try

 

Block::getCollisionBoundingBoxFromPool, eg from BlockBush

    /**

    * Returns a bounding box from the pool of bounding boxes (this means this box can change after the pool has been

    * cleared to be reused)

    */

    public AxisAlignedBB getCollisionBoundingBoxFromPool(World p_149668_1_, int p_149668_2_, int p_149668_3_, int p_149668_4_)

    {

        return null;

    }

 

-TGG

 

I can't use that function as it doesn't get an Entity parameter. My block needs collision detection depending on the type of entity that is on it.

I can't use that function as it doesn't get an Entity parameter. My block needs collision detection depending on the type of entity that is on it.

Ah, bummer.

 

Well I'm stumped then.  addCollisionBoxesToList should work fine.  Does it still glitch if your addCollisionBoxesToList always returns none?

 

Might be worth trying getCollisionBoundingBoxFromPool() to return null always and see if that fixes the problem.  If so, you could add a breakpoint to it, or something fancy which returns different AABB depending on what the caller is (http://stackoverflow.com/questions/11306811/how-to-get-the-caller-class-in-java)  to help you find what else is using that.

 

-TGG

If I let getCollisionBoundingBoxFromPool() return null it works perfectly but of course I have no control then.

If I let getCollisionBoundingBoxFromPool() return null it works perfectly but of course I have no control then.

 

OK.  That's a good start.

 

I'd suggest you could add a breakpoint to getCollisionBoundingBoxFromPool(), or something fancy which returns different AABB or null depending on what the caller is (http://stackoverflow.com/questions/11306811/how-to-get-the-caller-class-in-java).  It might help you find what else in the vanilla code is using getCollisionBoundBoxFromPool to detect collisions.

 

-TGG