Create Ore Excavation Deposits

0.2.0

A unification + compatibility release: one ownership model for every deposit, automatic adoption of third-party COE veins onto the map, input-fluid recipes, and a KubeJS binding.

Changed

• Base COE veins are disabled by default. This mod's managed deposits replace the role of the host mod's bundled veins (createoreexcavation:*) — letting both generate would duplicate every ore. They now start disabled: visible in the editor's vein list as (disabled — base COE default) with one-click Enable (writes the new enabled_veins config) or Edit → to promote one into a type you fully control. Veins from add-ons/datapacks keep auto-adopting — those were added intentionally, not as a dependency side-effect. Master switch: coe_veins_disabled_by_default (default on, also in the Generation config group).
• Unified deposit model — one owner, two generation variants. Every deposit coedeposits tracks is now owned by us identically: we write its OreData, persist it, prospect-scan it, render it, and find it. placement is no longer "who owns it" but only where it's placed — managed (our multi-chunk Perlin blob) or coe (Create Ore Excavation's own spread). This collapses the old dual-ownership split that caused COE-placement deposits to behave inconsistently (depletion/regenerate/finder edge cases).
• COE-placement veins are now prospect-scanned and findable. Declared placement: coe types (and adopted ones, below) are pre-populated on the world map ahead of the player and restored by /coedeposits regenerate, exactly like managed deposits — no more having to stand almost on top of a COE vein for it to appear. The picker faithfully replays COE's own spread placement (priority order, structure-chunk match, jittered biome whitelist/blacklist) off-thread.

Added

• Auto-adopt foreign COE veins (compat). Any COE vein recipe that has no coedeposits deposit_type of its own — e.g. from Create Ore Excavation Plus, the CoE × Mekanism datapack, OreCompatCreate, or any datapack — is adopted onto the world map under an implicit type: we take ownership of its OreData, track it, render it and find it like a declared deposit. Toggle with the new auto_adopt_coe_veins config (default on). Tooltip names for adopted veins are made readable (createoreexcavation:ore_vein_type/redstone → "Redstone"). The in-game editor's Deposits tab lists adoptable veins, each with Edit → (promote to a placement: coe type you fully control — map colour, reveal, biome filter…) and Disable (suppress the vein entirely — it stops generating, stored in the new disabled_veins config). /coedeposits types shows declared vs adopted with placed counts.

• Input / coolant fluid on recipes (like the host mod). Inline drilling: and fluid: blocks accept an optional fluid_input ({fluid|tag, amount}) — the fluid the machine consumes per cycle (COE's drillingFluid, recipe key "fluid"). Lets you express fluid-gated recipes such as the CoE × Mekanism datapack's Brine / Sulfuric-Acid drilling bonuses, or a coolant requirement. Editable in the in-game editor (both the Drilling and Fluid groups).

• KubeJS support — deposit types. With KubeJS installed, define deposit types from kubejs/startup_scripts via the CoeDeposits binding: CoeDeposits.add('mypack:ruby', { vein_recipes:[...], weight:80, distance:{min:2000,max:99999}, ... }). The object is the standard deposit_type schema; scripted types merge between the datapack defaults and the deposits.json overlay. KubeJS is an optional dependency — the mod runs fine without it. (COE's own vein/drilling/extracting recipes remain scriptable through COE's KubeJS plugin.)

• The bundled water deposit is renamed coedeposits:example_water → coedeposits:water (its synthesised recipes likewise example_water_vein/extracting → water_vein/extracting). Existing worlds with placed example_water deposits will drop them on upgrade — re-run /coedeposits regenerate if you want the renamed one back.

• auto_adopt_coe_veins is now in the in-game config (Generation group), next to the new "Disable base COE veins" toggle — previously only editable in the toml.

Fixed

• A chunk whose vein recipe is set but unresolvable now reads "vein recipe not loaded" on the map tooltip instead of a misleading "depleted" (the underlying never-applied-OreData self-heal shipped in 0.1.7).
• Editor: an input fluid (fluid_input) set on a drilling/extracting block now persists even when the block has no other content yet — picking the fluid marks its block active, so it's written to deposits.json instead of being dropped on save.
• Editor: picking a fluid no longer bounces you back to the Core tab — the editor reopens on the Inline-recipe tab you were on.

Notes

• Upgrading from 0.1.x: base-COE veins switch off on upgrade (coe_veins_disabled_by_default arrives as true). Veins already placed in your world stay tracked and minable — only new placements stop; run /coedeposits regenerate for a clean slate, or flip the config / enabled_veins to keep them spawning.
• Auto-adopt and the unified model are most predictable on fresh chunks. Foreign COE veins already generated in old chunks (before this version) appear once their chunk loads (the self-heal applies them within ~1s) or after a re-prospect.