Add Brew Packer factory to make BreweryX brews stackable

[xFier]

What

Adds a BREW_STACK recipe type to FactoryMod and a Brew Packer factory that makes BreweryX brews stackable.

Brews are potions, which vanilla caps at a stack size of one, so every bottle takes a whole inventory slot and bulk trade and transport are painful. The recipe hands back the same brew with the vanilla max_stack_size component set on it, so bottles merge into a single slot while staying real, drinkable, BreweryX readable brews. Stacks split and merge like any other item.

How it works

• Sealing is required. BreweryX writes a fresh random scramble id into an unsealed brew on every save, so no two unsealed brews are ever equal and they could never stack. Pre-sealed brews are accepted as they are; unsealed ones are sealed during the run when seal_unsealed is on. Sealing is irreversible and rounds an odd quality down to the next even one, exactly as BreweryX's own sealing table does.
• Sealed brews are inert. Brew#age, Brew#distillSlot and Brew#canDistill all short circuit on immutable, and BSealer / MCBarrel guard on isStripped / isStatic, so a stack cannot be aged, distilled or re-sealed in bulk. No duplication vector through BreweryX's mechanics.
• Allow list only, keyed by BreweryX brew id (the yaml key in BreweryX's config) rather than display name. The id is stable across renames and unique by construction, whereas the name is a bad/normal/good triplet that is easy to pick the wrong part of. Ids cannot be checked at parse time because BreweryX loads POSTWORLD, so unknown ones are reported once on first use rather than failing silently.
• Per brew stack sizes, so spirits can stack lower than everyday brews.
• Already packed brews are skipped, so feeding one back in never charges the cost twice.

Drinking from a stack

This needed a fix. BreweryX swaps the potion for a plain one in PlayerItemConsumeEvent so vanilla does not apply its effects, which sends the server down the branch that finishes using the replacement rather than the held stack and then calls setItemInHand, overwriting the stack wholesale. Without this, drinking one brew off a stack of sixteen would leave the player holding a single glass bottle and destroy the other fifteen.

BrewStackListener sets the event's replacement to the rest of the stack and hands the empty bottle over separately, since overriding the replacement drops the one the server made. Stacks now drain a bottle at a time, the way eating from a stack of food does. It runs after BreweryX's handler (HIGHEST) so a drink refused in creative or by BPlayer#drink is left alone.

Config

BREW_STACK is documented in the plugin's default config.yml. The live factory is added to both the paper and zorweth FactoryMod configs:

  pack_brews:
    production_time: 2s
    name: Pack Brews
    type: BREW_STACK
    input:
      glass_bottle: { type: GLASS_BOTTLE, amount: 1 }
    max_stack_size: 16
    seal_unsealed: true
    packed_lore: Packed Brew ({size})
    allowed_brews:
      wheatbeer: 16
      beer: 16
      darkbeer: 16
      mead: 8
      whiskey: 8
      vodka: 4

allowed_brews also accepts a plain list of ids, and {size} in packed_lore is replaced with that brew's limit.

BreweryX is a compileOnly dependency on the jar already vendored in ansible/src/paper-plugins, matching zorweth, kitpvp and simpleadminhacks, and is a softdepend — without it the recipe is skipped with a warning and the listener is not registered.

Testing

This has not been run on a server yet. It compiles and the behaviour was traced through Paper, CraftBukkit and BreweryX source, but FactoryMod has no test suite so there is no runtime evidence. Reviewers should treat the following as unverified:

• Factory formation, since setup cost uses containedExactlyIn and a wrong amount just makes the crafting table silently do nothing
• Drinking from a stack: stack drops by exactly one, one glass bottle arrives, drunkenness applies once, no hand-slot desync; plus creative mode and the last bottle off a stack
• Packing from both sealed and unsealed input, and that output merges to the configured size
• Allow list rejection, repack skipping, per brew sizes, full output chest, and the unknown-id warning firing once

Balance note

Setup cost and the allow list are a starting point, not settled balance. Both are effectively permanent once players hold stock: the max_stack_size component stays on the item, and brews packed at different sizes or under different packed_lore will not stack with each other, so these are best fixed before release.

🤖 Generated with Claude Code

[okx-code]

The LLM disclosure policy requires the model(s) used to be specified as well, can you add them?

[xFier]

Yes, I haven't fully reviewed all of this myself, nor tested it locally or a whole bunch of other things I need to do before this is marked ready for review. Just wanted to get it out of the context window before I leave for a few hours.

But, the model used was Claude Opus 5 with high effort.

[xFier]

Consistent with the compactor, but almost every other factory uses 1.0

[xFier]

A real balanced setup cost is going to be needed before this is released.

[xFier]

See above comment.

[xFier]

Essentially all of this needs to be balanced/reviewed further.

[xFier]

I'm sure brewery has a maven repo entry or something we can use here instead. This seems pretty brittle.