Opportunity for Comment: World Edit Changes on C and new Policies

[jchance]

 

We will soon be adding WorldEdit to C that is limited to regions that you are the region owner.    This change will require several changes in policy and general moderation procedure on C.

 

A few key points need to be addressed:

 

• Region / Protection Policy:  Players want to use WorldEdit to build in their region, so we can't just issue protections after something is already built like current policy states.
   
• Moderation Policy:  Moderators will have access to much broader permissions, so we need a way to prevent (for the most part) relatively inexperienced mods from doing major damage to the map. Region naming nomenclature needs to be standardized for all regions and shape and size considerations must be made.

 

Region / Protection Policy:

 

Old Policy:

 

We will only protect things after they are built- no protecting empty land.

 

New Policy:

 

We will create world guard regions for areas, with the region outline clearly marked with a border rectangle, before something is built so that players can use WE to clear land, build, etc.  Players can remove the rectangle once they've have actually built in the region.

 

The rectangle (not just 4 corners) is important- 

• it keeps players from just flying around placing 4 blocks to mark a huge area.  They at least have to put the time in to making a border.  
• It marks the area so other players know something is going there.   Protections without builds and without a marker rectangle around the region would just piss people off
• It makes moderation easier.   Less risk of overlapping regions.   Easy to see when land is utilized.

 

Griefing / Region Ownership Policies, etc:

 

When a region is created the player is set as owner and their player name is part of the region name as outlined below in moderation changes, making them the primary owner.  

 

Owners get world edit permissions in their own region.  Members do not get World Edit permissions.

 

If they add another owner then that is 100% their decision that they have to live with. 

 

Mods should never add new owners to a region and should instead instruct the player how to use the /region addowner command.  

 

Primary Region owners (the person with their name in the region) can make a modreq to have other owners removed.   The primary region owner is the ONLY person who can have another owner removed.  There will be no exceptions to this policy.  If your name is not in the region name you can not remove owners. 

 

If a player gives region owner permission to someone else and they do something the primary owner doesn't like, be it World Edit or otherwise, then that is on the region owner.   This is not grief.  This is the primary region owner making bad decisions.  The same goes for if you add another owner and that owner adds more owners- again, bad decision making on the primary owner's part.  

 

In short, once a region is given to the primary owner it is theirs to manage (and deal with the consequences) as they see fit.

 

We're bringing personal responsibility back to Creative.

 

Parent / Child Regions (Cities):

 

The plugin that limits World Edit to regions works like this:

• Parent region owners (mayors of towns) can world edit in both the parent and child regions.
• Child region owners (plot owners) can only world edit in their child region.

The same rules that have always applied to parent/child regions still apply:   

 

If you have given a child region to someone else you do not get to modify other people's builds in that child region.    

 

Parent region owners (city mayors, if you like) may make a mod request to have a build that does not fit their city style moved out of the city.    

 

Parent region owners are not allowed to just remove or modify builds they don't like.  You gave the child region owner the reasonable expectation of ownership of their plot and freedom from interference. 

 

 

New Moderation Policy:

 

Modmode Procedure is now Required on Creative:

 

All Mods on C are expected to use Modmode only for moderator duties and not to use Modmode for regular gameplay.  

 

This is in line with policy on other servers.

• Moderators outside of Modmode will have the same permissions as default players in respect to World Edit. (meaning they can use WE inside regions they are owner)
   
• Moderators in Modmode will have global world edit permissions to help players, do mod duties, etc.  (meaning they can use WE outside of regions they own)

This change is necessary to prevent moderators from accidentally using World Edit outside their own regions and overlapping in to others protections.   A mod, using mod mode, and using world edit in regular building gameplay is a risk to other players since they can override region limits.

 

This policy will be actively enforced on C for the protection of the community.    Mods not following proper Mod Mode policy (only using Mod Mode for moderator duties)  will be warned, and continued warnings will lead to loss of mod status.

 

Region Creation:

 

Regions must follow the playername_regionname format.   

 

This is important so we know the original, primary owner of a region.  This used to be standard operating procedure on C, but I've seen new mods move away from it.  We need to bring the standard region name format back. 

 

Regions will have the new created at flag added that shows the date the region was created.  This will be added to the /cregion command and automatic.

 

Unused regions may be removed or resized smaller after 2 weeks by mods or admins.  Everyone will be able to check the created at flag on the region using /region info.

 

We're also adding a "Created by" flag to regions so we can see who created what region.

 

Land Disputes, Region Resizing, Clearing of Derp:

 

