Forged products are now uniformly constructed through the EmakiItemAssemblyService, no longer relying solely on the legacy process of directly modifying ItemMeta.
Recipe results, material entries, and quality entries are compiled into assembly-layer snapshots and written into the final product.
result.meta_actions now supports name modification and Lore modification, making it easier to define product display rules directly at the recipe level.
Added forging-layer audit data, recording recipe ID, quality, material signature, forging time, and output source.
Assembly Feedback and Lore Search Hints
Added ForgeAssemblyFeedbackHandler, which synchronously reports Lore search-and-insert failures, regex errors, and configuration errors to the console.
Players will also receive direct prompts during actual forging if they encounter invalid Lore search configurations.
Asynchronous Caching and Persistence
Added PlayerDataCache; player forging history and pity counters are now managed by a concurrency-safe cache.
PlayerDataStore is now integrated into the CoreLib asynchronous YAML saving pipeline.
Automatic saves, player-offline saves, and plugin-shutdown saves will all wait for pending write tasks to complete, reducing the risk of historical data loss.
ForgeService added a pre-forge cache and prepareForgeAsync(...) to reduce redundant calculation overhead.
Changed GUI and Recipe Experience
The default forging GUI no longer displays random product previews, preventing repeated刷取 of random quality and entry results through previews.
The default target item slot has been changed to a "result hidden" placeholder description, with interface text updated accordingly.
The recipe book now uniformly uses configuredOutputSource() to parse the result source when displaying result items.
Recipes and Validation Logic
Recipe added configuredOutputSource() and requiresTargetInput() for unified output source determination.
MaterialValidationService rewritten the material normalization and validation logic to prevent disguising required materials and塞入 optional slots.
RecipeMatchingService optimized error priority; when a recipe fails to match, a more reasonable first failure reason is now given.
Blueprint capacity, material capacity bonuses, and optional material whitelist/blacklist are now uniformly结算 within the same validation process.
Example Resource Updates
Default blueprint and material examples have been switched from external item IDs to vanilla items, lowering the barrier to entry for running out-of-the-box.
Example blueprints added forge_capacity, making capacity sources more intuitive.
Example recipe flame_sword.yml changed to use vanilla diamond_sword as base material, any_of blueprint requirements, whitelist-style optional materials, and the result.meta_actions写法.
YAML indentation examples for quality broadcast actions have been corrected.
Upgrade Notes
Requires EmakiCoreLib 2.0.0 or higher.
If you use custom recipes, it is recommended to explicitly declare the result source:
When there is a fixed product base material, use target_item.item or result.output_item.
When name/Lore modifications are needed, prioritize writing them in result.meta_actions.
The default GUI intentionally hides result previews; if your old workflow relied on the "preview first, then confirm" interaction, you need to evaluate whether to keep the old template.
If you still use the old forging process of "player places target item for processing", please key inspection the target slot interaction and custom GUI templates before upgrading.
Known Issues
Random results do not provide product previews in the default template; this is a design trade-off, not a rendering fault.