Bukkit

In reply to gonzalo20o0:

 you would need to deny the playerheads.clickinfo permission in your permissions.yml or permissions plugin.  In some plugins you can set the permission to Deny, some other you have to give the permission with a minus sign in front to negate it instead of denying

In reply to gonzalo20o0:

 I would recommend adding a plugin like LuckPerms (or at your preference: GroupManager or PermissionsEx).  Then you can use /lp group default permission set playerheads.clickinfo false  or the equivalent which sets the permission to deny for everyone (everyone is in the default group for LP).   There are also user-specific permissions commands if necessary.

A permissions plugin will make it easier to manage permissions from plugins without needing to edit the YML and adds the ability to assign people to permission "groups" for users like staff or VIP.

Permissions are a fairly standard feature for modifying many different plugins behavior, so a permissions plugin is almost a must these days.

In reply to LastChip:

 I don't have this behavior on our server or tests.

  I would recommend checking that you used /lp group groupname permission set playerheads.alwaysbehead deny - then you can look for possible other problems:

/lp check usernamehere playerheads.alwaysbehead  will tell you if a player receives the permission (collectively from their personal permissions, their groups, etc).

/lp group groupname permission check playerheads.alwaysbehead will tell you if the group has the permission

/lp group groupname permission checkinherits playerheads.alwaysbehead will tell you if the group inherits that permission from elsewhere.

Luckperms groups also have "weights" which mean higher-weighted groups override permissions from lower-weighted ones, if you have any other groups.

Finally, using the star permission "playerheads.*" or "*" is strongly not recommended and instead you should give specific command permissions.

If you're still unable to identify the source of the permission, please send the groups the user has, the permissions for the groups, and your PlayerHeads config and I will try to identify/reproduce your problem. (pastebin.com is preferred for posting long text).

In reply to Beaushangles:

 If you scroll down you'll see I've answered this question a few times.

You need to deny the playerheads.alwaysbehead and playerheads.alwaysbeheadmob permission in your plugin or permissions.yml.  How you do this depends on whether and which permissions plugin you use (I recommend LuckPerms).

Why does this happen? Well, it honestly shouldn't, because I have these permissions set to be denied by default, even for ops (in recent releases).  So this is usually due to overzealous permissions plugins, the use of the playerheads.* permission, or an outdated version of PlayerHeads.

Some questions that will help reduce my own hair-pulling:

 Which permissions plugin do you use, if any? which exact PlayerHeads version are you using? Which server /version are you using?

Thank you

EDIT: I'm unable to reproduce this issue on 1.8 or 1.16.5 servers with either v4.7.0 (three years old) up to v5.2.15 (newest alpha) without a permissions plugin - neither regular players nor ops received 100% droprates / alwaysbehead.  So I'm thinking this must be either playerheads.* permission or the specific permissions plugin.

In reply to Beaushangles:

 "-The most recent one, I just downloaded it yesterday!!!!"

The reason I have to ask and I usually ask for a specific version is because there are currently four "most recent versions":

one development build (5.2.15), two alphas/betas (5.2.14 and 5.2.13), and the release version (5.2.12).  

If you go through BukkitDev, the alphas and betas are presented to users first (but only on the Files tab),  through CurseForge they present the Release first and the alphas/betas second.   Or if you go through the CI or Github you end up with either the development version or other odd versions.

It seems like an obvious thing but it really isn't, and it wasn't intended to point any fingers - just I wanted to determine which versions cause the issue and which don't so I can see what needs to change.

In reply to Beaushangles:

 >jperms

Checking their source code, that plugin gives you every permission of the plugin if you use "playerheads.*" - it does not check which nodes the plugin configures nor their defaults - meaning it ignores a significant part of the standard. (ref: Plugin YAML permission nodes)

If you are using the star permission, I highly recommend you do not use it with jperms. If it grants it by default to ops and also doesn't check the plugin's permission nodes, then I have no way to help you.  I would recommend using a more fully-featured permissions plugin (LuckPerms, PermissionsEX, and GroupManager are some more well-known ones).

>denying

I don't know how you deny permissions with jperms, I didn't see a way to do so in their code.

In Permissions.YML and some plugins, you deny permissions by giving a permission with a hyphen in front - like "-playerheads.alwaysbeheadmob".

In a lot of plugins, they have an explicit command to deny a permission to a user or group (luckperms:  /lp user usernamehere permission set playerheads.alwaysbeheadmob deny)

In reply to oohacactus:

 /heads isn't a command in this plugin, it's /playerheads or /ph.

However, that appears to be an oversight from before I joined - players can access the /ph command without permission, but not actually use any part of it.

So, while this is a cosmetic issue rather than a security issue, I've created a development build that should fix this:

https://ci.meme.tips/job/PlayerHeads-5.x/1126/
DISCLAIMER: This build has not been tested or approved by Bukkitdev staff. Use it at your own risk.

The development build adds a 'playerheads.command' permission that's required to use /ph at all, but ops or users with the star/wildcard permission receive it by default.  Again, users could not access any subcommand of it previously, only see that they exist.

Note: this build includes potential changes for the next version of PH as well.

In reply to RealMartinovitz:

If you changed the config file directly, you will need to use the /ph config reload command to ensure the server can see your changes - otherwise the config file is overwritten when the server shuts down (in order to save your ingame changes).

Instead, you can use the /ph config set  ???droprate 1.0 commands to change the settings without needing to reload - which are automatically saved to the config file on shutdown.

If heads still do not drop, please ensure that players have the playerheads.canbehead and playerheads.canbeheadmob permissions allowed.  A permissions plugin like Luckperms will make this easier to accomplish.

Alternatively, you can set playerheads.alwaysbehead and playerheads.alwaysbeheadmob permissions on players - this will ensure their drop rolls are always successful (when they're eligible by other settings).

In reply to GlaZeMaTriiKz:

 I can't reproduce this on my server or test servers.

PlayerHeads also doesn't check/modify any armor stand events, so this is probably due to a different plugin your server uses. Any armor stand interaction should be vanilla behavior.

I would look at which other plugins you use that deal with area protection, inventory protection, and heads/custom items.