Skip to content

Actorless automation policies

Minecraft automation has no reliable player actor. McProgression therefore checks each automated path against the item's configured action gate, and never awards XP from an automated inventory event. Each path has its own policy so owners can preserve ordinary redstone logistics while protecting gated actions.

Defaults and settings

All settings are under progression.automation in config.yml:

Setting Default Values Coverage
gated-recipes deny-gated deny-gated, station-owner, allow Furnace, blast furnace, smoker and their hopper-managed inputs/results. Checks recipe contexts such as CHARCOAL, FOOD and SMELT.
unowned-stations deny-gated deny-gated, allow Legacy/unowned stations when either owner mode is selected.
crafter deny-gated deny-gated, allow CRAFT requirement on the Crafter's resulting item.
inventory-transfers deny-gated deny-gated, allow Hopper, dropper and hopper-minecart inventory movement; item entities collected by inventories. Checks source CONTAINER, destination STORE, and item pickup PICKUP plus STORE.
brewing deny-gated deny-gated, station-owner, allow Automated Brewing Stand input transfers and potion extraction, checked against BREW.
dispenser deny-gated deny-gated, allow Dispenser use, projectile launch, placement and armor equip; uses USE, SHOOT, CONSUME, PLACE, EQUIP, or DROP for generic item ejection. Dropper ejection uses DROP. Shears used by a dispenser are covered.

deny-gated means actorless action requirements are evaluated against the no-owner profile. Ungated rules keep working. The policy does not block a hopper merely because it exists, and it does not impose a Hopper placement level. allow bypasses only the named automated path. Invalid policy values fall back to the safe deny-gated behavior.

Station ownership

station-owner records a UUID in the processing station's persistent block data after placement. Furnace-family recipe automation and Brewing Stand automation then use that owner's current skill levels, even when offline. Breaking and replacing a station records the new placer. Existing stations have no owner and follow unowned-stations, which defaults to deny-gated; an administrator can replace those stations or explicitly use allow for unowned stations. Opening a station does not claim it, so shared access does not transfer progression authority.

Path behavior and limits

  • Furnace recipe input and result transfers are matched against Bukkit's registered cooking recipes. If an ambiguous transfer could match contexts with different requirements, denial of any matching context blocks it. Fuel and items without matching recipe context remain unaffected by the recipe policy. Custom recipe systems that do not register recipes with Bukkit are outside this classification.
  • Crafter results use Paper's cancellable CrafterCraftEvent; the adapter fails closed if it cannot read the result. On Paper 1.21.1 and later this event is available.
  • Generic inventory transfers have no owner mode: there is no trustworthy actor to inherit. They check configured storage/item action requirements without awarding XP.
  • Brewing checks each item moved into a Brewing Stand against its BREW rule, and checks potion output before hopper extraction. InventoryMoveItemEvent does not identify the destination slot, so fuel, bottles and ingredients are all subject to the input check if they have a BREW rule. A result-only gate can allow the brewing process to finish while leaving the gated potion in the stand; players and hoppers cannot extract it until authorized. Manual ingredient/result interaction continues to use the player's own level. Automated movement clears temporary brewing XP attribution so a hopper cannot receive credit for an earlier player insertion.
  • Dispensing is classified by event subtype and item type. Unknown dispenser items use the conservative DROP gate because the event does not identify every custom or vanilla outcome. A generic dispense event may not identify every behavior added by another plugin; those integrations need an explicit adapter.
  • Commands, loot, plugin inventory writes, external automation plugins, explosions, pistons and mob actions do not all expose one cancellable Bukkit event. Those remain integration or server-policy boundaries rather than silently deleting items after an uncancellable event.
  • Redstone actions and automated transfers never award player XP. The system does not infer a player from a recent interaction, station opener, or item owner.

Validation checklist

Before production, test hopper insertion/extraction on all furnace sides, mixed recipes, fuel, blocked destinations, full inventories, Crafter output, Brewing Stand input and output, hopper minecarts, droppers, item-entity pickup, dispenser projectiles/blocks/equipment/shearing, legacy stations, offline owners, owner replacement, all three modes, and interaction with other plugins. Confirm cancelled transfers neither duplicate nor delete items, and that unlocked manual interactions still work. Repeat on Paper 1.21.1, 1.21.11 and 26.3.

The adapters and defaults are implemented. The above matrix still needs in-game gameplay validation, especially mixed storage/recipe gates, manual potion extraction, slot-agnostic brew input checks, owner data on old stations, and third-party automation integrations.

API references