ChimericLib

26.2 - 6.1.0

New Features

• commands/ChimericCommand, commands/ChimericCommands — a small per-mod command-registration framework: implement ChimericCommand#build to return a command tree, then call ChimericCommands.register(...) during your mod's init. Wraps Architectury's CommandRegistrationEvent so consuming mods don't need to touch it directly, and multiple commands that share a root literal (e.g. several features all registering under chimericlib) merge together automatically via Brigadier's own node-merging.
• commands/blockstate/BlockStateCommand — /chimericlib blockstate get|set|modify <pos> (requires permission level 2). get mirrors vanilla's /data get block; set mirrors /setblock, replacing the block via BlockStateArgument/BlockInput; modify is new — it merges only the given properties (e.g. [facing=east]) onto whatever block is already there, via the new commands/blockstate/BlockPropertiesArgument.
• commands/PlatformCommandArgumentTypes — the platform hook a custom Brigadier ArgumentType needs to sync to the client (vanilla's own reverse class-to-info lookup used for that sync is private and only self-populated for its built-ins). Fabric and NeoForge each get their own Provider implementation; register a custom argument type through PlatformCommandArgumentTypes.registerByClass(...).
• blocks/model/ModelUtils — vanilla-block-shaped datagen helpers generalized out of Minekea: registerBlockWithAxis/registerBlockWithWallSide/registerBlockWithHorizontalFacing/ registerBlockWithFacing (rotation dispatch for pillar/wall-mounted/facing block shapes), registerLanternBlock, registerCrop (vanilla age-property crop dispatch), registerGeneratedItem, and makeInvalidVariant (bedrock-textured placeholder for illegal blockstate combinations).
• blocks/model/CustomBlockModel — a ModelTemplate that also emits a render_type field (vanilla's own template has no render-type support); CustomCropModel is the cutout-rendered crop preset built on it.
• blocks/RecipeUtils#unlockedByHas — the .unlockedBy(RecipeProvider.getHasName(x), generator.has(x)) idiom as a one-line wrapper around any RecipeBuilder.
• fabric/blocks/TranslationUtils#addBlockAndItem — the block+item translation-pair idiom in one call.
• fabric/blocks/TagUtils#applyMineableTag — the tool-tag-application idiom (with a Tool/default-tool overload), now also used by the family generators below to remove their own copy of it.
• fabric/data/TextureGenerator, fabric/data/JarAccess — programmatic PNG datagen and safe vanilla-jar asset reading, generalized out of Minekea. TextureGenerator now takes the consuming mod's ID so its <modId>.datagen.resource-path environment variable and assets/<modId>/textures base path are mod-specific rather than hardcoded.
• chimeric-lib now ships its own access widener (chimericlib.accesswidener) — needed for CustomBlockModel's use of ModelTemplate's internals. Previously commented-out scaffolding in both common/build.gradle and fabric/build.gradle is now active.
• blocks/family/BlockFamily — declare a base block's BlockConfig once and register whichever of its stairs/slab/wall variants you need, each with a derived BlockConfig (ingredient set to the base block; materialName/texture/tool/flammable/translucent/renderType inherited unless overridden). Vanilla StairBlock/SlabBlock/WallBlock are used by default; a per-variant factory override lets a mod substitute its own subclass.
• fabric/blocks/family/StairsBlockDataGenerator, SlabBlockDataGenerator, WallBlockDataGenerator — recipes, mineable/#walls tags, loot tables, blockstate/item models, and translations for each family variant. BlockFamilyDataGenerators.of(family) wraps whichever variants a BlockFamily registered into the matching generators, ready to fold into a mod's own datagen aggregator.

Changes

• blocks/BlockDataGenerator#configureRecipes now takes a RecipeProvider parameter, and #configureBlockLootTables now takes a HolderLookup.Provider parameter. Not breaking in practice — nothing in this suite implemented the old signature.