DropHeads
DropHeads
Let the head-hunt begin!
Using quality heads 99% supplied by Minecraft-Heads.com & Nano Team â¤ī¸
Key Features
- Very configurable!
- Get heads as a death drop, or with a command
- MASSIVE variety (e.g., snow fox, lime sheep, grumm swamp farmer villager, …)
- Custom behead messages and translation support
- Regularly updated heads from the latest Minecraft snapshots
Configuration (Sample)
Default values designed to fit well on most servers,
However, if you like digging into configuration, here's just a taste of what you can do:
- Adjust drop rates based on mob type
- Adjust drop rates based on spawn conditions (eg: Breeding, MobSpawners, /summon, ...)
- Adjust drop rates based on ticks-lived
- Adjust drop rates based on what weapon is used
- Require using specific weapon(s) to get heads to drop
- Support charged creeper head drops
- Limit head drops when not killed by a player (configure what counts as 'killed by a player')
- Change any head textures (or add your own!)
- Set up automatic updates
- ...and more! Check out config files in the source repository
Permissions
For a complete & always updated list, check here.
dropheads.canlosehead: Can drop a head upon death
dropheads.canbehead.<mob_type>: Can get heads from killing the given mob
dropheads.alwaysbehead.<mob_type>: Get heads for 100% of kills (unless canlosehead is false)
dropheads.silentbehead: Avoid triggering a global behead message in chat *
dropheads.canplacehead: Can place a head as a block
dropheads.clickinfo: Can see the name of a head by clicking it *
dropheads.spawn: Can get heads with a command *
dropheads.droprate: Can check head drop rates with a command
* = has sub-permissions
F.A.Q.
Q: Heads are not dropping for me!
A: There a several possible causes; please go over this checklist before leaving a comment:
* Check if another plugin is blocking or modifying the death-event item drops
* Check if you have the dropheads.canbehead permission
* Check head-drop-rates and spawn-cause-modifiers (spawn egg drop rates are nerfed by default!)
* Keep in mind the time-alive, weapon-used, and looting modifiers.
* If killing a player, check if they have the dropheads.canlosehead permission
* If you have modified your config files, check them carefully for other causes
Q: Does this plugin ever cause lag?
A: Nope! I heard it is much faster than Xisumavoid's datapack :)
Q: Can I edit the head textures (i.e., to match a resource pack)?
A: Yes! Look in the head-textures.txt file
Q: Migrating from another heads plugin?
A: It should be an easy drag-n-drop replacement, but if you have any issues let me know!
Q: How do I install for singleplayer or a pure vanilla server?
A: DropHeads is built for Bukkit and its forks (Spigot, etc); perhaps try MMH-Nano instead
Q: Where do I get help / report a bug?
A: You can either post a comment below or create a bug report, I will see it either way :)
Q: What about older versions of Minecraft?
A: Currently, DropHeads only supports 1.13+. You can find older DropHead jars that work for 1.12 in the Files tab, or use a different plugin that has support for legacy versions, such as PlayerHeads.
Planned Features
- /give @p dropheads:vex - please upvote here đ
- Fabric mod
- Add/improve heads for these mobs:
- "Giant's Toe"?
- Tropical Fish (have the 22 common ones, but need the 3104 other varieties âšī¸)
- Carpeted llamas
- Horse variants (have for colors, but not for patterns)
Feel free to reach out if you find any bugs or a texture for a missing head!
A player reports to me that he uses a nametag(Grumm) to name a tropical fish.
When he kills the fish, the fish drops a normal tropical fish head, not normal grumm tropical fish head.
I have tested and confirm this issue.
Step:
1. use command "/summon minecraft:tropical_fish ~ ~ ~ {Variant:16778496}"
2. name the tropical fish to be Grumm
3. kill the named tropical fish
4. drops a normal tropical fish head, not normal grumm tropical fish head
Hello! First I just want to thank you for all the work you've put into this plugin, it's much appreciated.
I was just wondering how one would make it so alternate states of heads (e.g. Armored Wither, Invulnerable Wither, Armored Invulnerable Wither, etc.) also have a chance of dropping from the specific mob. Is it as simple as adding, for example, WITHER|ARMORED, into head-drop-rates.txt, or is there some simpler way of enabling this, or is this just not possible at this current moment in time?
Also, is it possible to enable the custom Dragon Head to spawn when the Dragon is beheaded while not messing with Vanilla Wither Skeleton skulls?
Thank you for your time.
In reply to xmjgold:
Unfortunately there isn't a way to get the Armored Wither head at the moment, I was trying to think of a creative way to determine which of the two is dropped --- so with the Ghast, it has two heads based on whether its mouth is open or not when you kill it; similar with Vex, since their face changes when they go into a charge-attack animation, but for wither it always enters armored state when low health, so if I just use "wither.isArmored()" to control which head it drops, then the regular head would be unobtainable, and I haven't brainstormed a satisfying enough alternative way to get it (open to ideas of course).
Your other question confuses me a bit; I think the default drop rates already have 5% chance to drop a dragon head when it is killed, but this can be turned off (or turned up), and it is completely separate from wither skeletons. Not sure if that is what you were asking for, but can follow up if needed :)
In reply to EvModder:
Hey, thanks for the response!
In regards to ideas for obtaining Wither Skull variants, the only thing that comes to mind is a way to make it so, upon being beheaded, the Wither would have a percent chance to drop any one of the four variants. It's definitely not a perfect solution, but it is some way to make all four variants obtainable.
About my second question, it was a bit unclear so I'll try to remedy that lol. My question pertains to "prefer-vanilla-heads" within the config.
The question I was attempting to ask was if "prefer-vanilla-heads:" was set to false, which would then have the Ender Dragon drop the custom head within the plugin (like the one found within head-textures.txt), would that then make it so Wither Skeleton Skulls now drop a Player Head designed to look like a Wither Skeleton skull (much like how it does with Zombies, Skeletons, etc.) or if Wither Skeleton skulls would still drop as vanilla skulls, hence not messing with players being able to spawn withers, if "vanilla-wither-skeleton-skulls:" were to be set to true within the config.
If the question is still too confusing I completely understand and apologize lol. Anyways, thank you for your time. :)
In reply to xmjgold:
No worries and thanks for the clarification! I checked the code, and unfortunately "prefer-vanilla-heads: false" will break wither skeleton skulls, even with "vanilla-wither-skeleton-skulls: true".
Edit: Actually, I'm not sure which it drops, now I'm thinking it should drop the vanilla skull item, but not sure without directly testing it.
In general, perhaps it's time for me to design a more flexible config option for these :)
Is it possible to prevent player from enchanting the heads?
Because some players echant the heads but I do not want them to enchant.
In reply to siulung201314:
Sorry to make a reply under my question but I am afraid you haven't noticed my message.
A player reports to me that he can duplicate the head using a bug related to enchantment.
Therefore, I want to not allow player to enchant the heads or there are any other ways to fix the bug.
im having an issue when editing the drop rates for wither skeletons, it provides me this error and i cant seem to find out how to disable it.
vanilla wither_skeleton handling is enabled.
In reply to TapToSearch:
Ah, that'd be coming from this line in the config.yml
Once you set it to false, you should be able to edit the rates for it however you like
In reply to EvModder:
In reply to EvModder:
Thanks, just curious, is there any way to change the skulls that drop when using the plugin as i have another plugin installed that requires vanilla wither skulls to be able to craft x item, when i try it with the custom drop skull it dosent work as it has a different lore/id to the vanilla skulls.
In reply to TapToSearch:
Hmm, not sure, I'm surprised it doesn't work, I'll have to take a look at it in a week when I'm back home from travel, in the meantime LMK what the other plugin is and I'll see if I can figure it out. If you're able to get it to work on your own, just let me know what you did so that other people in the future can reference it if they get the same issue.
Hello!
I downloaded the plugin for my server, but for some reason heads drop 100% of the time once I set the canlosehead and canbehead permissions to true. When i do canalwaysbehead, i get the 100% drop rates and when I set it to false What permissions/config settings should I change and to what to get more normal droprates? I've already tried changing weapon and looting values, but to no avail. Thanks!
In reply to fintastica:
There are a few things to check:
1) if you use the JPerms permission plugin, it tends to screw up default settings for server ops (giving you dropheads.alwaysbehead even though it is false. Note it also has sub-perms such as dropheads.alwaysbehead.zombie)
2) be aware that the drop chances in head-drop-rates.txt are from 0.0 - 1.0, not 1 - 100, so avoid setting them higher than 1.
3) When in doubt, the usual best way to debug is to point the cursor at a mob, and before you kill it run /droprate, it will spit out a bunch of useful info that explains pretty much everything affecting the final drop %. It might be helpful to also test with op & non-op player accounts to see if there is a difference, to eliminate the possibility of a "give all ops *, *.*, *.*.*..."-type permission plugin
In reply to EvModder:
Thanks for the help- the droprates are back to normal (supposedly). Though while doublechecking everything was working I noticed that the old problem of nothing dropping at all is back. According to the message I get when runnign /droprate on anything, I get a "you need the canbehead perm" even though I have set it to every single group (I have alwaysbehead on false and canlosehead on true as well.) Our server uses essnetialsX and LuckPerms, do those affect anything?
In reply to fintastica:
Very odd that issue is popping up, I've never had issues reported for either of those plugins and they are pretty well tested, but if you figure it out please let me know (it might be helpful for others as well). I guess I'd recommend using LuckPerms command `/lp user <Name> permission check dropheads.canbehead` (and also for mob sub-perms to verify it is set up properly (I got the command format from the LuckPerms wiki so I assume that's how it's done)
Hey, can I somehow make different custom heads drop from the same mob?
In reply to muurkkk:
Unfortunately this is not currently a feature (except for different mob sub-types, like Red Sheep, Blue Sheep), but it is very easy to add and doesn't complicate anything else, so I might include it in v3.7.10 or as an extra addon :)
The way I plan to set it up, you will go to head-textures.txt and just have the same "key" repeated with multiple texture values, for example:
COW: 7df4f2e7846000b6e7548f86937d3f6af847b1607668ee05e7caf9f6f04c9423
will have a 50/50% chance of dropping either head when a cow is killed.
Hey man. Everything works just fine, but when I destroy a head that's been placed the name will be changed to "dropheads:COW's Head" which is not desired. What can I do?
All I want in the world right now is for the names to always be like when dropped at first ("Cow Head")
Also ditto on the reload config option being nice :)
In reply to MainBaze:
Huh, that is very strange, can you confirm what version of the plugin you are using and DM me your config? (or link it in a comment).
I've never heard anyone else report this issue so there is also a chance it's caused by a conflict of DropHeads with another plugin, in which case if you know of any plugins you use that affect heads DM me that as well so I can try to recreate the issue :)
In reply to MainBaze:
Actually, I should probably explain why I haven't gotten around to a reload config command yet, since it is fairly easy to do; the thing is I just can't decide what the command name should be; the obvious one is just `/dropheads reload`, but then what does just `/dropheads` do? are there other sub-commands? Alternatives like `/dhreload`, which I've seen other plugins do something similar, look kind of ugly or verbose. My favorite would be `/dropheads:reload`, a namespaced command, but then it might conflict with the vanilla `/reload` command. All of this is just minor implementation detail but I get wrapped up in perfection and end up not choosing any due to nitpick dissatisfaction.
The best current alternative to a reload command is if you have any plugin manager that lets you disable/enable plugins, e.g., with `/dp DropHeads` then `/ep DropHeads`, then that will work. I've even seem some that have `/reload <pluginName>` as a command... But I understand that not everyone wants to bother with installing a plugin that's only purpose is calling <otherPlugin>.enable() or .disable() in the server API.
Some permissions plugins or "Essentials" type plugins also offer similar commands, but in all honestly I think Bukkit/Spigot/Paper etc should just expose this API as a command themselves since IMO it is basic useful functionality, and then no plugin author would need to implement a reload command themselves.
(actually, now that I think I might go open it as a feature request on spigot Jira and see what they say lol. Once again, I could easily add the command myself, i'm just being lazy/nitpicky and trying to get to a solution that is more elegant imo)