These are general plugin options that don't fit into the other categories.
|core.storage||Backend storage system to use. |
EBEANS - Ebeans storage (will go to SQLite or MySQL as specified in your bukkit.yml)
YAML - YAML storage in your plugins/HomeSpawnPlus directory. Will store one file per data type (home, spawn, etc)
YAML_SINGLE_FILE - YAML storage in your plugins/HomeSpawnPlus directory. Stores all data in single "data.yml" file
|core.defaultPermissions||This is used in the event that no permission plugin is found and superperms is not in use. You can use this to assign "default" permissions that will apply to anyone who logs in. For example, the below would allow "/home" and "/spawn" for everyone: |
|core.bedsethome||Set to true to allow players to set their home by clicking on beds. Note they must also have the hsp.home.bedsethome permission||true|
|core.defaultWorld||Defines the "default" world, used in several strategies as the "main" world in the event no strategies match for the local world the player is on||world|
|core.override_world||Tells HSP that when "/setspawn" is used, it should also commit that location to the Bukkit map. This has the effect that if you ever remove HSP later, the spawn point you set in each world will stay to what you set it to.||true|
|core.recordLastLogout||If set to true, HSP will keep track of the exact spot the player logs out. HSP will also send the player to this point when they log back in if it hits the "default" strategy in onJoin event, instead of letting Bukkit do it. This is to work around a bug in Bukkit that sometimes spawns people in walls or lava, near where they last logged out||false|
|core.lastHomeIsDefault||HSP can allow players to define multiple homes and switch their default home among them with the /setdefaulthome command. In the event that the player has deleted their defaulthome but does have a last remaining home on that world, if this flag is true that last home will be counted as the default home.||true|
|core.locale||Change the locale for localized language messages. Valid locale choices: en (English)||en|
|core.defaultMessageColor||The default color for all HSP messages||%yellow%|
|core.reloadChunkOnTeleport||When true, HSP will force Bukkit to reload/resend the chunk on player teleport. This has the same effect as if you were to install the BananaChunk plugin||true|
|core.newPlayerStrategy||Define the strategy used to determine if a player is a new player or not. Valid values are: BUKKIT, PLAYER_DAT and ORIGINAL. Read the comments in the full config.yml for more details.||PLAYER_DAT|
|core.eventPriority||Controls the priority HSP hooks the onJoin and onRespawn events at (which can determine whether HSP wins versus another plugin when these events happen). Defaults to Highest under the assumption that you installed HSP exactly for the purpose of controlling these events, but if for some reason you want to adjust it lower you can do so here. Valid values: lowest, low, normal, high, highest||highest|
|core.verboseLogging||Controls verbosity in your server.log for HSP. The goal is that HSP should be completely silent (except for any possible errors) if this is set to false. Set to true if you like to see occasional messages in your logs as HSP does it's work||false|
|core.verboseStrategyLogging||Setting this to true can be useful when you are setting up your strategies to debug them if you have any issues.||false|
|core.debug||Shouldn't ever be necessary, turns on additional debug messages that can be useful for the developer if you find a bug||false|
Event strategies are the heart and soul of what makes HomeSpawnPlus so flexible and puts the power in your hands to setup your home/spawn scenarios to happen exactly how you want. Events types are broken into three categories and evaluated in this order:
- Events by permission (events.permission.somename.event)
- Events by world (events.world.myworld.event)
- Default Events (events..event)
The events shown here just use the default "events." prefix, but they apply equally to the other two types that are available. Please see this example for the correct format for per-world or per-permission strategies
Please reference the strategies doc for detailed descriptions of strategies.
NOTE: Event types are always evaluated in the order: permission, world, default. The order they appear in the config file does not matter unless a player has two permission chains that apply, in which case the first permission listed in the config file will be the one to "win" (it will NOT evaluate both).
|events.onJoin||Defines the strategy to be used when a player joins the server||- spawnNewPlayer |
|events.onDeath||Defines the strategy to be used when a player dies and respawns||- homeMultiWorld |
|events.onSpawnCommand||Defines the strategy to be used when the player types /spawn||- SpawnLocalWorld |
|events.onGroupSpawnCommand||Defines the strategy to be used when the player types /groupspawn||- spawnGroup|
|events.onHomeCommand||Defines the strategy to be used when the player types /home||- homeMultiWorld|
Cooldowns are the amount of time (in seconds) required before a given command can be used again. Cooldowns timers are unique to the command, meaning the cooldown for "/home" is different than "/spawn". Cooldowns are currently global for all worlds, a future addition will allow changing them per-world or tying them to a specific permission/group.
|cooldown.home||Cooldown time for /home command.||60|
|cooldown.spawn||Cooldown for /spawn command.||60|
|cooldown.groupspawn||Cooldown for /groupspawn command.||60|
Warmups define the amount of time (in seconds) it takes before a given command fires. For example, by setting "/home" to a 10 second warmup, the player must wait 10 seconds after typing "/home" before they are actually teleported home. Like cooldowns, warmup settings are currently global; a future enhancement will allow you to set them up differently per-world or per-permission/group.
|warmup.enabled||This must be set to true for any warmup functionality to work. Although HSP is written to be extremely efficient with events, there is always some small overhead in hooking additional events, so this option allows admins not using warmups to turn off this functionality entirely.||false|
|warmup.onMoveCancel||If set to true, any movement will cancel a warmup||false|
|warmup.onDamageCancel||If set to true, any damage received will cancel a warmup||false|
|warmup.home||Warmup time for /home command.||5|
|warmup.spawn||Warmup time for /spawn command.||5|
|warmup.groupspawn||Warmup time for /groupspawn command.||5|
Home limits options
These options allow you to limit the number of homes a player can have per-world and globally. Home limits are defined for permissions and worlds much the same way events are, please see the default config.yml for examples.
|homeLimits.singleGlobalHome||If true, a single global home is enforced and any other defined limits are ignored. The permission hsp.singleGlobalHomeExempt can be used to exempt some players from this restriction, in which case the normal defined limits still apply.||false|
|homeLimits.default.perWorld||The per-world home limit, if no world or permission specific limit is defined||1|
|homeLimits.default.global||The global home limit across all words, if no world or permission specific limit is defined. -1 is unlimited.||-1|
These options allow you to use your economy plugin of choice to charge players for various commands. You MUST have the optional Vault dependency installed in order for these options to work.
|cost.verbose||If set to true, the player will receive a message every time their account is charged for using a command.||true|
|cost.home||Cost for using the /home command||0|
|cost.sethome||Cost to use the /sethome command||0|
|cost.spawn||Cost to use the /spawn command||0|
|cost.groupspawn||Cost to use the /groupspawn command||0|
This section allows you to entirely disable commands from being available. You might use this, for example, if you just want a really simple single-home-per-world setup and want to disable commands like "/listhomes" or "/deletehome".
[Author's note: These options were originally intended to make admins lives easier by allowing you to make HSP "play nice" with other plugins, disabling commands you want another plugin to use instead (such as /home for MyHomes). Sadly, Bukkit doesn't allow HSP to unregister it's command fully, so the most HSP can do is stop responding to the command, but it can't hand over control to another plugin. So you're still stuck editing plugin.yml files for now - Sorry]
|disabledCommands.groupspawn||Disable /groupspawn command. Note this is the only command disabled by default as it is basically a holdover from the original SpawnControl fork. It might be useful if you want to provide your users access to regular /spawn as well as the ability to go to a group-based spawn separately (such as for RPG classes or something). However strategies have mostly made this not necessary since you have so much flexibility in defining strategies for /spawn, including per-world and per-permission strategies.||true|
|disabledCommands.home||Disable /home command||false|
|disabledCommands.spawn||Disable /spawn command||false|
|disabledCommands.<command>||Just about every single command in HSP can be disabled just by listing the command name here as in the home and spawn examples above.||false|
Command Usurp options
A complaint I heard a few times as people first got started with HSP was that some of their commands weren't working as expected. This was usually caused because some other plugin (such as CommandBook, Essentials, etc) were registering the "/home", "/sethome", etc commands first and so HSP was never getting the commands. The usual fix involves hand-editing plugin.yml files for other plugins, or renaming your JARs such that HSP loads first. Both of these require remembering what you did anytime you update and is a general PITA.
So HSP offers an easier alternative: if you want HSP to "usurp" commands from other plugins, just list those commands here and it will be done, in a way that is upgrade-proof and so won't come back to bite you in the ass on your next upgrade because you forgot to edit a plugin.yml again.
The format is like so:
usurpCommands: - home - sethome - spawn
You can list any commands here that HSP uses and HSP will take them over from any other plugins that have that command registered when it starts up. This option is not enabled by default.
HomeSpawnPlus tries to do "the right thing" and just leverage whatever permission system you have in place. While superperms was supposed to solve all the multiple permission system nonsense, it fell short in implementation and left plugin authors having to write even more code than before to support things that Perm2-compatible plugins had out of the box (such as groups, offline permissions and other-world permissions). Plugins like Vault and WEPIF (WorldEdit) help with this, but not everyone is using these.
So HSP has a single Permission class controlled by a config option that lets you easily choose which Permission system you want to use. In general, you should ever have to do anything with this, since HSP will just look through the default list in order and use the first one it finds. But if, for some reason, you wanted to use WEPIF instead of Vault, or let's say there was a bug in Vault and you wanted to use PEX implementation directly, you can do so with the "permissions" config option. The author recommends Vault, it is by far the most robust and best performing option available. Here is the section right from the default config.yml:
# This defines which permission system HSP uses. Vault and WEPIF # (WEPIF is built into WorldEdit) are preferred, they both provide # a nice interface to all other permission systems. If you don't have # or don't want to use either of those, there is some native support # for a few other permission systems that you can use. These are # checked in the order they are listed for existence, and the # first one to match is used. permissions: - vault - wepif - pex - perm2-compat - superperms - ops