Minecraft – Disabling Nametags Vanilla

If the total cost to repair an item is greater than 39, it cannot be repaired in survival mode. You can use the RepairCost nbt tag to make it too expensive to repair an item in an anvil. For example, this command will spawn a Power 10 bow that cannot be repaired with an anvil:

/give @p minecraft:bow 1 374 {ench:[{id:48,lvl:10}],RepairCost:40}

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.