Bukkit

The main configuration is located at plugins/DeathControl/config.yml.

Here is the default one that is generated when you first install the plugin:

# ====== Settings for DeathControl ======
# IMPORTANT: Do NOT use tabs in this file! Only use spaces!
# 
# Documentation on how to set up this configuration can be found here:
# http://dev.bukkit.org/bukkit-plugins/deathcontrol/pages/configuration/


disable-permissions: false
logging-level: standard

multi-world:
    allow-cross-world: true
    disabled-worlds: []

handlings:
    # These are some handlings for demonstration purposes.
    # Adjust them for your own needs.
    demo:
        priority-order: 1
        timeout-on-disconnect: 15
        conditions:
        - cause fall suicide
        - food-level > 0
        actions:
        - keep-items
        - keep-experience
        - message %plugin-prefix%You're &e%victim-name% &rand %death-cause-formatted%.
        - message %plugin-prefix%&lThis is an example message
        - message %plugin-prefix%&lwhich is adjustable in the config.
    demo-with-price:
        priority-order: 1
        cancel-message: &cYou don't have enough money!
        conditions:
        - killer-type zombie
        actions:
        - required charge 100
        - keep-items !armor
    demo-with-command:
        priority-order: 2
        timeout-on-disconnect: -1
        cancel-message: |
            %plugin-prefix%You took too long!
            %plugin-prefix%Your items were dropped!
        conditions:
        - killer-type monster
        - -permission victim someplugin.testpermission
        actions:
        - message %plugin-prefix%Use &9/death back &rto get back your inventory.
        - wait command 30s
        - keep-items 75%
        - keep-experience 75%

disable-permissions

This setting specifies wether this plugin should use the standard bukkit permission system. If you set this to true, the plugin will use the OP system instead (see the Permissions page on how that is handled). This should always be false unless you don't want to use permission nodes at all.

logging-level

This determines how fine the logging to the console will be. The only valid options are:

• errors - no regular logs at all; only severe errors are shown
• warnings - no regular logs at all; only severe errors and warnings are shown
• standard - a short notification in the console when a death is handled; this is the recommended setting when the plugin runs normally
• detailed - a little more information when players die about the plugin's reaction; recommended when you investigate and try out features
• debug - very verbose information when players die; expect a lot of spam in the console; can be helpful when you don't understand what exactly a handling is doing or when creating a bug report

multi-world

This handles global settings concerning multi-world functionality. See below for more explanation.

handlings

This block specifies all the handlings that should be executed on a player death. See below for more explanation. The values of the default file are only for demonstration and should be altered to fit your needs.

Messages that are sent to the player can be modified and disabled in a separate file.
This is explained on the messages.yml page.

The plugin is capable of two global restrictions regarding multiple worlds. You can disable that actions are executed in a different world than the one the player died in (allow-cross-world).
And you can specify a list of worlds that you want to completely exclude from being processed (disabled-worlds).

allow-cross-world

When set to true (default), actions are always executed, no matter which world player death and respawn happened.
When set to false, actions will not be executed if the player isn't currently in the same world as when they died. That way, if people have separate inventories in different worlds, they can't get mixed up.

This restriction can be bypassed with the permission node "deathcontrol.crossworld".

disabled-worlds

This option lets you specify a list of worlds which the plugin's functionality should be excluded. If you leave this empty, it will work in all worlds.

Note that this only affects the world where the player died in, not where he respawned. That means when you leave allow-cross-world set to true and Player dies in world A (which is not blacklisted), but respawns in world B (which is blacklisted), everything will continue as normal. If you don't want that, make sure you set allow-cross-world to false.

Important: Make sure this is an actual list as YAML understands it. Even when you only have one entry, you must set brackets or a '-' sign!

This restriction can be bypassed with the permission node "deathcontrol.nolimits".

Handlings are the key-part of the plugin. They specify what actually happens on a player death. You can define an arbitrary amount of them with a custom name.
Most importantly, each handling has "conditions" that have to be met for the handling to execute and "actions" that define what will be executed.

    (handling-name):
        priority-order: ...
        allow-others: ...
        timeout-on-disconnect: ...
        cancel-message: ...
        cancel-message:
        conditions:
        - ...
        - ...
        actions:
        - ...
        - ...

If any option is left out, the default value will be used.
These are the available options:

Conditions are checked for each handling when a player dies. If all conditions of a handling are met, the handling will be executed for the death, which means the specified actions are applied.

Conditions usually require arguments. These work like arguments for Minecraft commands and are separated with a space.

        conditions:
        - condition-name arg1 arg2 ...
        - condition-name arg1 arg2 ...

A list of all conditions is available on the Conditions page.

Actions define what actually happens after the death. They are only executed when all of the conditions matched.

Actions usually require arguments. These work like arguments for Minecraft commands and are separated with a space.

An action has an outcome, which means it can SUCCEED, FAIL or DELAY the execution of the actions after it.

If an action fails, it doesn't change anything by default. To make the action chain stop after an action failed, you have to write the "required" keyword in front of the action-name.

Example:

        # Items won't be kept when the cost couldn't be payed.
        actions:
        - required charge 100
        - keep-items

Some actions modify items and thus affect how other actions work. That makes the order of actions especially important in some cases.
For example, "destroy-item(s)" should be used before a "keep-items" action, because keeping the items means removing them from the dropped items and "destroy-items" modifies the dropped items.

A list of all actions is available on the Actions page.

Variables can be used in some actions to allow place-holders. They will be replaced when the action is executed.

Some variables are always set from the beginning, while others will only be available after their respective action was invoked.

A list of all variables is available on the Variables page.