limiters.yml¶

Enchantment caps, potion caps, effect caps, and the most of each block a team's territory may hold.

Every example on this page is taken from the shipped limiters.yml. Changes apply with /hcf reload, to what players already carry too. Every list ships empty: which levels a map allows is its defining choice. enabled: true at the top switches everything on and off.

Enchantments¶

limiters.yml

enchantments:
  # The highest level each enchantment may reach. 0 forbids it entirely. Anything
  # not listed keeps vanilla's levels.
  #
  # EMPTY ON PURPOSE. Which levels a map allows - Protection I or II, Sharpness I
  # or II - is the defining choice of an HCF map, and not a default to invent.
  #
  # Names are the enchantment's id, with or without "minecraft:". A name this
  # server does not know is reported in the console when the file is loaded.
  #
  # A cap can also be ABOVE vanilla's maximum: the anvil then combines past it,
  # with vanilla's rule - two equal levels make one higher - so two Sharpness V
  # make Sharpness VI when sharpness is capped at 6. Nothing else in the game
  # creates such levels, so the anvil is where they come from.
  #
  #   caps:
  #     protection: 2
  #     sharpness: 2
  #     power: 3
  #     fire_aspect: 0
  caps: {}

  # Caps always apply at the enchanting table and the anvil. This also brings
  # down items that arrive some other way - loot, villager trades, fishing,
  # another plugin - when their holder joins, closes an inventory, or fights with
  # them. It only ever lowers. The very first hit with such an item can still land
  # at its old level: the damage of a hit is worked out before it can be seen.
  # Enchanted books are left as they are - they only give their levels through an
  # anvil, which caps them.
  fix-existing-items: true

Key	As shipped	What it does
`caps`	`{}`	Enchantment id to its highest level; `0` forbids it. A cap above vanilla's maximum is reached at the anvil
`fix-existing-items`	`true`	Also lower items that arrive otherwise — loot, trades, other plugins — on join, on closing an inventory and in combat

Potions¶

limiters.yml

potions:
  # The highest level each effect may be applied at FROM A POTION - drunk,
  # splashed, a lingering cloud, a tipped arrow. 0 forbids it. Anything not
  # listed is untouched. An effect above its cap is brought down to it rather
  # than refused: Strength II drinks as Strength I when strength is capped at 1.
  #
  # A forbidden potion (0) is not brewed, and drinking, throwing or shooting one
  # is refused and the player told - a potion is kept, not used up for nothing.
  #
  # Golden apples, beacons, commands and other plugins are left alone: a cap on
  # regeneration is about potions, not about apples. So are the classes' effects:
  # "strength: 0" leaves Strength to the Bard.
  #
  # Empty on purpose, like the enchantments.
  #
  #   caps:
  #     strength: 0        # Strength from the Bard only
  #     invisibility: 0
  #     speed: 2
  caps: {}

Key	As shipped	What it does
`caps`	`{}`	Effect to its highest level from a potion (drunk, splashed, lingering, tipped arrow); `0` forbids it: not brewed, drinking, throwing or shooting refused. Above the cap, the effect is brought down, not refused. A Bard's effects are not potions

Effects¶

limiters.yml

effects:
  # The highest level each effect may have on a player, WHATEVER gives it: a
  # potion, a class (a Bard's burst), a custom enchant, the King, a golden apple,
  # a beacon, a command, another plugin. 0 forbids it. Anything not listed is
  # untouched; an effect above its cap is brought down to it, not refused.
  #
  # Where potions.caps above is about potions only, this is about the effect:
  # "resistance: 3" and no player ever has more than Resistance III.
  #
  # Empty on purpose, like the rest.
  #
  #   caps:
  #     resistance: 3
  #     speed: 3
  caps: {}

Key	As shipped	What it does
`caps`	`{}`	Effect to its highest level on a player, whatever gives it — potion, class, custom enchant, the King, golden apple, beacon, command, another plugin; `0` forbids it. Above the cap, the effect is brought down, keeping its duration. Applies at once on `/hcf reload` and on join. For a potion, the lower of `potions.caps` and this holds

Blocks per claim¶

limiters.yml

claim-blocks:
  enabled: true
  limits: {}

