Welcome to the wonderful world of CraftBukkit server administration. It can be a scary and frightening trip, but with some forethought and planning you will be able to control your player’s access levels to however you see fit.
The short answer is that you need a permissions plugin such as PermissionsBukkit, PEX, etc. that lets you tailor access levels for specific players, groups, or a combination thereof.
That said, there is a learning curve on how to set up permissions and staying current with plugin changes. Because this would be your first foray into permissions configuration, I recommend that you begin with PermissionsBukkit. This is not the place to give you a full permissions tutorial, but I will highlight some key points.
Almost all permission systems are based on the concept of users and groups to which individual permissions can be assigned that either allow or deny access to a plugin’s command or feature. In the case of PermissionsBukkit, permission configurations are maintained in config.yml
, which will be located inside the plugins/PermissionBukkit
directory after it is run for the first time. For example, if you want to prevent everyone but your trusted moderator steve
from listing plugins, a simple configuration as follows will do.
users:
steve:
groups:
- moderator
groups:
default:
permissions:
bukkit.command.plugins: false
moderator:
permissions:
bukkit.command.plugins: true
inheritance:
- default
Any player that is not specifically configured with permissions is assigned to the default
permissions group. With that in mind, any player other than steve
or you (I'm assuming you're set up as ops), will be assigned the permission bukkit.command.plugins
with a value of false
, which denies them from using the /plugins
command. However, because steve
is assigned to the group moderator
he gets the same permission token but with a value of true
allowing him to use the command.
I'll quickly touch upon the notion of inheritance. In the above configuration, the group moderator
is set up to inherit permissions from default
. Essentially, what this means is that group moderator
will have the same permissions as group default
adjusted accordingly by the permissions assigned directly to it. In this example, moderator
inherits the false
value, but then overrides it with a true
value.
While this example doesn't achieve what you want to do, it does show you how to enable or disable a command, the concept of which can be extended to any plugin command or feature. Once you become accustomed to thinking in terms of permissions, configuration will become easier.
Obviously the next burning question is "What permissions I can set for a plugin?" Most plugin developers do a pretty good job of documenting permission configurations, but it wouldn't be the first time that developers release a new version and completely turn the commands and permissions upside down without leaving a hint or clue in the documentation. Fortunately, it doesn't happen too often and you will eventual learn which one of your plugin developers is such a culprit. Performing due diligence on a plugin is the only cure to avoid those problems with certainty during an upgrade.
There are several steps you can take to shield yourself from configuration nightmares and get as much information about a plugin's commands and permissions:
- Your first line of defense is to devour a plugin's documentation. Most developers provide configuration information that explains what commands and features you can control on BukkitDev.
- Your second line of defense is to open the plugin JAR file with WinZip, WinRAR, or similar compression software. JAR files are just a special version of ZIP files. Therein you will see a
plugin.yml
file which you can open up with any text editor (e.g. NotePad++, vi, etc.). Any plugin developer worth his or her salt will document plugin commands and permissions within this file.
- Your last line of defense is to review a plugin's source code. Most plugins, will have links to a source code repository (e.g. GitHub, BitBucket, etc.) that let you browse through Java code and get an idea of what permissions do what.
If you aren't a programmer, source code will probably be cryptic and not serve you well in gleaning additional information; but, you never know, it might peak a new interest. Our server has a strict policy for only using plugins with published source code. This policy ensures that we can assess the quality of programming and that we can maintain it ourselves should its developer disappear (happens quite often). Above all, avoid plugins whose descriptions start off with I'm new to Java, but I made this plugin... This is my first plugin... This works great on my private server... You get the point.
Don't bother looking at the plugin.yml
file for WorldGuard. Its a great plugin (though we use Residence), but its developer sk89q
who also authors WorldEdit
insists on doing permissions his own way - the details of which make an interesting read. You will have to solely rely on his documentation (wiki.sk89q.com/wiki/WorldGuard) since there is no additional information in bukkit.yml
Alright, I will stop here before I start discussing the finer points and intricacies of plugin administration and configuration. I hope that this will point you in the right direction. Best wishes to your venture.
Best Answer
There is no simple command to do this, at least in Vanilla. But you could use a ridiculously complicated system of commands to reach the same effect. And who doesn't like that?
First, spawn an armour stand at the lowest X and Z coordinate of your area, high in the air:
Then run these two commands for at least as many times as the area is long in the X direction (more doesn't matter much, except for performance, so I recommend just leaving a repeating command chain on for a few seconds):
This should give you a long line of hovering armour stands.
Now you let this line spawn lots of non-hovering armour stands. Those will fall down and land on the top block of the column they're in.
Warning: Water, lava, signs and other blocks that armour stands can fall through might mess with this. Also end crystals like placing fire below themselves in many situations, potentially overwriting your slabs.
And, of course, this creates a TON of lag. You should better stay in a position where you can turn the lever off again at any point and just look at the coordinates in chat (command output) to determine when to deactivate it, because even entering commands lags a lot if you full your entire End island this way.
Then you wait a bit until all armour stands have fallen and run these two commands (if you don't trust that all chunks are loaded, you can also run these together in a chain multiple times):
And finally you can also kill the other armour stands:
Another warning: This only works for the top layer of each column. In spots where there is e.g. End stone above three blocks of air above more End stone, then it still leaves those spots uncovered. A ridiculous solution would be to run this entire system on every single Y layer.
Alternatively you could use spawning to your advantage. Simply use these three commands in a repeating and a chain command block:
Then wait for an hour or so and most of the End should be slabbed, at least from 32 to 128 blocks around you. Move around occasionally if you also want the rest to get slabbed, but usually the End has a radius of 128 and no caves very close to the center, so if you just stand in the middle, it should leave out very few spots.