Matt
0b90e94079
Build / build (push) Has been cancelled
Anti-farm system that limits how much income players can extract from
villager trading in one location. Designed to make 50-librarian halls
diminish into futility without disabling villager trading altogether.
Model:
- World is partitioned into 64×64 block tiles (no POI lookups,
villager-position rounded by integer division)
- Each tile has a CompoundTag of {item_id -> remaining_demand} at
server.persistentData.bnsVillageDemand[dim:tileX:tileZ]
- Demand caps per item are set in VillageDemand.java; paper=20,
wheat=25, rotten flesh=15, iron=6, diamond=1, etc.
- Demand refills linearly: full cap restored over 1 hour of real time
(no scheduled tick — refresh computed lazily on each query from
lastUpdated timestamp)
- A 1-tile multi-profession hall earns ~150 spurs/hour at saturation.
Scaling income requires building halls in distant tiles — that's
overworld logistics, not micro-exploit.
Implementation:
- VillageDemand.java: per-item cap config
- VillageDemandTracker.java: lazy-refresh + atomic decrement against
the KubeJS server-scope NBT (existing reflection accessor)
- VillageTrackedMerchantOffer.java: MerchantOffer subclass that
overrides increaseUses() to decrement demand on trade completion
- VillagerTradeRebalance.java: at offer-build time, queries current
tile demand for the cost item. If saturated (<1 left), the offer
comes back with uses=maxUses (vanilla "out of stock" UI). Otherwise
wrapped in VillageTrackedMerchantOffer so post-trade decrement fires.
- Wandering trader: uses whatever tile he's wandered into. No special
case — it's just whichever tile he stands in at trade time.
Wandering traders, modded merchants (entity is not Villager): same
tracking, same caps. Anything that produces a spur as a trade result
is throttled by the tile.
Hooks: zero mixins. MerchantOffer.increaseUses() is vanilla-public
and fires server-side after the trade settles, so a subclass override
is the right hook point.
Perf: lazy refresh = no scheduled ticks. Per-trade overhead is one
NBT lookup + a few timestamp ops, microseconds. Idle servers do zero
work.
Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>
bnstoolkit
Companion mod for the Brass and Sigil modpack. NeoForge 1.21.1.
Provides the in-game UI surface for the KubeJS-driven civic tier, bounty, plot, and shop systems. Pure client visuals + a thin C2S/S2C network bridge over the existing server-side state — no server-side gameplay logic lives here, just transport and presentation.
Status
M0 — scaffold only. Loads cleanly on client and dedicated server. No screens are open-able yet (key bindings register but their handlers are TODO). One network round-trip pair is wired as a smoke test.
See docs/bnstoolkit-architecture.md in the brass-and-sigil repo for
the full spec.
Building
./gradlew build
The output jar lands in build/libs/bnstoolkit-<version>.jar. Drop it
into the modpack's pack/overrides/mods/ directory.
Package layout
uk.sijbers.bnstoolkit
├── BnsToolkit # common mod entry
├── BnsToolkitClient # client mod entry
├── client
│ ├── BnsKeyBindings # T / B / P defaults
│ ├── hud
│ │ └── SpurHud # spurs + tier overlay
│ └── screens
│ ├── BaseBnsScreen # shared parent (will swap to FTB Library)
│ ├── TierUpgradeScreen
│ ├── BountyBoardScreen
│ ├── QuestLogScreen
│ ├── PlotPurchaseScreen
│ └── ShopBrowserScreen
└── network
├── BnsNetwork # payload registrar
├── c2s
│ └── RequestTierStatePacket
└── s2c
└── TierStateUpdatePacket
Milestones
| Milestone | Scope |
|---|---|
| M0 (now) | Scaffold, keybinds, network smoke-test packet pair |
| M1 | Tier upgrade screen + KubeJS bridge for tier/balance |
| M2 | Quest log + shop browser screens |
| M3 | Bounty board + plot purchase screens |
| M4 | HUD overlay, mod settings screen, FTB Library swap |