YUNG's API and MoogsStructureLib add their own kernel to the Beardifier:
a size and falloff of its own, carving or burying above and below a piece's
floor, around rigid pieces and junctions. Better Strongholds buries its
stronghold, Better Fortresses carves the netherrack over its bridges and
Moog's mega fortress carves a band around its corridors. A structure or a
pool element holding `horizon:enhanced_terrain_adaptation` now gets that
kernel (horizon_core's TerrainKernel), summed after vanilla's density as
the libraries' mixins do; YUNG's also grows the start's box by its radius.
Vanilla data never has the key, so vanilla worlds are unchanged.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
A content mod's structure set or template pool file holding
"horizon:add_to" appends its entries to the sets or pools it names
(vanilla's, another mod's) instead of being one of its own, as
lithostitched's add_structure_set_entries and add_template_pool_elements
modifiers do on NeoForge and Fabric. The content root merges them after
every mod's own files, in mod and file order; a name nobody defines is
skipped. Vanilla data never has the key.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Loading seven real NeoForge mods carried over by horizon-port-pack (about
1,000 blocks) broke the content root in four places:
- The per-state NBT tables (cached collision, occlusion, movement, worldgen
block properties and support) passed the NBT reader's 1M-node cap once
mod states were appended. They are trusted prepared tables with a row
per state, so they now read and write with Limits::tables() (16M nodes,
256 MiB) everywhere they are loaded.
- The overlay linked the base root by the path it was given, so a relative
base gave dangling links. The base is made absolute first.
- Carried-over tags name blocks the port left out and other mods' items.
Vanilla fails such a tag as a whole; entries naming ids nobody registers
(or tags nobody defines) are now dropped, so the rest loads.
- Mods use the convention tags (c:dyes/red, c:glass_blocks/colorless).
Content mods may add to data/c/tags/ as to vanilla's, and with content
mods loaded the tag loaders read the c namespace and the mods' own.
Stonecutter and smithing recipes in mod namespaces load too (ids
<ns>:<name>), as crafting and cooking ones already did. With no content
mod nothing changes: the loaders read the minecraft namespace only.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
A .hmod may carry assets/ and data/ beside mod.wasm, or instead of it. The
manifest needs api = "0.2" and the new registries capability ("add blocks
and items to your worlds"). Content mods have no WIT interface: code still
links API 0.1.
horizon_mods::content::Content reads a mod's content and checks it:
- plain resource paths only;
- 65,536 files, 16 MiB each, 512 MiB in all;
- files in the mod's own namespace, plus additions to vanilla tags;
- blocks and items declared in data/<id>/horizon/{block,item}/*.json, each
copying a vanilla template with typed overrides (hardness, resistance,
light, tool, friction, map colour, sounds; stack size, rarity), unknown
keys refused.
Mods::load refuses an enabled mod whose content fails these checks, with
the reason on its row. A content-only mod is on with no engine and no hooks.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
docs/modpacks.md: how any pack (ATM10 down to small Fabric packs) gets to
Horizon: import (.mrpack, CurseForge zip or instance, Prism, packwiz),
inventory and classification, dependency order, mechanical carry-over of
data and assets, one agent per mod for code with a per-mod harness against
a dev-only NeoForge/Fabric oracle, and a coverage report. Also the mod API
gaps against 0.1, the registries 0.2 design (template blocks through the
overlay root), licence handling, how "10x" is measured against NeoForge,
and the scope for 2026-10-23.
docs/modpacks/atm10-mods.csv: ATM10's 495 jars from the pack's own
crash_assistant modlist (2026-10-15), with Modrinth metadata looked up by
hash: class, API tier, licence, sides. Metadata only.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
A mod's commands ran but the chat box parsed against vanilla's tree only,
so `/coords` showed red as unknown and never completed. The game now keeps
the chat's tree as vanilla's plus a literal per running mod's command (every
permission level, optional greedy `args`), rebuilt when mods start, reload
or stop.
Fixes#456
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
docs/mods.md: the sandboxed WebAssembly runtime, capabilities, hooks, budgets,
authoring, versions, multiplayer and distribution, with measured hook costs.
docs/research/java-mod-compat.md: why Fabric/NeoForge jars cannot run, data
import, which mods to port natively first, a porting guide outline.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Ludovic Marie