DeathCraft 2
DeathCraft
DeathCraft is a plugin to make dying fun!
Not really. Dying always sucks - But DeathCraft will make it more fun for everyone else.
Features
- Unlimited, customized death messages for every type of death, or per item!
- Differentiates between PVE and PVP deaths!
- Option to use true account names, or display names (/nick, etc)
- Player optional ignoring of either type of death (PVE or PVP) messages
- Head drops! Fully configurable drops of player and mob heads!
- Permission based configurable 'Death Chests' that will store items upon an untimely demise - or be the prize of the PVP victor!
- /kill and /suicide, as well as the option to override these commands from other plugins to continue the DC Experience
- Permission based configurable 'Keep Xp on death
Installation
- 1) Download
- 2) Put deathcraft.jar in your /plugins folder
- 3) /reload your server, or restart.
- 4) ???
- 5) DEATH!
Known Conflicts
- CreeperHeal You must disable chests in one of the two plugins, or you will end with a looping chest creation.
Commands, Configuration & Permissions
Please see the new Commands, Configuration & Permissions Page!
Bug Reporting and Suggestions
If you find a bug, or have a suggestion, PLEASE open a ticket! I can't fix what I don't know is broken, and I can't add what I don't know is wanted. :)
ToDo
- Togglable allowance of locked chests for popular protection plugins (LWC, Locket)
- Allow Keep item on death permissions, completely bypassing Chests
Tutorials
Portuguese:
This plugin appears to have problems with some protected region plugins. I'm using Grief Prevention and when a player dies inside his own claim with chests in his inventory they don't get placed and items are not stored. With debug on deathcraft sais "cannot build here."
I'm assuming deathcraft is using a pseudo-player to place blocks, which of course griefprevention wont allow. GP has an option to whitelist such psuedoplayers, but i need to know what the pseudoplayer is named. And that means asking you (unless I try to look through the JAR myself).
EDIT: Nope. Broke down and decompiled your jar. Don't know enough java to read it fluently but I'm pretty sure you're grabbing the player entity from the player death event and then testing if that player can successfully place a block. So I'm confused (again, not skilled with java) why the plugin concludes the player doesn't have permission to build where he was. I was watching him build while I was reading over the logs.
Update side note:
Since the chest dropping tends to cause issues here and there, I'm rewriting how the death chest portion of the plugin works.. I'm moving it to a Gravestone style system, where you can have a sign, or a head (configurable) - breaking the gravestone will drop the items, rather than it being a random chest laying out in the middle of nowhere.
Everything else will pretty much work the same with the deathchest system. Will also make it so that (of course, configurable also) the player head can drop when you break them, and some other new, nifty stuff.
I may or may not leave the chest option in as a configuration option ... it just causes a lot of issues.
@raum
Oddly enough, it's working perfectly... Sorry for the trouble. The next time the issue appears, I'll report the information.
@Liger_XT5
Are you still on 1.8, or have you swapped to 1.9?
Also, download v1.12a - it's got some extra debug messages in it. In game (or console) type "/dc2 set debug true" and break one of the Slimefun heads - You should receive a debug message that it IS a CSCore head and that it has been ignored - If you ARE receiving this message, then it's not Deathcraft causing the issue directly, but dc2 conflicting with something else you have: I just tested it on a fresh server with nothing but Slimefun, ExoticGardens and Deathcraft, and it's working like it should (SF heads dropping from SF items, not CSCoreLib heads)
@raum
Recently tested on an orange tree just outside of my spawn building.
Tested it without deathcraft, got an orange. Tested after loading deathcraft, got a CS-CoreLib head. Unloaded deathcraft, orange.
@Liger_XT5
When you type /dc2, what version does it say up top? I'm currently using Slimefun with ExoticPlants and it's working perfectly fine and correct.
When you type /SF, what version are you using of that?
What exact SF addons are you using? What exact SF heads aren't working as intended?
Tried it, still having the same issue. From the looks of it, it only affects the breaking of the slimefun heads. Once I used /plugman unload deathcraft, everything was back to normal again.
@Liger_XT5
Update to fix (maybe?) Slimefun conflicts was just uploaded. I don't use slimefun myself, so not certain it worked - please let me know.
@Liger_XT5
In config.yml, there should be an option under under 'heads' section that you cna set 'enabled' to false. You can also just set the player,or whichever mobs, head drop percent down to 0.
@raum
Out of curiosity, is there a way to disable the head functions of deathcraft? The decoration additions are nice, and so is the beheading, however I've got about two other ways for players to behead another player or mod, and the decoration blocks can be easily setup through command blocks.
@Liger_XT5
1.9 itself doesn't effect Deathcraft at all - No update is currently needed for it to run on 1.9.
As for Slimefun - I've only glossed over this plugin, and never used it in production, so never noticed anything odd with DC2. I'll have to take a look at how they're dealing with heads and adjust things accordingly - hopefully it's open source. Worst case scenario, we can just make Deathcraft completely ignore any head owned by 'CS-CoreLib'.
Update for MC 1.9?
I've found a new conflict when using Deathcraft with Slimefun (mostly it's side plugins ExoticGardens and LuckyBlocks).
The head blocks of Slimefun all break into one name, CS-CoreLib, when DeathCraft is installed when the chunk with the item is generated. When DeathCraft is not installed, the block heads drop the appropriate item(s).
@xH3LLRAIZ3Rx
I'll look into it. Been rather sick IRL recently, and haven't had much chance to do much of anything. I see he's got his source available, so it shouldn't be too difficult.
can you add support for http://dev.bukkit.org/bukkit-plugins/zenchantments/ Bind Enchant where if the item is Binded, it doesnt go into the death chest
@raum
PM~
When copying over your messages.yml to mine, I do not encounter the reset issue you're describing. When I edit the file, then start up, it is fine. If I edit it, and use /dc2 reload, it is also fine. Is it still occurring? The only thing I can think of is that originally there was an issue with your file, and when you re-did it, the mistake didn't exist.
I had misunderstood your initial comment regarding the custom item message - that can safely be ignored. In short, it's not finding item 276 in your file, so it's defaulting - or supposed to be - to pvp. Apparently it is not doing that - it is defaulting to entity_attack instead.
Is there any particular reason you're not using the in-game config editor? It would both save the need for a reload, and should write the config file without issue.
If you're still having issues, go ahead and PM me so we can try to get it taken care of quicker, and without spamming the comments.
@raum
As i stated in my prevous post, i haven't added any other items to CustomList, just my added variations for the bedrock item:
The resetting (actually it isn't resetting everything; read above, so i'm not sure how to call this) only seems to happen when adding messages to non-CustomList related sections. I tried adding an almost identical message under wither: (only omitting the period):
But after saving the file and doing /dc reload, that message was removed
(i used WinMerge and Notepad++ to add my messages, but they are still removed)
Here's the messages.yml i currently have:
@ThisUsernameIsMine
Hm .. Messages shouldn't reset for any reason, unless it's finding an invalid line (yaml limitations). Do you/did you have a custom item message for item #276?
I haven't run into this issue at all. Do you have a copy of your non-reset messages.yml so I can test and debug with your settings?
Aww, the new version is resetting my messages back to the default one.
It even happens after adding a colour code to one of the default messages (of course between the quotes and when server was off).
http://www.yamllint.com/ shows Valid YAML
Debug shows nothing odd at server startup, but note when killing someone:
Interesting to mention is that there is no such entity_attack in my standard generated messages.yml (and yes, i'm really using the latest version of DeathCraft).
also isn't mentioned under CustomItem, i only see '7' and a message.
Furthermore i often see the following debug output in the console:
This amazes me, because in my config i haz:
And remember, this all happens with the default messages.yml, the complete config.yml i have is below:
Perhaps the plugin is not ready yet for Spigot 1.8.3?
With name changes going live last month, some of the Decoration heads are no longer valid. I have not gone through them and updated it for 1.10.2. Deco heads can be manually edited/enabled/disabled in the config file. If you see one you dont' like, or that is no longer valid, you're able to remove it on your own.