TownyAdvanced / Towny

Towny Advanced Minecraft plugin for Bukkit/Spigot.
https://townyadvanced.github.io
Other
507 stars 352 forks source link

Patch: Adds delayed regeneration on Towny protected blocks #296

Closed LlmDl closed 8 years ago

LlmDl commented 8 years ago

Originally reported on Google Code with ID 259

This patch creates "delayed regeneration" on Towny protected blocks.

This fixes an issue where players who own Towns can create "vaults" and protect large
amounts of chests by walling in a room inside of a Towny protected area.

The delay is fully configurable, and setting the delay to 0s causes Towny to fallback
to the old behavior.  By default, the delay is set to 0s.

Reported by phrstbrn on 2011-09-10 06:39:52


LlmDl commented 8 years ago
Some caveats I've found with some more testing:

1) Signs "blank" when they regen
2) Sand/Gravel blocks falls after it regens if the block below it is air
3) Redstone "pops off" if it regens while the block below it is missing (this may apply
to crops/grass/more, haven't fully tested this yet)
4) Torches "pop" off when their attached block is missing (this bug is probably the
same for all Attachable)

Not sure if there are any other edge cases that I've missed.  I'll be patching these
as well once I figure out a good workaround.

Reported by phrstbrn on 2011-09-10 08:25:07

LlmDl commented 8 years ago
Just want some clarification on this. This delayed regeneration is happening when a
player without permission to destroy, destroys within a protected area. This allows
them to make a hole in a wall for instance, and then the hole would seal back up slowly?

Reported by Hurfapotamus on 2011-09-10 15:58:42

LlmDl commented 8 years ago
Hurfapotamus, that's the idea.

Reported by phrstbrn on 2011-09-10 16:00:35

LlmDl commented 8 years ago
Okay, this patch should fix all the issues presented with the initial proof-of-concept.

I've tested and am unable to find another edge case that isn't accounted for at this
point.

Reported by phrstbrn on 2011-09-11 05:02:43


LlmDl commented 8 years ago
Have you tested it with the delay value at 0 (what most users will want)?
Signs that are not attached (with a signpost)?
Chests won't respawn with contents.
What about other container blocks?
Beds.
Mob Spawners.
Noteblocks.

Restrict this ability to a permission.

What do placeholders in TUniverse do?
if not: run task, cancel. Task deletes+reforms.
if so: delete and remove from the placeholders. Is this for bug testing?

Has this crashed on you? Is it unstable?

Reported by zrenfire on 2011-09-11 06:07:18

LlmDl commented 8 years ago
Delay of zero doesn't fire off any of this code, and behaves exactly like regular towny.

Signpost signs worked fine in testing

Chests/Noteblocks are unbreakable if they are in switch IDs.  Should be the same with
all containers.  LWC locked chests/ChestShop locked chests didn't break either if they
were locked, so I'm sure it's fine.  This behavior is OK in my opinion, if they can
switch the chest, they should be able to take everything/steal it, so breaking is okay
too, imho.

Not sure what the issue with Mob Spawners would be.  Could you clarify?

Beds respawn fine, but I didn't think to check what happens if the player who sleeps
in that bed dies.  I can double check that.

I can add a permission nodes which disables this feature completely without the permission
and the timer.

Some blocks "break" when respawning if the block underneath is air (redstone, crops,
mushrooms).  The placeholders are created to prevent those blocks from breaking.  It
also prevents sand and gravel from falling if it respawns on top of an air block. 
The only time this happens is if you break the block underneath after you break the
block on top, and when the block on top respawns, it respawns under air.  If this behavior
is undesired, I could attemp recurse until the block under it respawns as air, but
this could theoretically create an infinate loop, and breaking out would either the
block would have to disappear, or reappear on top of air and break.  Not sure if this
behavior would be more desirable.

No known crashes

Reported by phrstbrn on 2011-09-11 06:33:50

LlmDl commented 8 years ago
Ok, there are numerous bugs in this. Nice idea though Fix it up and I'll definately
add it.

1. If you break a dirt block under planted wheat, the block is replaced but the wheat
is destroyed. It's not testing the block above.
2. If you break a block causing sand to fall in it's place. You can then break the
sand which will trigger a Task. You end up with the first block being replaced, then
that being replaced by sand during the second Task.
3. There is an issue with block.setTypeId(0, false). It will be over ridden by the
cancelation of the onBlockBreakEvent. The client replaces the block before this code
does.
Performing the setTypeID and THEN overriding the physics works...eg
            block.setTypeId(0);
            block.setTypeId(0, false);
As it sends a client update on teh change, but stops teh physics. Else you must catch
onBlockPhysics and prevent blocks falling and other bits in there.

In fact it would make more sense to override the physics than placing false blocks.

Reported by ElgarL@palmergames.com on 2011-09-11 20:52:08

LlmDl commented 8 years ago
oh, if you implement onBlockPhysics then you must test on the block location not on
the block object, as the object may have minor changes for light etc.

Reported by ElgarL@palmergames.com on 2011-09-11 21:03:48

LlmDl commented 8 years ago
I was running through blocks that I *think* might have extra data other than getData()
like container blocks. Since you don't seem to store data for them (or at least reform
it) in the cases I mentioned.

Reported by zrenfire on 2011-09-11 21:56:57

LlmDl commented 8 years ago
What are the "other blocks".  Chests drop their loot when you break, unless they are
in switch_ids, in which case you can't break them at all.  This behavior seems OK to
me.

Reported by phrstbrn on 2011-09-11 21:59:07

LlmDl commented 8 years ago
I'd like to add this, but I've had a play at recoding parts and it seems there's bugs
in bukkit or MC which cause a sand block to fall no matter if you cancel the physics
event or not.
I can prevent the cascade of sand from above, but the single block you set as sand
always falls.

Reported by ElgarL@palmergames.com on 2011-09-12 12:03:04

LlmDl commented 8 years ago
I have this about as 'fixed-up' as possible at the moment. The only bug I can see is
if you break multiple blocks of soil under crops teh crops will sometimes break, even
with canceling the physics/break events.

I'll test it a bit more, but I'm undecided if it should be added.

Reported by ElgarL@palmergames.com on 2011-09-13 15:53:33

LlmDl commented 8 years ago
Fixed up and added for possible use later in one of the war mods.

Reported by ElgarL@palmergames.com on 2011-09-13 16:45:47