Enchants, limits and the crowbar¶

Configured in enchants.yml, limiters.yml and crowbar.yml.

Custom enchants¶

Enchantments that do not exist in vanilla — the well-known HCF and kitmap ones. Nine ship configured; every one can be renamed, re-levelled, moved to other items, removed, or copied under a new id.

Enchant	Type	Max	On	Does
Fire Resistance	`effect`	I	armour	Fire Resistance while worn
Speed	`effect`	II	boots	Speed while worn
Jump Boost	`effect`	II	boots	Jump Boost while worn
Night Vision	`effect`	I	helmet	Night Vision while worn
Invisibility	`effect`	I	chestplate	Invisibility while worn
Hellforged	`hellforged`	IV	armour	Repairs the piece each time its wearer takes damage
Implanted	`implanted`	III	helmet	Keeps its wearer fed
Recover	`recover`	II	chestplate	Regeneration when health falls low, then a cooldown
Autosmelt	`autosmelt`	I	pickaxe	Smelts what it mines, exactly as a furnace would

Five behaviours, each a type: effect (any potion effect — one more effect enchant is one more block of YAML), hellforged, implanted, recover and autosmelt. Autosmelt follows the server's own furnace recipes, datapacks included.
An effect enchant never overrides a stronger effect from elsewhere: a Speed II potion is not cut down to a Speed I boot.
The enchant lives on the item — its level, a lore line and the glint — so kits, chests, deaths and trades carry it like the rest of the item.
Lowering a max-level lowers items already made.

Getting one¶

Command	Does
`/cenchant list`	What exists — everyone (aliases `/ce`, `/customenchant`)
`/cenchant apply <enchant> [level]`	On the held item — staff
`/cenchant remove <enchant>`	From the held item — staff
`/cenchant give <player> <enchant> [level] [amount]`	Books — staff, and from the console

A book is dragged onto an item in the inventory, with the anvil's rule: a higher book sets its level, an equal one raises it by one, up to the maximum. /cenchant give from the console is how a shop, a crate or a redeem code hands books out. Staff commands need hcfcore.enchant.admin.

Enchantment, potion and effect caps¶

Which levels a map allows — Protection I or II, Sharpness I or II, no Strength II — is the defining choice of an HCF map. Both lists ship empty.

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

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: {}

Enchantments are capped:

at the enchanting table — the offers shown are corrected, and an enchantment with nothing left is refused rather than charged;
at the anvil — a result that brings nothing is removed, so nobody pays for a forbidden book;
on everything else (fix-existing-items, on by default) — loot, villager trades, fishing, other plugins — when the holder joins, closes an inventory, or fights. This only ever lowers. The very first hit with such an item can still land at its old level: a hit's damage is worked out before it can be seen.

A cap can 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.

Potions are capped when the effect comes from a potion — drunk, splashed, lingering, a tipped arrow. An effect above its cap is brought down, not refused: Strength II drinks as Strength I when strength is capped at 1. Golden apples, beacons, commands and other plugins are left alone.

A potion capped at 0 is forbidden:

it is not brewed: the brewing stand leaves that bottle as it was (the ingredient is used up, as for the other bottles);
drinking or throwing one is refused, and the potion stays in hand; shooting a tipped arrow of it is refused. The player is told why;
one that still reaches a player — a dispenser, a potion from before — gives nothing.

Strength from the Bard only

The classic HCF rule: strength: 0 under caps. The classes are not potions: a Bard still gives Strength to the team, and a class's own effects are untouched. See Classes.

Effect caps¶

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: {}

An effect cap holds whatever gives the effect: a potion, a class — a Bard's burst, a Diamond's passive —, a custom enchant, the King, a golden apple, a beacon, a command, another plugin. resistance: 3 and no player ever has more than Resistance III. An effect above its cap is brought down to it, keeping its duration; 0 forbids the effect entirely.

	`potions.caps`	`effects.caps`
What it caps	The effect when a potion gives it	The effect, whatever gives it
A Bard's Strength II, with `strength: 1`	Untouched	Strength I
A Strength II potion, with `strength: 1`	Strength I	Strength I
`0`	The potion is not brewed, nor drunk, thrown or shot	Nobody has the effect

For a potion, the lower of the two caps holds. The classes, custom enchants and the King give their effects already within the cap — a Bard wanting Resistance IV gives Resistance III — and still take back only what they gave. A cap set with /hcf reload holds at once on the effects players already have, and on those a player brings back when joining. The effect commands are capped too.

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. Ships empty:

limiters.yml

claim-blocks:
  enabled: true
  limits: {}

/team limits (alias blocks) shows your team's usage.
A limit of 0 forbids the block in claims. Only player teams' land counts.
Counts are kept per chunk and per team — claims being block-precise, two teams can share a chunk and are never charged each other's blocks — as blocks are placed, broken, burnt and blown up, and each claimed chunk is recounted exactly in the background the first time it loads after a start — which puts right what no event reports (redstone washed away, blocks changed by another plugin).
Staff get past the limits only while holding hcfcore.limiter.bypass and with /staffbuild on.

Crowbar¶

A tool that takes a placed End portal frame out — the block survival cannot break, and a common part of base traps. Right-click a frame with it; the frame drops as an item, and its eye too if it had one.

/crowbar give <player> [amount]      # hcfcore.crowbar.admin

Where: in the wilderness, or in your own team's claim. Never in another team's claim — raidable or not — nor on server land or in the warzone. The crowbar is there so a team can adjust its own traps, not so a raid can defuse somebody else's.

The removal is then offered to every other protection as an ordinary block break, so a Mountain or another plugin's region still has its say.
Ships neutral: unlimited uses (uses), no cooldown (cooldown-seconds), no cost (cost, taken from the economy). Nothing is taken for a refused use.
The item, its name and its lore are configurable; %uses% in the lore shows the uses left.
Frames only — no spawners. Taking a frame out of an already active portal leaves the portal blocks in place, as in vanilla.