Block#breakBlock vs Block#getDrops for handling item drops

[Kevun1]

I'm designing a mod that checks for drops from a block using 

Block#getDrops

 

which is called in

Block#dropBlockAsItem

and actually spawns the items.

 

Most mods override the getDrops method to determine what a block drops, but I've noticed that the vanilla shulker box determines what it drops only in 

Block#breakBlock

and doesn't call getDrops at all.

 

Is there any reason to handle block drops like the shulker box? Or is it just plain bad code?

[Draco18s]

All of my container blocks use removedByPlayer to drop their contents. This is due to there having been an issue at one point in 1.10 where the TileEntity would have been removed before breakBlock was called, causing either a NPE or an otherwise inaccessible container.

 

In fact, most mods might still be doing it this way because of the default behavior of breakBlock:

    public void breakBlock(World worldIn, BlockPos pos, IBlockState state)
    {
        if (hasTileEntity(state) && !(this instanceof BlockContainer))
        {
            worldIn.removeTileEntity(pos);
        }
    }

No one uses BlockContainer any more because it's an unnecessary vanilla artifact.

 

Block#getDrops is a bad hook because it's only called by World#destroyBlock which is not invoked during the standard punch/mine/harvest logic, it's called by Entity AI tasks (Wither, Silverfish, Rabbits), the Fill command, buckets (when placing/taking fluids), and a couple of plants (lilypads when a boat collides with them, corous plants and cactus if it can't survive at its current blockpos), etc.

[Kevun1]

1 hour ago, Draco18s said:

 

Block#getDrops is a bad hook because it's only called by World#destroyBlock which is not invoked during the standard punch/mine/harvest logic,

Are we thinking of different methods? Unless if you override it, Block#getDrops is in the call hierarchy of PlayerInteractionManager#tryHarvestBlock, which also calls Block#removedByPlayer.

 

The default call hierachy, unless if I'm mistaken, goes:

 

Block#harvestBlock -> Block#dropBlockAsItem (if not silk touch) -> Block#dropBlockAsItemWithChance -> Block#getDrops

 

I've checked a bunch of popular mods like Thermal Expansion, Immersive Engineering, and EnderIO, and they all handle their drops in Block#getDrops, so I assumed that was where block drops were handled.

 

Note, I'm not talking about getting the drops from the tile entity or any container. I am aware of that tile entities are removed in Block#breakBlock, I'm talking about harvesting the block itself. 

 

In mods I checked, if there is a block with a container that retains its contents with NBT data as an item, they would get the block item, add the NBT data to it based on the tile entity's data, and then return it in Block#getDrops. This works because getDrops is called before the tile entity is removed in breakBlock. However, the vanilla shulker box handles its drops entirely in breakBlock, where it generates the dropped shulker box item with NBT data. getDrops is never called because dropBlockAsItemWithChance is overriden. 

 

I'm just wondering if the shulker box implementation is an anomaly or not, since I've never seen it done like that before, and there would be no way to check what it drops without actually simulating the drop itself.

 

 

Edited September 4, 2017 by Kevun1

[Draco18s]

Ah, you're doing something different than what I expected.

 

To answer your question about the shulker box being an anomaly: I would say maybe, but anyone who wants to do the same thing that looks at the shulker box would copy it.