Paper: Moving blocks are indestructible

Created on 10 Aug 2020  路  9Comments  路  Source: PaperMC/Paper

What behaviour is expected:
TNT destroys moving blocks when it explodes
https://www.youtube.com/watch?v=0At4JPPjxNc

What behaviour is observed:
TNT does not destroy moving blocks when it explodes
https://www.youtube.com/watch?v=MlHG5DGoMFc

Steps/models to reproduce:

  • Make sure the allow-permanent-block-break-exploits setting set to false (default)
  • Summon an exploding TNT entity near or inside blocks that are being moved by pistons

Paper build number:
Paper version git-Paper-133 (MC: 1.16.1) (Implementing API version 1.16.1-R0.1-SNAPSHOT)

Anything else:
I'm aware that this issue is essentially a duplicate of #3679 and #3853, however, I'm opening this issue as the actual issue described in both of those issues was never addressed.

I think we agree on the following 2 things:

  • Headless piston retraction replacing unbreakable blocks such as bedrock is not an intended mechanic.
  • TNT breaking blocks with a low enough blast resistance is an intended mechanic, even while the blocks are being moved.

What's up for debate is the following:

  • Whether or not moving blocks should all have the same low blast resistance, instead of the blast resistance the block normally has.

The exploit(s) fixed by the allow-permanent-block-break-exploits setting affects both of these things. Perhaps moving blocks should have the blast resistance of the block that is being moved, however, they should most definitely not be unbreakable given that they were never supposed to be unbreakable blocks.

I'm not sure of the technicalities behind this (I'm not a dev) but I believe this might be caused by moving_piston being treated the same as blocks such as bedrock in the fix.

bug 1.16

Most helpful comment

I would argue this part should _not_ be up for debate and should match vanilla exactly. Mojang can fix it themselves if they want it to be different. Until then, it's not something Paper should mess with. Moving blocks getting blown up by legit TNT should work exactly the same as vanilla.

One could argue that the vanilla behavior is unintended and therefore should be changed. On the flipside though it's not an exploit and therefore perhaps should not be touched. Personally I don't mind either way so long as moving blocks are destructible, since that part is without a doubt intended vanilla behavior.

It can work the same. Just turn off the option...

You have to take a choice between the mechanism working or having the exploits it introduces patched.

Server owners should not have to disable fixes for exploits in order to get intended behavior that was broken with an exploit fix back. If you seriously believe otherwise I'm not sure what to even say. This isn't isn't about TNT duping or bedrock breaking. These are 2 different things affected by a fix that is only supposed to affect one of those things.

The stance to this issue has generally just been PR or shut up

That just seems pointlessly hostile, especially given that there was no open issue in regards to this. Acknowledging that there might be - dare I say is - an issue and discussing what the behavior should be(come) before taking a "PR or shut up" stance might go a long way.

All 9 comments

What's up for debate is the following: Whether or not moving blocks should all have the same low blast resistance

I would argue this part should not be up for debate and should match vanilla exactly. Mojang can fix it themselves if they want it to be different. Until then, it's not something Paper should mess with. Moving blocks getting blown up by legit TNT should work exactly the same as vanilla.

It can work the same. Just turn off the option...

Having to enable exploits to get moving blocks to break on explosion, either at block 36 blast resistance or the block's non-moving blast resistance (although I am in favor of the former as it's vanilla-consistent and nothing's getting duped) isn't really a solution.

Unless something has changed, I think piston heads changing states and moving blocks changing states are both briefly treated like block 36 which is probably why it's applying this to all moving blocks.

Was making block 36 indestructible part of the "fix" for allow-permanent-block-break-exploits?

Yes. You have to take a choice between the mechanism working or having the exploits it introduces patched.

If that's the position being taken, then blocks that are moving need to blow up at their block's blast resistance, not fail to blow up because they are Block 36. Blocks not blowing up at all just because they are moving makes no sense.

The stance to this issue has generally just been PR or shut up; I assume if you really want it, you can deduce what to do.

I am not sure why anyone would waste their time when there doesn't seem to be a consensus on whether or not breakable blocks should break when things that break blocks happen to them edit: I should say, a consensus on exactly what the actual behavior in Paper should be.

I would argue this part should _not_ be up for debate and should match vanilla exactly. Mojang can fix it themselves if they want it to be different. Until then, it's not something Paper should mess with. Moving blocks getting blown up by legit TNT should work exactly the same as vanilla.

One could argue that the vanilla behavior is unintended and therefore should be changed. On the flipside though it's not an exploit and therefore perhaps should not be touched. Personally I don't mind either way so long as moving blocks are destructible, since that part is without a doubt intended vanilla behavior.

It can work the same. Just turn off the option...

You have to take a choice between the mechanism working or having the exploits it introduces patched.

Server owners should not have to disable fixes for exploits in order to get intended behavior that was broken with an exploit fix back. If you seriously believe otherwise I'm not sure what to even say. This isn't isn't about TNT duping or bedrock breaking. These are 2 different things affected by a fix that is only supposed to affect one of those things.

The stance to this issue has generally just been PR or shut up

That just seems pointlessly hostile, especially given that there was no open issue in regards to this. Acknowledging that there might be - dare I say is - an issue and discussing what the behavior should be(come) before taking a "PR or shut up" stance might go a long way.

Fixed with #4131.

Was this page helpful?
0 / 5 - 0 ratings

Related issues

successed picture successed  路  3Comments

TNTUP picture TNTUP  路  3Comments

ShelLuser picture ShelLuser  路  3Comments

Brokkonaut picture Brokkonaut  路  3Comments

Shevchik picture Shevchik  路  3Comments