Land disputes will still be handled at a C admin's discretion.

 

Resizing of existing regions and clearing of derp regions, of which there will probably be many, will be handled at a C admin's discretion.  A derp region, for example, would be one where some player joins, makes a giant sponge or lava cube, and then abandons it never to return.  These can be submitted in an admin mod request for removal and will be removed based on the last /seen time for the player and last edit time in the region.

 

Things that Must Be Avoided:

 

Overlapping Regions

 

Bad.  Both region owners can world edit in the overlapping area.  Don't make them.

 

Protip:  the "/region-intersects" command tells you if any regions intersect your current selection.   Thanks Denevien for the reminder!

 

Poly Regions can no longer be used

 

The world edit / world guard plugin we are using does not support poly regions.  Only cuboid regions can be used on C once the new plugins are activated.  Poly regions still work for protection, but you can't use world edit in poly regions you are an owner of- only cuboid regions.

 

Some Questions that have been brought up already (and answers!):

 

 

 

Are we setting a maximum size for new regions? If so, are there exceptions for larger builds like cities, or would they have to start with a small region and get it expanded later?

 

 

 

We don't have a maximum size now so I don't really see the need to set one.   I combined the land claim policy (make a rectangle around the area to claim land) and the region policy so that they can't just put out 4 wool blocks and claim a huge area- they actually have to spend the time to mark a large area if they're going to claim it.

 

Having a max size makes it too ambiguous-  How do you determine the max size?  Is it by volume? What if they use //expand vert, does that count the air? Is it by X and Y length (requiring mods to do math based on the coordinates)?  

 

Then, what are the criteria for getting larger than a max size?  How do you determine, before anything is built, if something deserves a bigger than normal region?  

 

It just seems like it would open mods and admins to claims of favoritism like "You gave Bob a 300x300 region but you only gave me 100x100!" and be hard to regulate and administer.

 

  Should we set any restrictions on moderators creating regions for themselves like P has(mods must not make regions for their own builds), or would creating the box be sufficient?

 

This has had some discussion amongst admins.    I don't have a strong opinion one way or the other as I believe that if you are a moderator you can be trusted to make your own regions.   However, there have been issues on other servers in the past.

 

I'd like to leave it as "If you have any doubt about what you are about to do and if it may be seen as mod abuse, then ask another mod or admin for their opinion and/or to do it for you."

 

Some say its better to ask for forgiveness than to ask for permission.  I do not agree and I will not look favorably on a mod who does something that is clearly  against policy or abuse.  When in doubt ask somebody.

 

 

  For players who don't wish to use WE for their builds, are they required to create a box around their build too, or could we just apply the old policy and create a region around what they've built?

 

 

For players who don't want to use WE to build they can just build like normal- We can always protect structures as we've always done.   The new policy changes proposed above only apply to new "empty" protections.

 

 

  Is there a hard-coded limit on the number of blocks that can be worldedited at a single command? I could see that being an issue of straining the server with grand edits in particularly large region boxes. Likewise, do we have a list of blocks that should not be worldeditable for their penchant of crashing servers, such as cacti, doors, etc?

 

 

We can limit the size of edits by user group (default, mod, admin) and block problem items from world edit completely.    I did not include those settings in this discussion since Its not really something we will expose to mods or the community to discuss per se- I will have to sit down with a tech admin and determine what they think is safe for Creative, and it will probably have to be modified once its actually been in use and we've seen the impact.   

[jchance]

Oh, and one other thing:

 

For those who do not know, we use Async World Edit on all Nerd.nu servers.   This should noticeably decrease the impact of using world edit by multiple people (at the expensive of slower edits as needed- it automatically queues jobs).

 

I'm pretty sure we'll crash the server a couple times figuring out the right limits.  You can't make an omelette without cracking a few eggs.

[Trooprm32]

These are some very impressive new changes, bravo jchance.

[jchance]

More information on the change-

 

This is what players will have access to.   Some commands will be limited in radius or size TBD by tech admins.

