I'm starting to run my first Minecraft server (using Bukkit latest on 1.7.4), and for the most part I just want it to be a base game. However, to protect a few things, I of course need a couple of plugins. (Particularly this is to use WorldGuard to protect specific areas that were complex to build. I can always restore from backup, but if a lot of time passes before I notice a problem then that's not really a win.)
While I can use WorldGuard to accomplish what I need, I would prefer if it's a base game for other players. Is there an easy way to accomplish this?
The closest thing I could find was this question, particularly the top two answers. The accepted answer looks good, but it seems to just disable the listing of plugins and not the actual interaction with them. A user could still simply try various commands and find the plugins. The next answer involves aliasing several things to the /help
command, which also helps. However, I'd also have to build a custom /help
response and alias all possible commands (plugins included) except the base commands, and I don't have those lists of commands. It also seems like a losing game, especially if an update changes/creates commands. Additionally, it looks like I'd be overriding the commands for myself as well, which isn't desired.
Is there any way to achieve what I'm trying to do? I just want WorldEdit/WorldGuard to be entirely unknown/inaccessible to other users so they just have a base game (and can petition me to "protect" areas they want to protect).
Or am I going about this all wrong? I've only ever played the base game, no mods, and have only ever played locally. So I'm very much in uncharted territory with mods. I guess I just want to make sure that I'm not opening up more than I should, since I don't have a complete picture of what these mods allow users to do.
Best Answer
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 theplugins/PermissionBukkit
directory after it is run for the first time. For example, if you want to prevent everyone but your trusted moderatorsteve
from listing plugins, a simple configuration as follows will do.Any player that is not specifically configured with permissions is assigned to the
default
permissions group. With that in mind, any player other thansteve
or you (I'm assuming you're set up as ops), will be assigned the permissionbukkit.command.plugins
with a value offalse
, which denies them from using the/plugins
command. However, becausesteve
is assigned to the groupmoderator
he gets the same permission token but with a value oftrue
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 fromdefault
. Essentially, what this means is that groupmoderator
will have the same permissions as groupdefault
adjusted accordingly by the permissions assigned directly to it. In this example,moderator
inherits thefalse
value, but then overrides it with atrue
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:
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.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 developersk89q
who also authorsWorldEdit
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 inbukkit.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.