[Bug] Item gets dropen falsely

[Nononitas]

Reproduction: Make a plugin which have the following Listener BlockBreakEvent which sets event.setDropItems(false) only on a custom block (customcrafting block) CustomItemBreakEvent with event.setDropItems(false)

• Place a custom block and break it nothing will drop. (like excpected)
• Place any block favourable not a custom, lets take sand and break it. The drop of the previous custom block will be dropped and not a sand item

[WolfyScript]

Unfortunately, I was unable to reproduce it.

Due to API changes, the CustomItemBreakEvent#setDropItems has no effect anymore, so that one can be removed.

There is now a new way of doing things using the PersistenStorage in WolfyUtils. For example, this listener disables the drops of any custom item block, and it causes no issues for me.

import com.wolfyscript.utilities.bukkit.WolfyCoreBukkit;
import com.wolfyscript.utilities.bukkit.items.CustomItemBlockData;
import org.bukkit.event.block.BlockBreakEvent;

@EventHandler
public void onBlockBreak(BlockBreakEvent event) {
    var block = event.getBlock();
    WolfyCoreBukkit.getInstance().getPersistentStorage().getOrCreateWorldStorage(block.getWorld())
            .getBlock(block.getLocation())
            .flatMap(store -> store.getData(CustomItemBlockData.ID, CustomItemBlockData.class))
            .ifPresent(data -> event.setDropItems(false));
}

As you can see, it is easily done using the BlockBreakEvent now and no longer requires a wrapper event like before.

However, if you still encounter this issue, I fear it might be another plugin conflicting with it.
In that case, we need to figure which plugin it is.

[Nononitas]

Here is my code and a problem that can occur with this bug

Code (CustomBlock is obviously not from WolfyUtils or CustomCrafting. If you want to reproduce it just take a specific block type)

Example

[Nononitas]

I will try using your solution for now :)

[Nononitas]

I will try using your solution for now :)

Still the same issue with your method

[WolfyScript]

(CustomBlock is obviously not from WolfyUtils or CustomCrafting. If you want to reproduce it just take a specific block type)

If the block is not from WU nor CC, then I don't really understand what it has to do with CustomCrafting or WolfyUtils, if the block breakage isn't handled by neither of them.

[Nononitas]

The block is registered in CC otherwise I wouldn't report this bug... I just don't want that CC is handling the drops. If I uninstall CustomCrafting and WolfyUtils it works perfectly fine.

[WolfyScript]

Then it is most likely that your event is called after the internal event.

So the WolfyUtils event handler (Also with priority HIGHEST) one marks the block to drop before your event handler sets dropItems to false.

The easiest solution would be to set your event priority to HIGH.

The more tricky solution would be to change your plugin load order, like load before or after WU. But Spigot provides no guarantee that the event order stays the same.

[Nononitas]

That makes no difference because I set the setDropItems to false. The problem is that your plugin is taking the drop of the custom block that was there before, even though the current block is a sand block. So your plugin doesn't notice that the block was being removed and it has something to to with setting ItemDrops to false. Please check out the video I shared earlier

[WolfyScript]

Have you tried setting the priority to HIGH?

Because the issue is that WolfyUtils isn't dropping the items on the BlockBreakEvent, but on the drop event later on.
It listens to the BlockBreakEvent (with highest priority) and checks if it should drop items.
In case isDropItems returns true, it marks the block to drop the custom drops for later.

Here comes your plugin (or any plugin for that matter), that listens to the BlockBreakEvent, into play. Because your listener gets called after the WolfyUtils listener, the block has already been marked to drop the custom item.
That means after your listener drops the extra item, the block is still marked, meaning it'll drop on the next drop event, which in this case is caused by the sand.

I am not saying that your plugin is the only cause of the issue here, clearly WolfyUtils needs to handle something differently or unmark the block properly, which I am currently looking into. Just trying to get this to work for you at this moment without any patch required.

[Nononitas]

Yes this actually bypasses this issue. Thank you :)