- worldedit.clipboard.cut
- worldedit.clipboard.paste
- worldedit.drain
- worldedit.fixlava
- worldedit.fixwater
- worldedit.generation.cylinder
- worldedit.generation.pyramid
- worldedit.generation.sphere
- worldedit.history.redo
- worldedit.history.undo
- worldedit.navigation.jumpto.command
- worldedit.navigation.jumpto.tool
- worldedit.navigation.thru.command
- worldedit.navigation.thru.tool
- worldedit.region.curvy
- worldedit.region.faces
- worldedit.region.line
- worldedit.region.move
- worldedit.region.overlay
- worldedit.region.replace
- worldedit.region.set
- worldedit.region.stack
- worldedit.region.walls
- worldedit.selection.*
- worldedit.selection.contract
- worldedit.selection.expand
- worldedit.selection.hpos
- worldedit.selection.inset
- worldedit.selection.outset
- worldedit.selection.pos
- worldedit.selection.shift
- worldedit.snow
- worldedit.superpickaxe
- worldedit.superpickaxe.area
- worldedit.thaw
- worldedit.wand

Of course, if any of these cause major problems or lag we'll have to remove them.    This is all pretty new for everybody.

[SirTacoface]

Very nice! I'm glad you followed through with this, I'm sure there will be many people who will be very happy. Looks like C has a bit more moderating to do! :D

[Bardidley]

Looking forward to this jchance, nice work.

[3c33]

Freaking Awesome! jchance for president!

[Diamond_Lover123]

Regarding the new mandatory username_regionname format, what will do about current regions that do not follow this format? Also, do we need to use exact usernames, or could we shorten them a bit (DL123_build rather than Diamond_Lover123_build for example)?

[jchance]

Regarding the new mandatory username_regionname format, what will be do about current regions that do not follow this format? Also, do we need to use exact usernames, or could we shorten them a bit (DL123_build rather than Diamond_Lover123_build for example)?

 

 

There is nothing we can do about existing regions other than to recreate them (to my knowledge its impossible to rename regions).

 

We can shorten usernames- we just need enough to be able to identify the primary / first owner or a region for moderation purposes.   DL123 is pretty obvious thats Diamond_Lover123.     However,  Taco_something wouldn't be good enough since there is SirTacoFace, TacoDude, xX_Taco_Waffle_Xx, etc.

[Trooprm32]

There is nothing we can do about existing regions other than to recreate them (to my knowledge its impossible to rename regions).

 

We can shorten usernames- we just need enough to be able to identify the primary / first owner or a region for moderation purposes.   DL123 is pretty obvious thats Diamond_Lover123.     However,  Taco_something wouldn't be good enough since there is SirTacoFace, TacoDude, xX_Taco_Waffle_Xx, etc.

 

/region rename exists, atleast on PvE, and is also an admin only command.

[jchance]

/region rename exists, atleast on PvE, and is also an admin only command.

 

 

Yeah, I was speaking from the perspective of mod permissions though.  Its a fairly simple operation for a mod to /rg select regionname, /cregion new_regionname player name using the same selection, then /region remove old region.

[Trooprm32]

Yeah, I was speaking from the perspective of mod permissions though.  Its a fairly simple operation for a mod to /rg select regionname, /cregion new_regionname player name using the same selection, then /region remove old region.

 

True enough. /region rename would also add all existing owners to the new named region, and it may not be easy to distinguish who originally created the region as well, so it could get sticky in regards to that.

[WayneByNumbers]

 Poly Regions can no longer be used

 

The world edit / world guard plugin we are using does not support poly regions.  Only cuboid regions can be used on C once the new plugins are activated.  Poly regions still work for protection, but you can't use world edit in poly regions you are an owner of- only cuboid regions.

 

A little confused by this one.  Does this mean that poly regions have been disabled/disallowed completely, or that we can still make them for protection if a player doesn't care about world edit in that region?

[TheRandomnatrix]

A little confused by this one.  Does this mean that poly regions have been disabled/disallowed completely, or that we can still make them for protection if a player doesn't care about world edit in that region?

Based on the wording, looks like poly regions will work, but won't interface with the plugin for limiting to regions and would be discouraged.

[jchance]

Poly Regions still work for protecting things.    Players just won't be able to use world edit in poly regions that they own like the standard cuboid ones.

 

We'll be adding /region rename to mod perms with the update also.

 

 

 

I have Slide lined up to get the config moved from C-Dev to C and help me double check perms and settings.  We're aiming for a release tonight as long as everything goes well.

 

[jchance]

WorldEdit has been released on creative:  https://nerd.nu/forums/index.php?/topic/2739-creative-now-has-world-edit-and-the-map-expanded/#entry20859

[Trooprm32]

Just a couple of things I can think of at the moment that would be nice to have: //info and //count.

 

Edit: No //count lol, but  //rotate and //flip are definitely needed.

[schererererer]

Heavily seconded - //rotate, //flip, and //stack are imo the three most important tools for accelerating an otherwise repetitive section of building.

[jchance]

//rotate and //flip have been added.