Productive Frogs

v1.2.0 - 2026-05-25 - cross-mod compatibility + observability

The V1.2 compatibility + tooling release. Resource Slimes now extend to the popular ATM10 mods' resources through common tags (no hard dependencies), a gated debug-logging framework lands across every layer, and the Slime Milk fluid collapses to a single component-driven block/bucket - completing the goal that a new Resource Slime variant is addable by datapack alone.

Added

• Cross-mod variant pools. 24 Resource Slime variants for the popular ATM10 mods, all condition-gated so they only appear when their provider mod is installed: AllTheOres metals (tin, lead, osmium, nickel, silver, zinc, aluminum, uranium), Create brass, Mekanism refined obsidian + fluorite, AE2 certus quartz / fluix / silicon, Mythic Metals orichalcum / mythril / aquarium, Powah blazing / niotic / spirited / nitro crystals, Industrial Foregoing pink slime, and Mystical Agriculture inferium / supremium essences. Each is a datapack JSON + a Froglight smelt recipe (no Java, no textures, no lang) generated by scripts/generate_cross_mod_variants.ps1. Thermal Series picks are deferred (it has no 1.21.1 release). Design: docs/cross_mod_compat.md.
• primer_tag on the slime_variant codec (alongside the now-optional primer_item). A variant can be primed by membership in a common tag (c:ingots/tin), so one cross-mod variant accepts any mod's matching item. Resolved at infusion time via SlimeVariant.findByPrimer; an exact primer_item match wins over a primer_tag match, and the codec rejects a variant declaring neither (it could never be primed).
• Observability framework (PFDebug). A gated debug-logging layer across 12 mod subsystems (lifecycle, registry, config, infusion, split, tongue, egg, sensor, milker, milk_source, render, tint). Off by default and near-zero cost when disabled; enable per-area at launch with -Dproductivefrogs.debug=<areas> or at runtime with the /pf debug <area> on command. Design: docs/observability.md.
• Single neutral Slime Milk texture set tinted per-variant at render (fluid via position-aware getTintColor reading the source BlockEntity; bucket via a 2-layer model + item color on the milk layer). One greyscale set serves every variant, including datapack-added ones.
• ResourceSlimeRenderer falls back to the category texture when a variant ships no <variant>_resource_slime.png, so a datapack variant renders cleanly (category cube + its primary_color shell) instead of a missing texture.
• Title-cased display-name fallback (VariantNames) on the Slime Milk bucket / Configurable Froglight / spawn egg, so a datapack variant needs no lang file.

Changed (breaking)

• Slime Milk collapsed to a single component-driven fluid/bucket/block. The ~35 per-variant Slime Milk registrations (one FluidType, Source + Flowing fluids, <variant>_slime_milk block, and <variant>_slime_milk_bucket item per variant) are replaced by one of each: a single slime_milk fluid, a slime_milk source block whose BlockEntity stores the variant, and a single slime_milk_bucket item carrying the variant in the SLIME_VARIANT data component (the same pattern as Configurable Froglight / Slime Bucket / the spawn egg). Migration: hard break - the per-variant *_slime_milk_bucket item IDs and *_slime_milk block/fluid IDs are gone; placed milk blocks and stashed milk buckets in existing worlds become orphaned refs (regenerate, per the project's pre-stable policy).
• Why: this is the last step of the data-driven variant refactor. A new Resource Slime variant is now addable by datapack alone - JSON, no Java, no recompile, no per-variant assets or lang. Per-variant fluids could never be datapack-added because fluids register at mod construction, before any world datapack loads. Design: docs/refactor_data_driven_variants.md.