Kaledelights Compat

1.3.8 — Server-side Config Sync

Fixed

• On a dedicated server, turning off item deletion left the affected items existing but uncraftable, with their recipes missing (user report, 2026-10-19). Root cause: AllowItemDeletion, the blacklist and disabled rule groups were applied from the local config on each side, while OEI keeps a separate replacement cache on the client and on the server. Changing only the server left the two sides inconsistent — the server kept the items while the client still replaced them. The server now sends its effective criteria to the client on login (and again after a server-side /reload), and the client re-aligns its OEI cache accordingly. Singleplayer sends nothing and behaves exactly as before.
• Clients no longer get rejected when joining a server without this mod (the channel accepts a missing counterpart).

Changed

• New network channel kaledelights_compat:config_sync (server → client, a single message).
• The client restores its local config after disconnecting from a server.

Hotfix (2026-10-19, same version 1.3.8)

🔙 Rolled back (2026-10-19, later): the "follow-up recipe reload" changes below (after /reload, after world load, and the on-demand variant) were rolled back entirely — the author judged the extra reload cost too high (an additional data-pack/recipe reload on server start and /reload, plus a client-side JEI reload). The current 1.3.8 keeps only the server-side config sync and the client recipe resync (with the broken-recipe filter). As a result, "recipes missing after joining, before /reload" is no longer auto-fixed; a manual /reload is required.

• Client recipe resync: after receiving the server's criteria, the client now asks the server to re-send the recipe list. This overrides the case where a client-side resource reload (Reloading ResourceManager) re-loads recipes from the local config and breaks recipes that use a deleted item as an ingredient — e.g. Eternal Steak (artifacts:eternal_steak) has recipes on the server but not on the client, because all three of its recipes use artifacts:everlasting_beef, which is in the deletion group.
• Follow-up recipe reload after /reload: OEI rebuilds its replacement cache after recipes are parsed, so a reload can leave recipes with minecraft:air ingredients (the client then throws ItemStack value must not be empty, and those recipes go missing). The server now reloads recipes once more ~2 seconds after /reload (when the cache is updated) and filters air-containing recipes out before re-sending them.
• Same fix for world load: world loading (startup / reloading a world) parses recipes in the same order, so it could also leave broken recipes and the client would see missing recipes before any /reload. A follow-up reload is now triggered after ServerStartedEvent as well (only when deletion rules are present), so recipes are correct before players join.
• Reload only when needed (no extra stutter): before the follow-up reload, the server scans its RecipeManager; it only reloads if a broken recipe actually exists (empty result or an air ingredient). When recipes are fine, the check is skipped and no extra stutter happens on startup or /reload.

Known limitation (multiplayer)

• If recipes still fail to show after joining a world (dedicated server / LAN), run /reload once — they will re-sync and appear. The automatic follow-up reload was rolled back to avoid the extra stutter, so this one manual step may be needed in that case.