Patch: Adds delayed regeneration on Towny protected blocks

[GoogleCodeExporter]

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.

Original issue reported on code.google.com by phrst...@gmail.com on 10 Sep 2011 at 6:39

Attachments:

• towny-delayed-protection-regen.patch

[GoogleCodeExporter]

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.

Original comment by phrst...@gmail.com on 10 Sep 2011 at 8:25

[GoogleCodeExporter]

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?

Original comment by Hurfapotamus@gmail.com on 10 Sep 2011 at 3:58

[GoogleCodeExporter]

Hurfapotamus, that's the idea.

Original comment by phrst...@gmail.com on 10 Sep 2011 at 4:00

[GoogleCodeExporter]

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.

Original comment by phrst...@gmail.com on 11 Sep 2011 at 5:02

Attachments:

• towny-delayed-protection-regen-v2.patch

[GoogleCodeExporter]

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?

Original comment by zrenf...@gmail.com on 11 Sep 2011 at 6:07

[GoogleCodeExporter]

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

Original comment by phrst...@gmail.com on 11 Sep 2011 at 6:33

[GoogleCodeExporter]

[deleted comment]

[GoogleCodeExporter]

[deleted comment]

[GoogleCodeExporter]

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.

Original comment by Elg...@palmergames.com on 11 Sep 2011 at 8:52

[GoogleCodeExporter]

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.

Original comment by Elg...@palmergames.com on 11 Sep 2011 at 9:03

[GoogleCodeExporter]

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.

Original comment by zrenf...@gmail.com on 11 Sep 2011 at 9:56

[GoogleCodeExporter]

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.

Original comment by phrst...@gmail.com on 11 Sep 2011 at 9:59

[GoogleCodeExporter]

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.

Original comment by Elg...@palmergames.com on 12 Sep 2011 at 12:03

[GoogleCodeExporter]

[deleted comment]

[GoogleCodeExporter]

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.

Original comment by Elg...@palmergames.com on 13 Sep 2011 at 3:53

[GoogleCodeExporter]

Fixed up and added for possible use later in one of the war mods.

Original comment by Elg...@palmergames.com on 13 Sep 2011 at 4:45

• Changed state: Fixed