Register the damage-indicated fluid container handler at the lowest priority

[rubensworks]

Replaces CyclopsMC/EvilCraft#1269, #1270 and #1271, which patched this at the EvilCraft end. Fixing it here is cleaner and covers every subclass in every dependent mod at once.

The bug

DamageIndicatedItemFluidContainer registers a generic FluidHandlerItemCapacity for every subclass, from its constructor, on CyclopsCore's mod bus. When the subclass' own mod registers a more specific handler for the same item, that item has two competing providers.

ItemCapability#getCapability returns the first registered non-null provider. RegisterCapabilitiesEvent goes through ModLoader.postEventWrapContainerInModOrder, and postEventWithWrapInModOrder loops over EventPriority.values() on the outside and ModList.forEachModInOrder on the inside. So at equal priority the winner is decided purely by mod load order.

That order is not stable. A dependency declared with ordering="NONE" creates no edge in ModSorter's graph, so the two mods are ordered by TopologicalSort's tie-break, which is a PriorityQueue keyed on each mod's index in the discovery order. Add or remove unrelated mods and the order can flip.

How it showed up

EvilCraft's creative blood drop registers an infinite handler from ItemCreativeBloodDropConfig, and EvilCraft declares ordering="NONE" for cyclopscore. When cyclopscore won the race, a fresh creative blood drop resolved to the generic finite handler, which on a fresh stack contains nothing — the item silently became useless.

In CI it surfaced as testBloodInfuserEmptyFluidContainerCreativeBloodDrop failing in the cyclops-all-deps pack test only, and only on 26.1.2:

Expected Blood infuser tank contents to be 10000: was 0 on tick 202

EmptyFluidContainerInTankTickAction#canTick saw an empty container and returned false on every tick, so the drain never ran once. Hence was 0 rather than a partial amount. It was never a timeout: the drain moves 100 mB/tick and needs 100 of the 200 available ticks.

The change

The handler registered here is a fallback, so it registers at EventPriority.LOWEST. Any subclass registration, at any higher priority (including the default NORMAL), is therefore always considered first, whatever the mod load order. Subclasses that register nothing of their own are unaffected — the fallback is still the only provider.

Verification

Built CyclopsCore with and without this change, published each to mavenLocal, and ran EvilCraft master-26-lts unmodified against both. To pin the mod ordering deterministically (rather than relying on whichever order this machine happens to produce), EvilCraft's own registration was temporarily moved to EventPriority.LOW — reproducing exactly the "cyclopscore is considered first" condition:

CyclopsCore	EvilCraft game tests
stock (NORMAL)	Expected Blood infuser tank contents to be 10000: was 0 on tick 202 — the CI failure, byte for byte
this branch (LOWEST)	95/95 passed

The one-line priority change is the only variable between those two runs.

CyclopsCore's own ./gradlew build, test and runGameTestServer all pass, spotlessApply applied.

Note on a regression test

I did not add one here: CyclopsCore has no DamageIndicatedItemFluidContainer subclass of its own and no game-test content items, so covering this would mean inventing a test item plus a competing registration purely for the test — more machinery than the fix. The EvilCraft PRs carried a GameTestsItemCreativeBloodDrop that asserts the creative blood drop's fluid handler directly and fails in one legible line; happy to re-propose that against EvilCraft separately if you want the guard.

Downstream

EvilCraft needs no change once this is released, beyond the usual cyclopscore_version bump. The packtests Build (server, cyclops-all-deps, 26.1.2, neoforge) job goes green once it picks up a CyclopsCore build carrying this.

---

Generated by Claude Code

[coveralls]

coverage: 31.187%. remained the same — claude/damage-indicated-fluid-container-capability-priority into master-26-lts

[sonarqubecloud]

Quality Gate passed

Issues
0 New issues
0 Accepted issues

Measures
0 Security Hotspots
0.0% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube Cloud