Enchanting

MythicEnchants manages the vanilla enchanting table's offerings while adding features such as live conditional enchanting using enchantment conditions and new reagent types beyond Lapis Lazuli.

Enchanting Table Plugin Configuration

The Plugin's Config features a section dedicated to global enchanting table behavior, managing the vanilla table with a variety of options when custom-table: true. (Without MythicEnchants table management, many features such as reagents and enchanting conditions will not take effect).

The configuration options are explained in comments in the config file itself.

enchanting:
  # Disables MythicEnchants providing its own emulated enchanting table.
  # Required for reagents and conditional enchanting.
  # All enchantments are registered using vanilla datapack offering settings.
  custom-table: true
  # Vanilla-override: register treasure enchants as offered in the table.
  allow-treasure: false
  # Whether vanilla enchantments can appear in the custom enchanting table.
  # When false (default), only custom MythicEnchants enchantments are offered.
  # When true, vanilla enchantments are filtered using datapack supported_items
  # tags (authoritative item-type check) and can fill slots that have no custom
  # enchantment available.
  vanilla-in-table: true
  # When true, an empty reagent slot is treated as if vanilla lapis were
  # present — offers are computed against the "vanilla" reagent bucket and
  # shown immediately when the player drops in an item. When false (default),
  # the table waits until the player adds *something* to the reagent slot
  # before producing offers (vanilla lapis still rolls vanilla-bucket offers,
  # custom reagents roll their own bucket). Use `true` for the legacy
  # always-show behavior; `false` for a reagent-gated UX.
  assume-reagent-lapis: false
  # Custom-table only. Replaces vanilla's hard-coded "1 power per bookshelf,
  # capped at 15" with a configurable material weight map and three per-slot
  # equations evaluated against a `count` variable.
  #
  #   * `materials` — block ID → power weight. Any block listed here is counted
  #                   at the same 30 positions vanilla scans for bookshelves.
  #                   The value is summed (e.g. 5 BOOKSHELF + 2 EMERALD_BLOCK
  #                   with the weights below → count = 5*1 + 2*3 = 11).
  #   * `require-line-of-sight` — when true, follows vanilla's air-gap rule
  #                   (the cell between the table and a power block must be
  #                   air). Stops players cheesing with solid walls.
  #   * `equations` — exp4j expressions for slot1/slot2/slot3 (top→bottom in
  #                   the table UI). Variable `count` is the summed power.
  #                   Functions: `floor`, `ceil`, `min`, `max`, `clamp`,
  #                   `randomInt(a,b)` (inclusive), plus all standard math.
  #                   Omit a slot's equation to fall back to the vanilla
  #                   formula for that slot.

Bookshelves are the vanilla conduit block used for Enchantment power to increase the enchantment levels and offers.

table-power:
  materials:
    BOOKSHELF: 1
    # EMERALD_BLOCK: 3
  require-line-of-sight: true
  # Optional. When omitted, scans vanilla's hand-picked 30 positions (the
  # exact set vanilla uses for bookshelves). When present, replaces that
  # with a chebyshev-distance cuboid scan around the table.
  #
  #   inner — exclusive lower bound on max(|dx|,|dz|). 2 reproduces vanilla's
  #           "shelves can't be adjacent to the table" gap. 0 lets blocks
  #           directly touching the table count.
  #   outer — inclusive upper bound on max(|dx|,|dz|).
  #   y-min / y-max — inclusive Y offsets relative to the table block.
  #                   Vanilla equivalent is 0..1 (two layers).
  #
  # LOS rule for wide radii: there's no single "cell between table and shelf"
  # once the radius exceeds 2, so the check approximates by requiring the
  # cell at (sign(dx), 0, sign(dz)) — the doorway adjacent to the table —
  # to be replaceable. Solid wall around the table still kills the bonus.
  # radius:
  #   inner: 2
  #   outer: 7
  #   y-min: 0
  #   y-max: 1
  equations:
    slot1: "floor(min(max((randomInt(1,8)+floor(count/2)+randomInt(0,count))/6, 1), 10))"
    slot2: "floor(min((((randomInt(1,8)+floor(count/2)+randomInt(0,count))*2)/4)+1, 15))"
    slot3: "floor(max(((randomInt(1,8)+floor(count/2)+randomInt(0,count))/2)+2, min(20, count*2)))"
  # After each slot's equation evaluates, clamp the result to this maximum.
  # Saves wrapping every equation in min(...). Defaults shown below
  # (10/15/30) mirror vanilla's progression. To opt a slot out of its cap
  # so only the global `max-base-level` applies, set it to `0`. Omitting
  # the entire block keeps the defaults; omitting a single slot also
  # keeps that slot's default.
  slot-caps:
    slot1: 10
    slot2: 15
    slot3: 30
  #
  # Hard upper bound applied last — defaults to 30 to match vanilla's
  # enchanting-table UI. Lifting beyond 30 works (the algorithm will pick
  # higher-tier enchants for the candidate pool) but the XP-cost number
  # renders in red and demands that many player levels to confirm. Set
  # carefully if you want deeper progression than vanilla allows.
  max-base-level: 30

Enchanting Configuration for Enchantments

Enchantments can have their Enchanting Table behavior configured directly.