Kaledelights Compat

1.3.6 — Banana Roll Rework · Radgill Roll · Tag & Model Fixes

Added

• Banana sushi roll fully reworked (alexsmobsdelight:banana_roll): brand-new finished-roll model (based on the rainbow futomaki layout, centre blocks in chocolate brown), new ingredient models for banana / chocolate / cut pitaya / apple, and an ordered recipe that reads exactly banana peel → rice → rice → banana → chocolate → banana → cut pitaya → roll up.
• Banana peel as the roll's outer skin: the cuisine table's first step has always been a hard-coded singleton (dried kelp → nori model). A dedicated parallel chain was built for banana peel, with its own base id banana_peel_roll and its own open-roll models, so the skin stays banana-yellow from the first step all the way to the finished roll. Dried kelp and every other roll are untouched.
• Second banana-roll recipe using cocoa beans (minecraft:cocoa_beans + minecraft:apple) that works without Paster Dream / Nether's Exoticism. Cocoa and chocolate share one model.
• Radgill roll (cavedelight:radgill_roll) now has a recipe — rice base → roll up → radgill slice — plus a new topping texture that copies the salmon sushi layout pixel-for-pixel and recolours it to the radgill slice palette.
• Pitcher-plant sushi with its own rice base and a purple topping derived from the pitcher-plant texture.
• Dedicated rice bases for sakura / himekaido / pitcher-plant sushi.

Changed

• Four sushi now yield 2 instead of uneven amounts: cavedelight:trilocaris_roll (1 → 2), immortalers_delight:kwat_pocket_sushi (1 → 2), culturaldelights:egg_roll (4 → 2), immortalers_delight:hamburger_meat_sushi (1 → 2).
• Pitcher-plant topping tone softened (less saturated, shifted bluer) after feedback.
• Cocoa-bean ingredient modelling removed — chocolate and cocoa beans now share one model.

Fixed

• A whole tag could silently fail to load. carryon:block_blacklist referenced youkaishomecoming:* while only youkaisfeasts was installed; Forge drops an entire tag when one required entry cannot be resolved, so block-carry protection was effectively absent. All 268 entries are now per-entry "required": false.
• Dedicated rice bases never took effect. The model id was being built the wrong way, so the swap silently no-op'd for every sakura / himekaido / pitcher-plant sushi. The base is now replaced by position, independent of id spelling.
• Banana peel was being eaten by the ingredient slot. IngredientTableItem.find recurses into child steps before checking itself, so a peel registered as both skin and topping was always captured by the topping slot. Banana peel is no longer an ingredient, and the skin step is intercepted at the table root instead.
• Open-roll models pointed at the shared nori texture, so the skin turned back into seaweed once rice was added. The chain now uses its own banana_peel_open_* models.

Config / diagnostics

• Config values that actually take effect are printed in the log, in both English and Chinese ([Config] / [配置]), and section/key names are matched case-insensitively.

Fixed (2026-10-16)

• AllowItemDeletion = false is now genuinely honoured — single-player and dedicated servers. Reported by a user: with deletion switched off the items were still turned into air; in single-player the items only came back after a manual /reload on every world load; and on a server the setting did nothing at all. Two root causes. (1) Our "remove the rule" step ran after the fact (one server tick later), while OneEnoughItem rebuilds its cache from scratch — clearCache() + putReplacement() — on both server start and every data reload, so the rule we had just removed came straight back. (2) During a resource reload matchItem reads a reload-override map that takes exclusive precedence, so the read-back verification used to confirm a removal always saw air, concluded "still there", and gave up after 3 retries — which is exactly why only a /reload seemed to help. Pruning now happens at the entry point (a Mixin on OneEnoughItem's ItemReplacementCache.putReplacement / beginReloadOverride), so a disabled rule never reaches the cache in the first place: timing-independent, no /reload needed, and identical behaviour in single-player, on servers, in new and in existing worlds. Blacklist entries and disabled rule groups go through the same path. Only the rules this mod produces are affected — rules from other mods' or a pack's own datapacks are left completely alone.
• Custom unification mappings now land on dedicated servers. They were only written to saves/<world>/datapacks/, but a server keeps its world under <gameDir>/<level-name>/, so they never applied there. The world-level datapack is now also written next to level-name (read from server.properties).
• The two log lines that printed the deletion switch inverted (true shown as "blocked") are fixed — true now reads as 允许 / ALLOWED.

Removed (2026-10-16)

• Millstone oil extraction is retired — right-clicking a millstone with a glass bottle to draw rusticdelight:cooking_oil no longer exists. Disassembling Kaleidoscope Cookery 1.2.0 and 1.6.0 side by side shows the millstone has always ejected its output onto the ground (tick() → addFreshEntity, output slot cleared immediately afterwards); the oil never stays inside long enough to be collected from the block, in either version. The old handler was also reading the wrong item (it expected oil_pot while both versions output kaleidoscope_cookery:oil) and used the 1.2.0-only getOutput() API, so it had effectively been dead for a while. Oil works the vanilla way: grind seeds → pick the oil up → right-click an oil can with it → draw cooking oil from the oil can with a glass bottle.

说明：原 1.3.5 / 1.3.6 / 1.3.7 / 1.3.8 的内容已全部并入本段， 从未作为独立版本发布。

1.3.4 — Config Tolerance & Diagnostics

Fixed

• Fixed: setting AllowItemDeletion=false could still delete items (reported by a user). Root cause: the unify.omniconf parser matched section names and keys exactly (case-sensitive). A typo silently fell back to the default true (= deletion allowed), and the effective value was never logged, so there was no way to notice. Measured against the real parser with 11 variations: 6 were silently ignored — a lowercase key B:allowItemDeletion (the key name used by the old 1.3.0 unify.json, so it is the most common case after upgrading), a section header without quotes, an extra space in the section name, a key written outside any section, a key in the wrong section, and a key after the previous section was already closed. Section names and keys are now matched case-insensitively, section headers may omit the quotes, and runs of spaces are collapsed — the lowercase-key, missing-quotes and extra-space variants now work instead of failing silently.

Added

• The effective values are now logged: [配置] 已加载 ...（砧板启用=X · 物品删除=Y） and ... 物品删除=Y in the unify.omniconf read line — so it is immediately clear whether a setting was not read or read but not in effect.
• Config logs are now bilingual: every config message is logged twice - an English [Config] line followed by a Chinese [配置] line (34 call sites converted, none left Chinese-only). This mod ships to both an English (CurseForge) and a Chinese (mcmod.cn) audience, and a diagnostic that only exists in Chinese is no help to an English-speaking reporter - which is exactly the situation that made this bug hard to spot.
• Misplaced settings now warn instead of vanishing:
  • [配置] ... 里有 N 行写在任何节之外，已忽略（多半是放错位置）：[...]
  • [配置] ... 的 "Item Deletion" 节里没有 AllowItemDeletion（键名忽略大小写）—— 取默认值 true。该节现有键 = [...]
  • [配置] ... 里没有 "Item Deletion" 节 —— 物品删除开关取默认值 true（允许删除）
  • [配置] ... 里有节头没写引号（本次已按节处理，建议补成 "节名" {）：[...]