Bukkit

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.

In reply to robyn348:

 Yes, it's a little bit of effort but if you change all of the mob rates to -1  (or set them to 0 and set the appropriate "behavior" settings to vanilla) then only vanilla heads should drop.

Then you can of course set 'droprate' (which is the setting for players) to the amount you want.

Remember if you change the config file directly, you must do /ph config reload, otherwise, change settings with /ph config set settingnamehere valuehere

In reply to mijkolsmith:

 Yes, heads are automatically updated when dropped or broken.

you can disable this behavior by setting both fixdroppedheads and fixbrokenheads configurations to false.  (if you change the file, do /ph config reload afterwards - otherwise, use the /ph config set ... commands)

However, when you do this, you will encounter the problem that vanilla minecraft strips meta (name, lore, enchants) when a head is placed and broken or broken by a piston.

The other reason for these setting was to allow heads to be traded with other plugins (eg: Shopkeepers) - changes in these details tends to break trades.

In reply to mijkolsmith:

 Strangely no,  the Profile (Username, UUID, Texture) fields are the only thing minecraft doesn't clear when you place a head.  So usually it keeps the texture (and internally the ID/Username), just none of the styling, item displayname, or anything else

So, it's possible for a plugin to determine the owner of a head after placing (which is done here when using ''clickinfo' by displaying the name or when 'fixing' it by re-creating the head with the name and styling) and it still appears with the texture - but other information is lost.

if your heads turn into Steve, then there's another issue (offline-mode, or mojang-api being inaccessible).

Aside: it might be technically possible on newer spigot servers to store the meta in the block using the new PDH API but the three issues with this approach is it would become version-dependent,  the amount of data being saved in blocks would get big very quickly, and serialization is not guaranteed to be "stable" (as in it can produce results that don't identically match the original in tag order or internal formatting).

In reply to graymold9:

 how are you changing the setting? with the config command (/ph config set cowdroprate 1.0) or editing the file?

if you are editing the file directly, did you use the /ph config reload command to load the new settings after saving the file?

if you've changed the rates ingame or used the config reload command then a rate of 1 should always drop a head (assuming nothing weird like negative lootingrate) if you have the playerheads.canbehead/canbeheadmob permission and other self-imposed restrictions (pkonly/mobpkonly, requireitem).

If you still can't get a head to drop then it may be more likely another plugin (like arena, keepinv, or protection plugins) is cancelling the successful drops, in which case youu may need to change the antideathchest setting.

EDIT: does a lower level of looting work? I'm not sure if 30,000 is valid.

Thanks