Bukkit

In reply to sprucestudios:

Sorry for my slow response I was out for a few days. Perhaps it would be possible to keep both if you create a folder named "EvFolder" and move the config files from both plugins into it, because that's what the old code is trying to do.

Alternatively, I would recommend trying this updated (beta) version of ChatManager:
https://github.com/EvModder/ChatManager/releases/tag/v2.1.1
Although if you update, I strongly suggest deleting the old chat manager config.yml and let it generate the new one, since a lot has changed in the v2.0 and I haven't done much backwards compatibility work yet

In reply to artaria500:

<server>/plugins/DropHeads/head-drop-rates.txt

In reply to VolubalOffi:

To be honest, this had been in my TODO bucket plans for a long time, mainly I was just waiting for someone who needed it enough to ask I guess :)

You can reload DropHeads with a server /reload or a plugin manager plugin to let you disable and re-enable it, but I agree having a built in reload command could be nice, although it would just be for configs.

As for configuring droprates with a command, the reason I have been putting it off is I was worried about having to load & save the drop-rate.txt file each time the command gets run, and preserve any local changes and comments, but it wouldn't be that hard (I've done it for other plugins before)

In reply to ndturtle_:

You will need to add them manually I'm afraid; the updated file for reference is here; you can also get it by renaming/moving your drop rates file to a backup and letting the plugin regenerate it, then re-applying your custom drop rate settings. If you do nothing, it will use the "Default" drop rate from the file which is 0 I think (although you can edit that as well).
I recommend tools such as https://www.diffchecker.com/
BTW, if you use spigot/paper/purpur config files, it's good to regularly do something similar with those as well since they occasionally add new settings but you won't see them without regenerating files (it's a common problem with configs in general, unless the config stores a "config version number" and has special code for detecting it)

In reply to JoshViz101Gaming:

It depends on what permission plugin you have installed (with no permission plugin, or with a good one, it won't be added in the first place)

Most of them have some config file where you can do <permission>=false for certain players or "groups"

In reply to lobsterdog53:

Hmm, both of those things sound like issues but I've gotten it to work with other permissions plugins so I think it's a LuckPerm specific thing (might be worth checking with them).

- According to DropHead's plugin.yml file, nobody should have alwaysbehead perm by default, not even ops, so this issue you get is probably LuckPerms just deciding to ignore what plugin authors say and just giving OPs all permissions that exist (I've heard other people report this as well).
- *=true, dropheads.alwaysbehead=false in your second issue should still allow beheads, so that indeed sounds like an issue. Once again it's probably a permission plugin related thing, but you can always double-check it by looking at a mob and doing /droprate (it's a helpful debug command that will tell you everything impacting the drop chance)

In reply to pl1nkoriot:

Hmm, if you mean what the "spawn reason" for the warden is (from spawn-cause-modifiers.txt), I'm actually not sure since I haven't tested it yet personally. It will be one of these though.

Edit: I checked, and it seems the SpawnReason that Bukkit/Spigot assigns is "DEFAULT"

In reply to dingoo900:

Look for the setting named 'specific-tool-modifiers' in the config.yml (or 'specific-tool-multipliers' in DropHeads v3.7.6) and set it to this:

that will result in the drop chance (which is a number between 0 and 1) getting multiplied by a very large number which will make it happen basically 100% of the time.
if you want you can list various different items (e.g., shears, or AIR for bare hand) with numbers to increase the chance by

In reply to lokyycs:

Hmm, it could be a bug or something unique with configuration, if you don't mind DMing me your config files I can take a look and see what's up.

Another possibility is if he killed a tamed pet of yours (tamed wolf or cat), because those will always show death message to owner regardless of distance, but it doesn't sound like that is the problem