This is a Known Bug
Dispensers shooting arrows need at least 2 empty blocks of space to smash a block.
This is due to implementation details of this pack, namely that Arrows and Tridents can only break blocks if they were going at least 12 blocks per second in the tick prior to hitting a block. We cannot know the speed after it has already hit a block, as the speed at that point is 0.
With dispensers hitting a block with a 1 or 0 block gap, this pack is unable to know how fast the projectile was moving, since it spawns already in the block. It is technically possible to remove this ambiguity, by tagging projectiles as known every tick, and then if there is an unknown projectile in a block we know it has spawned already lodged in the block.
HOWEVER, implementing this fix would have significant impact on the performance of the pack, requiring 3 additional selectors in the tick function. It is for this reason that I have decided to not implement the fix and leave this as a known bug.
Other Considerations:
Reading the above, you may be wondering: Why does this pack have a speed requirement for projectiles to smash a block?
- This is to prevent low speed projectiles, like those falling off blocks that have just been smashed, smashing another block on the way down. This speed requirement comes from the vanilla behaviour of tridents and pointed dripstone. Note, this speed requirement does not apply to vanilla breaking of decorated pots and chorus flowers. It is simply a design choice of mine to extend this speed requirement to blocks added by this pack.
This is a Known Bug
Dispensers shooting arrows need at least 2 empty blocks of space to smash a block.
This is due to implementation details of this pack, namely that Arrows and Tridents can only break blocks if they were going at least 12 blocks per second in the tick prior to hitting a block. We cannot know the speed after it has already hit a block, as the speed at that point is 0.
With dispensers hitting a block with a 1 or 0 block gap, this pack is unable to know how fast the projectile was moving, since it spawns already in the block. It is technically possible to remove this ambiguity, by tagging projectiles as known every tick, and then if there is an unknown projectile in a block we know it has spawned already lodged in the block.
HOWEVER, implementing this fix would have significant impact on the performance of the pack, requiring 3 additional selectors in the tick function. It is for this reason that I have decided to not implement the fix and leave this as a known bug.
Other Considerations:
Reading the above, you may be wondering: Why does this pack have a speed requirement for projectiles to smash a block?