Bukkit

In reply to 1212march:

 Ops and players with the playerheads.* permission have playerheads.alwaysbehead and playerheads.alwaysbeheadmob by default regular players will not.  If you must have Op and normal drops for ops, then you will need to negate those permissions (see FAQ Entry #9 ).

In reply to vict0rylive:

 each looting level would add 10% of the base droprate for that entity, not a flat 10% chance added.

the looting modification looks like this on a head roll:

newDropRate = oldDropRate * (1 + lootingrate * lootinglevel)

that is, the current droprate is added to the fractional-increase of the droprate. (so that the change to droprate is always proportional to the original droprate.)

In reply to vict0rylive:

 There is no setting mobdroprate. there is a setting for each individual mob.  If you want to set all mobs easier, look at a few comments down where I supplied a sample config that can easily have 0.02 replaced with the desired rate (and do ph config reload after you save the config.yml) although you will need to add beedroprate.

Regarding the second question, you can change the setting addlore to false, but keep in mind heads with/without the loretext will not stack or be compatible in villager trades. (although dropping the head or placing/breaking it may update it to the desired appearance depending on your settings).

In reply to FireHiveRS:

 if you use the newer versions, you can set all mobs droprates (and the player "droprate" if you want) to -1 and set the "behavior" settings to either vanilla or ignore.   this will prevent PlayerHeads from adding any drops and force vanilla behavior.

Alternatively, you could instead deny (negate) the permission playerheads.canbehead and playerheads.canbeheadmob for players which disallows them from getting PlayerHeads beheading.

---

context:

in versions 5.1 and higher, a negative droprate forces PlayerHeads to stop processing the death event without further consideration or cancelling.  Before 5.1 (since version 3.12), this only applied to witherskeletondroprate.

witherskeletonbehavior and chargedcreeperbehavior are overriding behavior settings (the default ignore setting deactivates them, vanilla forces processing to stop early). So ignore with a droprate of -1 should be the same as vanilla.

changing all the droprates to 0 except the vanilla mobs that drop heads (with those as behavior:ignore and _droprate:0 or -1, or behavior:vanilla) should function the same, but is not as future-proof in case a new server version adds old heads (albeit unlikely).

---

if you want to maintain vanilla heads you might want to read about a couple other configuration options to decide if you want to disable them - like convertvanillaheads and fixdroppedheads.

Let me know if you have any problems.

In reply to Jmcbaa:

you're looking for the configuration setting called droprate. For backwards-compatibility reasons, the name of this setting wasn't changed to playerdroprate since that would break existing configurations from version 3.

So if you want player's heads to drop with a 1% chance, you would do:

/ph config set droprate 0.01

 All of the configuration options and descriptions can be found at this link.

In reply to in__c:

 Not at this time, but I've pasted what should be a list of all 1.14 mob droprate configs (for plugins/PlayerHeads/config.yml) with all of them set to 0.02:  https://pastebin.com/rEt6y6xT

If you use this, you should be able to use your text editor to find-and-replace 0.02 with the desired droprate.

 (other normal settings are not present in this paste, and it doesn't contain the normally unsupported entities - armorstand and giant)

In reply to NoChanceSD:

 4.10.0 is the last version to support detection of older v3 mobheads.

If you attempt to use v5, any usernamed-based mob heads (v3 mobheads) that haven't been converted into v4 heads yet (by placing/breaking/dropping them) will be considered to be player head drops instead of mob heads.  Heads that have been converted to v4 can be thought of as being 'set' / future-detectable.

You will be able to tell if a head is converted to v4 if you see loretext (PlayerHeads/Mob/Player-Drop) on the hover description, since that is a newer feature. (if lore is enabled)

The unconverted heads should appear with the texture associated with the username (as in v3), but if they are detected by v5, the name and lore will appear as "______'s Head / Player Drop". 

Note: the texture of v3 heads is from the user profile of the associated username - if the user updated their skin, the texture may break even on v3 - this is why they were phased out. v4 heads have an embedded texture-url and UUID that is more detectable and less likely to change, and there's no ambiguity between a user and mobhead.

Without writing some sort of full world-processing utility, automatic conversion of all v3 heads to v4 heads is not possible, only manual conversion is.

If this behavior is not acceptable and it's not feasible to update the heads manually in v4, I would recommend staying on v4.10.0 - otherwise, you can update to v5 if you don't care about the name/lore.

TL;DR - For clarity's sake: the head standard adopted in v4 was to convert v3 username-based mobheads into v4 uuid+texture mobheads.  v5 just does not convert these anymore and so they are considered to be the heads of players. Texturing of player's heads is based on their profile and caching outside of the plugin.

In reply to gekitotsu:

 The issue tracker is the proper way to submit an issue, I've replied to your issue asking for some information, and I will attempt to advise there when I can.

In reply to pixelcraftian:

•  Do you have other plugins that could prevent items from being dropped?
•  If so, have you tried setting antideathchest to true (from the FAQ) by either using the command or reloading the changed config?
• If not, do you have droprates, pkonly/mobpkonly configured in a way where you can get heads?
• Do you have the permissions needed to get heads playerheads.canbehead and playerheads.canbeheadmob ?