Paper
Paper copied to clipboard
Fix breaking tripwires with shears, fixing string dupe.
A bug in vanilla causes tripwires broken by shears to go into a weird state, see https://bugs.mojang.com/browse/MC-129055 In this state, destroying the tripwire will not work, it will instead disconnect from tripwire hooks for 10 ticks before connecting again. Destroying the tripwire during this 10 tick window will actually destroy the tripwire.
Abusing this, and using water to repeatedly destroy the tripwire, an infinite amount of string can be easily duplicated in a fast manner, as the tripwire will drop one string when "destroyed" by water.
It seems tripwire in this bugged state was previously accepted as a feature, see #7259 and #7261 This PR fixes the issue by moving a line of code down one line into an empty if-statement by Mojang... If bugged "disarmed" tripwire is something we'd like to keep around, a more thorough solution is needed, as the current "unbreakable" behavior is quite unintuitive.
Download the paperclip jar for this pull request: paper-9436.zip
I'd maybe add a config option for it since it goes beyond just a dupe, and have the fix enabled by default
Disarming without breaking has basically been accepted as a feature at this point is the problem, so we don't want to rip it out entirely
Would something like this be better? We keep disarmed wires around, but make them actually break on subsequent block breaks. The code is a bit ugly by setting a block in onRemove, but it already did that previously, just hidden further away in TripWireHookBlock. This has the by-effect of making all tripwires broken by shears being disarmed on the first break, not just ones currently in a tripwire circuit - making it a bit more consistent.
Having thought about it a little more, I think just doing what you had before is the "best" option as long as you add a config option to revert it in the unsupported
section (see 0005-Paper-config-files.patch
). After the initial attempt at fixing the dupe without changing mechanics, we had hoped Mojang would possibly fix either soon enough, but given that's not the case and there's no sign of it either unfortunately, having it like this a lot easier to maintain with all the terrible state handling
Config option added and reduced back to just fixing the issue.
Rebased.
This PR looks great and even offers a switch option, can the review be completed
Fix breaking tripwires with shears, fixing string dupe allow-shears-disarmed-tripwire: false
https://github.com/PaperMC/Paper/assets/135555687/ad7d6679-24c8-40b7-bda8-99fb1c591388
Works perfectly,even offers a switch option
allow-shears-disarmed-tripwire: true
https://github.com/PaperMC/Paper/assets/135555687/335739c3-ed81-4d56-a0c6-51cf87d3e53d
As far as I know, Forge did this a long time ago Test everything works as expected. Can the code approve the merge. ꒰^ↀωↀ^꒱❤
Since it seems unclear in this PR, has tripwire duping been patched? If so, is there a configuration option to opt into allowing it as discussed in #9542?
I can't seem to find allow-shears-disarmed-tripwire
in the docs, so I'm guessing this PR was abandoned and superseded by something else perhaps (since certain users report being unable to make use of this duplication glitch even though this PR might not have been merged).
Some variation of tripwire duping remains, this should patch them, however, it has wider behavioral changes for the solution, and so, this specific variant has a configuration option Do note that we generally do not add configuration options for bug fixes
Since it seems unclear in this PR, has tripwire duping been patched? If so, is there a configuration option to opt into allowing it as discussed in #9542?
I can't seem to find in the docs, so I'm guessing this PR was abandoned and superseded by something else perhaps (since certain users report being unable to make use of this duplication glitch even though this PR might not have been merged).
allow-shears-disarmed-tripwire
TNT isn't it?
Some variation of tripwire duping remains, this should patch them, however, it has wider behavioral changes for the solution, and so, this specific variant has a configuration option Do note that we generally do not add configuration options for bug fixes
Why should only one variation of tripwire duping include a configuration option over the other kinds?
Committed manually because easier and without the config option - sorry for how this pr was handled, we were still figuring out how to best deal with such fixes, made worse by how this being a thing for so long also created a kind of behavioral expectation outside of the dupe