Plain command surface for V1 (Phase 3): /quests, /quests info,
/quests cancel. Cheap to ship, works on mobile via the bridge.
Quest Log book item in V2 (Phase 3.5) -- nicer surface, same backend.
Sidebar HUD as V3 later, optional.
Adds a 3-quest active slot cap so cancellation is meaningful:
prevents accept-all/RNG-shop-cancel exploit, makes the cancel
button a real choice. Quest moves to READY frees the slot.
State storage schema documented (per-player JSON with active +
completed/cooldown tracking).
Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>
Full design for the unified spawn economy:
- Seven themed guild buildings (Adventurer's, Merchant's, Civic,
Library, Tavern, Foundry, Mint)
- Universal accept → complete → return quest pattern
- Villagers moved fully to spurs with rebalance principles +
initial price guidance
- Money flow architecture (bounded inflows, scaling sinks)
- Phasing plan (8 phases, each independently shippable)
- Mod stack confirmed (we have everything we need for V1)
- Risk register + open decisions to make before implementation
Status: design, not yet implemented. Phase 0 (spawn skeleton)
is the next concrete deliverable.
Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>
Stop hacking around the problem -- use the standard cross-recipe-
viewer hide convention that both NeoForge and JEI define.
Source-level confirmation:
mezz/JustEnoughItems @ 1.21.1
CommonApi/.../api/constants/Tags.java
HIDDEN_FROM_RECIPE_VIEWERS = c:hidden_from_recipe_viewers
Library/.../ingredients/IngredientVisibility.java
isIngredientVisible() calls
ingredientHelper.isHiddenFromRecipeViewersByTags(typedIngredient)
-> any item carrying this tag is hidden from JEI.
neoforged/NeoForge @ 1.21.x
common/Tags.java
Tags.Items.HIDDEN_FROM_RECIPE_VIEWERS = c:hidden_from_recipe_viewers
-> same tag, NeoForge agrees with JEI.
EMI / REI also respect this tag (common convention).
So the proper modpack-shippable fix is a single datapack file:
pack/overrides/world/datapacks/bns-fuel/data/c/tags/item/
hidden_from_recipe_viewers.json
{
"replace": false,
"values": [
"alexsmobs:shattered_dimensional_carver",
"alexsmobs:transmutation_table"
]
}
No mod, no KubeJS, no CraftTweaker, no Item Obliterator JEI integration
(which doesn't exist for 1.21.1 NeoForge anyway). Just the tag the
recipe-viewer ecosystem agreed on years ago.
Item Obliterator + Necronomicon stay in the pack for what they actually
deliver on 1.21.1: inventory-pickup block + villager-trade removal +
right-click cancellation. The Capsid recipe override stays too as the
creation block.
The full disable stack now:
- Tag (this commit) -> Hidden from JEI / REI / EMI
- Datapack capsid recipe -> Can't be created in-world
- Item Obliterator -> Can't be picked up / right-clicked
if obtained via /give or creative
Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>
I removed this datapack override in v0.31.0 on the (incorrect)
assumption that Item Obliterator would also handle Alex's Mobs'
custom capsid_recipes recipe type. It doesn't -- Item Obliterator
intercepts vanilla and some common modded recipes, but the Capsid
uses its own SimpleJsonResourceReloadListener bound to the
"capsid_recipes" folder, and that listener still loaded the
default shipped recipe.
The visible bug: a player could put a regular Dimensional Carver
into a Capsid -- the recipe matched, the Dimensional Carver was
consumed, and the Capsid spat out a Shattered Dimensional Carver.
Item Obliterator then refused the pickup. Net result:
- Player loses their hard-earned regular Carver
- Player can never pick up the Shattered one
- World has an unrecoverable floating item entity
Restore the override at:
pack/overrides/world/datapacks/bns-fuel/data/alexsmobs/
capsid_recipes/shattered_dimensional_carver.json
This swaps the recipe's input from `alexsmobs:dimensional_carver` to
`minecraft:barrier`, which is unobtainable in survival. The recipe
loads cleanly but can never match. The Capsid transformation for
the Shattered Carver effectively no longer exists.
Item Obliterator still handles the JEI / creative tab / inventory /
trade removal -- both layers complement each other.
Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>
Replace the v0.30.x ad-hoc disable mechanisms (KubeJS server script,
datapack recipe override, KubeJS client-side JEI hide -- which was
broken on this KubeJS build) with a single proper tool:
- **Item Obliterator 2.3.0** + dep **Necronomicon API 1.6.0**
Declarative JSON config to remove items from inventories,
creative tabs, all recipes (including modded custom recipe
types), villager trades, and JEI. Exactly the missing capability.
Config: pack/overrides/defaultconfigs/item_obliterator.json5
Blacklists:
alexsmobs:transmutation_table
alexsmobs:shattered_dimensional_carver
Removed (no longer needed):
- pack/overrides/kubejs/server_scripts/disable_alexsmobs_features.js
(Item Obliterator handles transmutation_table recipe removal
and right-click cancel automatically)
- pack/overrides/world/datapacks/bns-fuel/data/alexsmobs/
capsid_recipes/shattered_dimensional_carver.json
(Item Obliterator handles modded recipe removal too)
Both items now correctly:
- Don't appear in JEI search / item list
- Don't appear in creative tabs
- Have no working recipe path
- Can't be right-clicked / used
- Get scrubbed from inventories on join
The Void Worm boss + regular Dimensional Carver still work --
nothing else in Alex's Mobs is affected.
Verified live: both mods discovered, Necronomicon read our config
file successfully ("File exists, reading config"), Item Obliterator
loaded with the blacklist.
Note: config schema is v2; v1 configs get overwritten by the mod's
default. Always write configVersion: 2.
Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>
The hide_disabled_items.js client script I added in v0.30.3 used
`JEIEvents.hideItems(...)` -- a namespace that does NOT exist in
KubeJS 2101.7.2 on NeoForge 1.21.1. There is no kubejs-jei bridge
mod for 1.21.1 NeoForge published on Modrinth at this time.
Client launchers were showing:
KubeJS client script errors
hide_disabled_items.js#8
ReferenceError: \"JEIEvents\" is not defined.
Removing the script entirely. The Shattered Dimensional Carver
still:
- Cannot be produced (Capsid recipe override with barrier input)
- Does nothing on use (server-side right-click cancel)
Tradeoff: the item will still appear as a recipe-less entry in JEI
search if players type its name. Cosmetic only; no gameplay path
to obtain or use it.
If a JEI-hide approach becomes available in a future KubeJS update
or via a new bridge mod, we can revisit.
Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>
2026-06-01 19:15:19 +00:00
6 changed files with 382 additions and 45 deletions
\* Only if we keep emeralds; see §5 — we're moving villagers to spurs, which probably retires the Mint as a currency-conversion station and repurposes it as a wallet/info hub.
---
## 3. Spawn — themed guild buildings
Each guild is a destination. The guild's NPC is both the **entry point** (accept work) and **exit point** (return to claim reward). This pattern applies universally — see §4.
- **FTB Quests** = the *progression* backbone — chapter-by-chapter pack content, one-time rewards, story arcs. The campaign.
- **Spawn-building NPCs** (Easy NPC + KubeJS) = the *daily/repeatable* layer — bounties, sell shops, services. The live activities.
Both pay into the same wallet. Players run the campaign at their pace and the daily content for income/replay value. They reinforce each other rather than compete.
---
## 4. Quest & bounty flow (universal pattern)
**Core principle:** for any guild, the player **accepts** work from an NPC, **completes** it in the world, then **returns** to that NPC to **turn it in** and claim the reward. No instant payouts. This:
- Anchors guilds as destinations
- Creates risk/reward tension (die on the return, lose the reward)
- Encourages waypoint use and travel
- Lets the server centrally control payouts and detect cheating
### State machine
Each quest, per player, lives in one of these states:
```
AVAILABLE ─[player accepts]─► ACTIVE ─[objective met]─► READY ─[turned in]─► COMPLETED
- **AVAILABLE** — NPC offers the quest in dialog. Player has no current copy of it.
- **ACTIVE** — Player accepted. KubeJS tracks objective progress via relevant events (`EntityEvents.death` for kills, `ItemEvents.firstRightClicked` for explorations, etc.).
- **READY** — Objective met. Reward is *promised but not yet paid.* NPC dialog now offers a turn-in option.
- **COMPLETED** — Reward paid out. Quest goes on cooldown for this player.
- **AVAILABLE** (again) — after the cooldown, the NPC will offer it again.
3. KubeJS writes `quest:plunderer_10` to the player's quest state with `count: 0`.
4. Player kills Plunderers in the world. `EntityEvents.death` for `supplementaries:plunderer` increments the count.
5. At count=10, KubeJS flips state to **READY** and notifies the player ("Return to the Adventurer's Guild to claim your reward.").
6. Player returns. Right-click NPC. Easy NPC dialog detects READY state and offers "Turn in: Slay 10 Plunderers."
7. KubeJS pays 50 spurs into the player's Numismatics wallet, flips state to **COMPLETED**, sets cooldown to 24h.
### Universal applicability
The same accept → complete → return pattern works for every guild:
| Guild | Accept | Complete | Return |
|---|---|---|---|
| **Adventurer's** | "Hunt 10 plunderers" | kill them | NPC pays bounty |
| **Merchant's** | "Procure 32 diamonds for our buyer" | gather them | NPC pays inflated price + completes |
| **Civic** | "Survey 5 unclaimed chunks" | walk through them | NPC pays survey fee |
| **Library** | "Recover this lost tome" | find the book in a structure | NPC pays + grants reputation |
| **Foundry** | "Craft 10 Andesite Casings" | craft them | NPC pays commission |
### Player-facing tracking & cancellation
A quest engine that players can't inspect is worthless. The design ships with three layers of visibility:
#### V1 — command-driven (Phase 3, with the engine)
| Command | Effect |
|---|---|
| `/quests` | Lists all of your ACTIVE and READY quests with progress, source guild, and reward |
| `/quests info <id>` | Detail view for one quest — description, objective, progress, reward |
| `/quests cancel <id>` | Drops an active quest, freeing your slot. The quest goes on cooldown as if completed (prevents accept-cancel-accept RNG farming) |
Cheap to ship. Works on mobile via the Telegram bridge. Doesn't require any extra mods.
#### V2 — Quest Log book item (Phase 3.5)
Every new player joins with a **Quest Log** book in their inventory (KubeJS `PlayerEvents.loggedIn` grants it once). Right-click to open. Dynamic Patchouli-style pages list active/ready quests, with a "Cancel" button per quest. Same backend as the `/quests` commands — just a nicer surface.
#### V3 — Sidebar HUD (later)
Optional scoreboard sidebar showing 2-3 most recent quests + progress, always-on. Implemented via vanilla scoreboard objectives driven by KubeJS. Players can toggle on/off via `/quests sidebar`.
### Quest slot limit
Players have a **maximum of 3 active quests at a time.** This is the friction that makes cancel meaningful:
- Forces players to pick which quests they actually want — no "accept all 5, see what's easiest, cancel the rest" RNG-shopping.
- Keeps the state files small.
- Makes ready-to-turn-in queues meaningful (you can hold 3 unrewarded quests in your back pocket).
A quest moving to READY frees the slot for accepting a new one even before turn-in.
### KubeJS implementation sketch
- **State storage:** per-player JSON in `world/data/bns_quests/<uuid>.json`, written via KubeJS persistent-data hooks. Schema:
- **Event tracking:** standard KubeJS event handlers (`EntityEvents.death`, `ItemEvents.pickedUp`, `BlockEvents.broken`) read the player's active quests and increment.
- **Dialog branching:** Easy NPC dialog with conditions that call KubeJS to check quest state and route the dialog appropriately.
- **Reward delivery:** call Numismatics' wallet API to deposit spurs.
- **Commands:** registered via `ServerEvents.commandRegistry` in KubeJS, scoped to the player who runs them.
---
## 5. Villager rebalance
**Decision:** move all villagers to **spurs** (not emeralds). Thematic consistency over preserving vanilla mental model.
**Decision principles:**
- Villagers are **net money sinks** — players spend more on villagers than they earn from them.
- **Trash trades get deleted** — no one ever wanted to sell rotten flesh or buy paper.
- **Sell-to-villager trades exist but are bad** — `64 wheat → 1 spur`, `16 leather → 1 spur`. Farms still possible, but ~10× slower than any other income source.
### Price guidance (initial calibration — tune via playtesting)
#### Buy-from-villager (player pays spurs)
| Item | Tier-1 | Tier-3 | Tier-5 |
|---|---|---|---|
| Standard enchanted book (random) | 50 spurs | 120 spurs | 250 spurs |
| Mending book | — | — | 800 spurs |
| Diamond tool (unenchanted) | — | 80 spurs | — |
| Diamond tool (enchanted) | — | — | 350 spurs |
| Bookshelf | 15 spurs | — | — |
#### Sell-to-villager (player gets spurs)
| Item | Spurs per unit |
|---|---|
| Wheat | 1 per 64 |
| Paper | 1 per 32 |
| Leather | 1 per 16 |
| Iron ingot | 2 per 1 |
| Diamond | 8 per 1 *(matches sell-shop fixed price — players use whichever is closer)* |
### Scope
~60 trades × 5 profession tiers = ~300 trade entries to redesign. One-time data-design pass, implemented via `ServerEvents.villagerTrades` in KubeJS.
---
## 6. Money inflow sources (detailed)
| Source | Cap / DR mechanism | Rough rate |
|---|---|---|
| **Daily bounties** | Per-player per-quest cooldown (24h) | ~200-500 spurs/day for an active player |
| **Sell shop (fixed price + DR)** | Lifetime sales tracker per player, 10% price drop per 64 sold | ~50-200 spurs/hr while diamond stockpile lasts |
| **Dynamic exchange** | Global supply pool — price drops with sales | Self-balancing |
| **First-time milestones** | One-shot per player (`hasFlag`) | 5-50 spurs per milestone, ~10 milestones total |
| **FTB Quest progression** | One-time per quest | Varies; cluster rewards at chapter completion |
| **Villager sell trades** | Inherently slow + bad prices | ~50 spurs/hr from a serious villager farm |
---
## 7. Money outflow sinks (detailed)
| Sink | Cost curve | Why this scales right |
|---|---|---|
| **Plot claims** | Free up to 9 chunks. 50 spurs/chunk to 25. 200 spurs/chunk beyond. | New players claim free starter areas; ambitious players pay real money |
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
Matt
Matt