Key	As shipped	What it does
`enabled`	`true`	The block limits
`limits`	`{}`	Block name to the most a team's whole territory may hold; `0` forbids it in claims

The whole shipped file¶

View it on GitHub.

limiters.yml

# ---------------------------------------------------------------------------
# limiters.yml - enchantment, potion and effect limits
#
# /hcf reload applies changes at once, including to what players already carry.
#
# Lines "# --8<-- [start:...]" and "# --8<-- [end:...]" mark the parts the online
# documentation quotes from this file. They are comments and change nothing.
# ---------------------------------------------------------------------------

enabled: true

enchantments:
  # The highest level each enchantment may reach. 0 forbids it entirely. Anything
  # not listed keeps vanilla's levels.
  #
  # EMPTY ON PURPOSE. Which levels a map allows - Protection I or II, Sharpness I
  # or II - is the defining choice of an HCF map, and not a default to invent.
  #
  # Names are the enchantment's id, with or without "minecraft:". A name this
  # server does not know is reported in the console when the file is loaded.
  #
  # A cap can also be ABOVE vanilla's maximum: the anvil then combines past it,
  # with vanilla's rule - two equal levels make one higher - so two Sharpness V
  # make Sharpness VI when sharpness is capped at 6. Nothing else in the game
  # creates such levels, so the anvil is where they come from.
  #
  #   caps:
  #     protection: 2
  #     sharpness: 2
  #     power: 3
  #     fire_aspect: 0
  caps: {}

  # Caps always apply at the enchanting table and the anvil. This also brings
  # down items that arrive some other way - loot, villager trades, fishing,
  # another plugin - when their holder joins, closes an inventory, or fights with
  # them. It only ever lowers. The very first hit with such an item can still land
  # at its old level: the damage of a hit is worked out before it can be seen.
  # Enchanted books are left as they are - they only give their levels through an
  # anvil, which caps them.
  fix-existing-items: true

potions:
  # The highest level each effect may be applied at FROM A POTION - drunk,
  # splashed, a lingering cloud, a tipped arrow. 0 forbids it. Anything not
  # listed is untouched. An effect above its cap is brought down to it rather
  # than refused: Strength II drinks as Strength I when strength is capped at 1.
  #
  # A forbidden potion (0) is not brewed, and drinking, throwing or shooting one
  # is refused and the player told - a potion is kept, not used up for nothing.
  #
  # Golden apples, beacons, commands and other plugins are left alone: a cap on
  # regeneration is about potions, not about apples. So are the classes' effects:
  # "strength: 0" leaves Strength to the Bard.
  #
  # Empty on purpose, like the enchantments.
  #
  #   caps:
  #     strength: 0        # Strength from the Bard only
  #     invisibility: 0
  #     speed: 2
  caps: {}

effects:
  # The highest level each effect may have on a player, WHATEVER gives it: a
  # potion, a class (a Bard's burst), a custom enchant, the King, a golden apple,
  # a beacon, a command, another plugin. 0 forbids it. Anything not listed is
  # untouched; an effect above its cap is brought down to it, not refused.
  #
  # Where potions.caps above is about potions only, this is about the effect:
  # "resistance: 3" and no player ever has more than Resistance III.
  #
  # Empty on purpose, like the rest.
  #
  #   caps:
  #     resistance: 3
  #     speed: 3
  caps: {}

# ---------------------------------------------------------------------------
# Blocks per claim: the most of a block a team's whole territory may hold -
# against lag machines and abuse. Placing one more there is refused. Only player
# teams' land counts. Staff get past the limits only while they hold
# hcfcore.limiter.bypass AND have /staffbuild on - an operator placing blocks in
# normal play is counted like anybody else. Players see their team's usage with
# /team limits.
#
# Counted per chunk and kept up as blocks are placed, broken, burnt and blown up;
# each claimed chunk is also recounted exactly - off the main thread - the first
# time it loads after a start, which puts right whatever the events cannot see
# (redstone washed away by water, blocks changed by another plugin). A limit of 0
# forbids the block in claims. Names as the server spells them. Ships empty:
#
#   claim-blocks:
#     enabled: true
#     limits:
#       HOPPER: 64
#       SPAWNER: 8
#       REDSTONE_WIRE: 256
# ---------------------------------------------------------------------------
claim-blocks:
  enabled: true
  limits: {}