Describe the bug
1.) Can duplicate radiant resonators using block dispensers.
2.) Can duplicate sugar cane using the 'celeste'.

To Reproduce
Steps to reproduce the behavior:
1.) Place a radiant resonator in-front of a block dispenser and activate the block dispenser (in this case, I used a redstone block). The radiant resonator should appear as a drop in front of the block dispenser and as a item inside of the block dispenser (giving you two radiant resonators).

2.) Place sugar cane on valid blocks and hit it with the 'celeste'. Dupes can range from two, three, or four times the original amount placed (just as the 'celeste' explains in its' description).

Expected behavior
1.) The block dispenser places the radiant resonator in front of it (just like other blocks) and does not produce a item inside of it.

2.) The 'celeste' should not work on placed sugar cane.

Screenshots

Info (please complete the following information):

• Modpack Version: 3.0 Beta 3
• Server or Singleplayer: Akliz Server
• Version the world was created on: 3.0 Beta 3

Additional context

eb738ef fixes the rest of this.

Arcane Archives isn't designed to interface with block-placers or block-dispensers and doesn't provide any specific support for it. That said, there are some blocks which are specifically limited as to the number a player can have in the world, including the Radiant Resonator, but the code for this is in onItemUseFirst.

From what I can gather looking through the default dispenser behaviour for dispensing blocks in Better With Mods, a potential point of failure is if tryPlaceBlock places the block but returns false, thus preventing the shrink call from being made. However, the onItemUseFirst is, at least as far as I can see, never called by Better With Mods, and from what I recall of the 1.12.2 environment, only ever called by the player controller/player interaction manager.

I don't see any solid indication from code as to who is at fault here. Given that, and given that this additional behaviour/block is added by Better With Mods, I'm not sure what else I can do to assist in tracking down the cause -- the BWM team are going to be placed best to interpret it, seeing as they know all of their functionality and it doesn't appear to be related to any of mine.

That said, while I am willing to do bug-fix releases for 1.12.2, especially for major exploits, if the issue stems from tile entity movers or other blocks which manipulate/handle things in a non-vanilla fashion, especially if that behaviour can be avoided through the use of blacklists (which this appears to specifically have), I'm probably going to be less inclined to do anything, as I'm currently neck-deep in the 1.16 port.

While I realise this might make me sound petty, I can only reasonably program in accordance with how Vanilla handles things. Speaking from experience, the moment things such as tile entity movers or automatic block placers are introduced, or I start trying to account for every possible thing that another mod might do, it gets really insane.

That said, I'm not sure if this has been reported to Better With Mods, but this line that checks instanceof ItemBlock might better be served with a direct class comparison to the vanilla itemblock. That is, making the assumption that something with a custom itemblock could do funky things.

Added this to our list for the new BWM update that Bord is so kindly going to make for us <3

https://trello.com/c/eTpxjr8O/1543-make-list-of-whats-needed-for-bwm-update