Per world Auto-zoning

[BobKare]

Hey!

All Minecraft servers' biggest problem is griefing. It's hard to avoid on popular servers, where you are, for example, 5 mods/ops against 50 guests.
This is hard situation. You basically can't zone all buildings on the world, and you fly around using /B on all grief, ban as hell, and you know the rest of the story.

What I suggest, is probably not something that is that's done in five minutes.
It's simply an option to enable per world Auto-zoning!

What you do, is that you enable this option in-game. It may be related to block-tracking.
You can also set a world-/server-wide highest rank limit for this.

What it does, is automatically zoning all blocks placed by (maxRank) and below for (buildRank) +playerPlacedBlock!

To use the fCraft server for an example:

It's enabled on main, where all blocks placed by guests can't be modified by other's than the player who placed it, and (let us say...) vets+!

I hope this isn't too messy, if you got any questions about the suggestion, just post them, in a friendly way, please

Thanks,

~BobKare

[Sanjar Khan]

A zone per each individual block? I'd love something like that, but I have no idea what it would do performance wise.

[BobKare]

I thought if it could be related to the BlockDB, since that one already saves who built a block...

[fragmer]

This has been suggested before, although I cant find the old discussion. Basically - I will NOT add this feature, and here is why:

• First of all, there are serious performance implications from checking BlockDB on every click. BlockDB is optimized for append/write access, so it is laid out on disk in linear chronological order. Writes to BlockDB are fast - they are buffered and batched to minimize disk i/o. The buffer has to be flushed on-read (e.g. when doing /undoplayer or /bi). Reading from BlockDB on every click would defeat buffering, dramatically increase disk i/o, and create a massive performance bottleneck.
  
  One solution to this would be to keep a copy of the entire BlockDB in memory, but that would increase RAM use significantly, and still burn a lot of CPU for repeated linear scans.
• Although this system will help prevent block DELETION, it will do nothing to stop block PLACEMENT (spam). For example, interior of a building will almost always have air blocks that have not been modified by the building's creator. A griefer could spam blocks all over the interior, and the very system that you are suggesting will make it hard to remove the spammed blocks.
  
  A possible solution to this problem would be to create an "aura" of ownership around original builder's blocks, e.g. preventing edits in a 5x5x5 area around placed blocks to protect house interiors. This scheme would also make performance issues much worse (requiring 125 BlockDB queries per click).
• This system would also prevent cooperative builds, or require storing who's-allowed-to-edit-whose-blocks exceptions.

EDIT: Clarity

[BobKare]

This has been suggested before, although I cant find the old discussion. Basically - I will NOT add this feature, and here is why:

• First of all, there are serious performance implications from checking BlockDB on every click. BlockDB is optimized for append/write access, so it is laid out on disk in linear chronological order. Writes to BlockDB are buffered and batched to minimize disk i/o, and the buffer has to be flushed on-read (e.g. when doing /undoplayer or /bi). Reading from BlockDB on every click would defeat buffering, dramatically increase disk i/o, and create a massive performance bottleneck.
  
  One solution to this would be to keep a copy of the entire BlockDB in memory, but that would increase RAM use significantly, and still burn a lot of CPU for repeated linear scans.
• Although this will help prevent block DELETION, it will do nothing to stop block PLACEMENT (spam). For example, interior of a building will almost always have air blocks that have not been modified by the building's creator. A griefer could spam blocks all over the interior, and the very system that you are suggesting will make it hard to remove the spammed blocks.
  
  A possible solution to this problem would be to create an "aura" of ownership around original builder's blocks, e.g. preventing edits in a 5x5x5 area around placed blocks to protect house interiors. This scheme would also make performance issues much worse (requiring 125 BlockDB queries per click).
• This system would also prevent cooperative builds, or require storing who's-allowed-to-edit-whose-blocks exceptions.

I'll take that as a no.

Thanks for fast reply

[Intertoothh]

Well, i think its best left for a plugin.
But a system like the /home.

Where a rank, could claim a region of the map. Ofc limited in size.
He then can add people to 'his' home. There are some smp plugins that work this way.
When the plugin system of fcraft is completed i think its not that hard to implement/build.