I could be totally wrong, but it appears that blocks which manage their drops using Block#dropBlockAsitemWithChance() instead of getItemDropped() or another such method are not getting recognized by Dropt. If so, my question is whether it would be possible to fix this by adding a call to the function under EventHandler.onHarvestDropsEvent(), as HarvestDropsEvent does appear to expose all of the necessary information for doing so. If not, please let me know so I can make changes on my end.

Thank you so much!

Short answer: I don't believe the solution is that simple, no.

Calling either Block#dropBlockAsItem or Block#dropBlockAsItemWithChance will ultimately call Block#spawnAsEntity which immediately spawns the entity into the world. Now, while it would be possible to use reflection to access the protected fields captureDrops and capturedDrops and prevent the drop methods from actually spawning the drops in the world, it feels like an ugly hack. Even if this solution were implemented, Dropt still wouldn't be able to handle blocks that call those methods directly as a result of some state change. For example the bed and ladder blocks call Block#dropBlockAsItem as a result of a call to neighborChanged.

I believe that intercepting these drops will remain outside the scope of Dropt, at least for now.

Out of curiosity, which specific block are you having trouble with?

Thanks for the response. I didn't actually consider that it was a void and thought I remembered it returning an ItemStack. Woops. The problem was reported by a user of my own mod. I'm using a few different variations of the same class to dynamically handle block properties using an OreProperties object, which allows me to easily modify block properties using external configurations, as well as adding entirely new ore variants very easily. I was previously using 3-4 separate events for managing ore drops, but found it neater to just merge everything into 2 functions: one for normal drops, and the other for silk touch drops. That allowed me to avoid repeatedly using the same logic in each location.

In that case, I'll see about working around it. No big deal! I guess I'll take another look at it and see if I can switch to a different method.