Pages

configuration/1.5.x

A default configuration file should be created on first run of the plugin. For an explanation, see the comments below.

Default Configuration File Explained

settings:
# Should players respawn at their /home?
  respawnToHome: true
# Does sleeping in a bed set home? 0 = disabled, 1 = enabled, 2 = enabled, /sethome command disabled.
  bedsCanSetHome: 0
# Can players sleep to set home in the day?
  bedsDuringDay: false
# The locale to use (set this to 'file' to load from customlocale.properties)
  locale: 'en'
# Should messages be coloured?
  useColors: true
# Should invites be enabled?
  enableInvite: true
# Should we register permissions defaults? (Set this to false if you don't want users to have access to basic commands by default!)
  enableDefaultPerms: true
# Should the /sethome command be used?
  enableSetHome: true
# Should we log detailed debugging information? (Don't use this unless you need to!) 
  debugLog: false
# Should we download any of the needed libs automatically?
  downloadLibs:
    enable: true
    mysqlLib: true
    sqliteLib: true
  mysql:
# Should we use mysql? If false, sqlite.
    enable: false
# The connection string to use. Replace 'minecraft' with the name of the database you want to use.
    connection: 'jdbc:mysql://localhost:3306/minecraft'
# The mysql username and password - If your password contains numbers and/or special characters, make sure it is quoted with '.
    username: 'minecraft'
    password: 'password'
# A list of worlds to enable respawnToHome on. The respawnToHome setting must be true for this to work. If this list is empty, all worlds are enabled.
  respawnToHomeWorlds: []
# The default values for each of the permission based variables if no permissions are found.
defaults:
  homeLimit: 3
  homeInvLimit: 1
  warmup: 0
  cooldown: 0
# The limits given to each permission node on the number of homes. For usage information, please read on!
homeLimits:
  a: 30
  b: 20
  c: 15
  d: 10
  e: 5
# The limits given to each permission node on the number of invites per home. For usage information, please read on!
homeInvLimits:
  a: 10
  b: 8
  c: 6
  d: 4
  e: 2
timers:
# Should the timer permissions be used?
  timerByPerms: false
# Should timer permissions be added onto the default time?
  additionalTime: false
# Should we message the user when they can teleport again?
  cooldownNotify: false
# Should we message the user when they have warmed up?
  warmupNotify: true
# Should warmups be aborted if the player is damaged/attacked?
  abortOnDamage: 0
# Should warmups be aborted if the player moved?
  abortOnMovement: false
# The cooldown and warmup times applied to the permissions nodes. For usage information, please read on!
  cooldowns:
    a: 0
    b: 5
    c: 10
    d: 15
    e: 20
  warmups:
    a: 0
    b: 5
    c: 10
    d: 15
    e: 20
economy:
# Should we attempt to enable economy support?
  enable: false
# How much should players be charged each time they warp.
  warpCost: 0
# How much should players be charged each time they set or move a home.
  setCost: 0

Variable Permissions Explained

uHome allows you to set limits and timers for players based on their permission nodes. These permission nodes are created by the plugin dynamically depending on your config file, so make sure you read the following carefully!

When uHome loads the config file, it will scan each variable section of your config. As of the time of writing, these sections are homeLimits, homeInvLimits, cooldowns, and warmups. Each of these sections should contain name-number pairs, where name will be used to form the permission node, and the number shall be used as the variable (e.g. the number of homes a player can set). The default config for homeLimits is as follows:

homeLimits:
  a: 30
  b: 20
  c: 15
  d: 10
  e: 5

In this example, the letters are the permission node names, and the numbers are the home limits. The permission node is created by adding the name to a stub, which in this case is "uhome.limit.". Therefore, if I wanted to give myself a home limit of 20, I would give myself the permission node "uhome.limit.b", as b is set to 20 in the config shown above.

Dynamic Permission Nodes (Stubs)

  • homeLimits => "uhome.limit."
  • homeInvLimits => "uhome.invlimit."
  • warmups => "uhome.warmup."
  • cooldowns => "uhome.cooldown."

Permission Node Priority & Inheritance

If your permissions plugin has any form of multi-group support or inheritance (which all the current permissions plugins do), you may notice a problem at this point. If a player has two or more permission nodes for the same limit, which limit does the plugin use? If you've used uHome previously, you may remember that priority was calculated alphabetically. In 1.5 and up, the priority of a dynamic permission node depends on it's position in the config file section. In the default configuration example used above, this would mean that the plugin would do the following checks to calculate your limit:

  1. Check if the player has the required bypass permission. If so, no limit.
  2. Check if the player has the limit permission "uhome.limit.a". If so, use the limit a from the config.
  3. Check if the player has the limit permission "uhome.limit.b". If so, use the limit b from the config.
  4. Check c as above.
  5. Check d as above.
  6. Check e as above.
  7. If no permissions have been found at this point, fall back to use the limit from the config under the 'defaults' section.

Users upgrading to 1.5.x will notice that this default config causes exactly the same checks as in v1.4. This is to make your permissions setup backwards compatible, and the upgrade process as smooth as possible.

Comments

Posts Quoted:
Reply
Clear All Quotes