The only major change that might have any impact was the move from a Mixin of BlockState to implementing getDestroyProgress in the block instead. They are functionally identical, so it's not that.

Turns out my assumption was incorrect, they are not functionally identical although on the surface they appeared to be. I've made a new release for 1.19.

Sorry, it's me again. Explosion nuclear_explosion - explodes lootr:lootr_barrel.
The rest of the containers don't explode. Only the barrels. It's a bug.
Version 1.19.2 and 1.20.1 Forge.

#The maximum explosion resistance that a block can have to be destroyed by a nuclear explosion. Set to zero to disable all nuclear explosion block breaking.
#Range: > 0
nuke_max_block_explosion_resistance = 1000

There is such a line in the Alex's Caves configuration, which means that your barrel has no protection against explosion.

It's possible the barrels aren't outputting the correct blast value, it should be Float.MAX_VALUE.

It's possible the barrels aren't outputting the correct blast value, it should be Float.MAX_VALUE.

It is quite possible, please fix it if it is not difficult for you, and I will help check it!

  @Override
  public float getExplosionResistance() {
    if (ConfigManager.BLAST_RESISTANT.get()) {
      return 16.0f;
    } else if (ConfigManager.BLAST_IMMUNE.get()) {
      return Float.MAX_VALUE;
    } else {
      return super.getExplosionResistance();
    }
  }

Ensure you don't have "BLAST_RESISTANT" enabled as that will default to 16.0f.

The code used here is identical to all of the other getExplosionResistance methods.

Hm wait.

Fixed ! Thank you !

I'm pretty sure that this issue has been opened several times, potentially by you. As far as I'm aware there's a tag that makes blocks immune to the drill, and you need to add Lootr containers to it.

Again, there is nothing I can do about it on my end.

EDIT: Is that a Lootr container or is it a Quark container?

I checked on Lootr and Quark containers - all break

none

You fixed it somehow before, the chests didn't break. After the update they break again

Which update?

Which update?

sec

EDIT: Is that a Lootr container or is it a Quark container?

Okay, which versions of Minecraft, Lootr, Create, etc, are you currently using? What did you update? What were the previous versions? What other changes have you made?

i use Forge 1.19.2

mods:
create-1.19.2-0.5.1.i.jar
lootr-forge-1.19-0.4.28.74.jar

my config lootr:
lootr-common.txt

In version Lootr-67 Lootr no destroying!!!!

https://modrinth.com/mod/lootr/version/0.4.25.67 my love version

I'm telling you, you broke something in the update! :D

Did you only update Lootr, or did you also update Create?

EDIT: I've looked through the entirety of changes since the 0.4.25.67 release through to HEAD of the 1.19 Forge branch and there are no changes that would cause this.

The only major change that might have any impact was the move from a Mixin of BlockState to implementing getDestroyProgress in the block instead. They are functionally identical, so it's not that.

Did you only update Lootr, or did you also update Create?

EDIT: I've looked through the entirety of changes since the 0.4.25.67 release through to HEAD of the 1.19 Forge branch and there are no changes that would cause this.

The only major change that might have any impact was the move from a Mixin of BlockState to implementing getDestroyProgress in the block instead. They are functionally identical, so it's not that.

I've launched it now create-1.19.2-0.5.1.i.jar and lootr-67 version and lootr no destroying

But when I launch the new version of lootr - all chests are broken by the drill from Create

Is that -67 from Modrinth, or is it one I compiled specifically for you?

Is that -67 from Modrinth, or is it one I compiled specifically for you?

Modrinth.

You can fix please this?

I'm looking into it but it's proving difficult to debug.

The only major change that might have any impact was the move from a Mixin of BlockState to implementing getDestroyProgress in the block instead. They are functionally identical, so it's not that.

Turns out my assumption was incorrect, they are not functionally identical although on the surface they appeared to be. I've made a new release for 1.19.