VitalProbe

In one line: a health-manipulation engine. It disassembles a mob's bytecode at runtime, reverse-engineers the dataflow behind getHealth(), finds where the health value actually lives, writes to it, then verifies by reading it back.

• Minecraft 1.20.1 · Forge 47.4.x
• modid vitalprobe (bccore is kept as a command alias)
• Dependencies none beyond Forge; everything else is soft-compatible
• Author ByteChen · License MIT

The problem it solves

"Set that mob's health to 20" is entity.setHealth(20) in vanilla. The moment another mod wants to stop you, that path is blocked in a dozen different ways:

VitalProbe exists for exactly these cases. It never guesses member names and never hardcodes a target mod's classes or fields — it works by runtime disassembly plus measured read-back verification.

The strategy chain

Every write tries these in order. Each step is judged by reading getHealth() back afterwards; on failure it falls through to the next:

1. ANALYZED — symbolic inversion: abstract-interpret the getHealth() expression into an equation in T and solve for the value to write.
2. MAP_SWEEP — no inversion: walk the classes referenced by that expression, find the Map holding this entity, match the value and rewrite it.
3. ENCODED_PROBE — differential probing: when health is a string, write character by character and read back, measuring the encoding instead of decoding it.
4. SET_HEALTH — vanilla setHealth, after first checking whether its semantics really are "set" (an additive/heal-only override is skipped).
5. RECODE — rebuild a legal value by the container's own rules (take an existing valid value as a template, replace only the field that encodes health; the checksum is computed by the mod's own function).
6. MUTATOR — borrow the mod's own writer primitive (auto-detects delta vs absolute semantics, measured per candidate).
7. PROVIDER — borrow the mod's "health provider": confirm it is the health source by calling it with zero arguments, mine the command token out of its own bytecode (e.g. internal), then write through its own hand.
8. FIELD_SCAN — generic field scan, including inverted forms such as maxHealth - health.
9. MAX_HEALTH — when health is pinned to the cap, lower the max health instead.

Push-backs are handled separately: pulled back to the original value → limited rewrites; pulled back to a third value (the signature of a per-tick invariant) → a sustained-pressure window that walks the reading to the target at the other side's own rate, and counts as success once it holds stable for several ticks.

Strength (config)

general.strength, defaulting to UNSAFE (maximum):

If a write fails, allowEscalation promotes the level automatically.

Void Sword (optional integration)

Hold hall:void_sword from RottenRuins:The Hall and right-click to set every living entity within 100 blocks to getHealth() - 20:

• sneak + scroll wheel adjusts the amount (step 10, absolute cap 1000);
• at zero health a finishing blow is applied so loot, death events and boss bars behave normally;
• item id list, radius, delta, whether players/yourself are affected, and cooldown are all configurable;
• no dependency on that mod: not a single line has to change on the item side, and it works fine without it.

Commands

All require OP level 2. /bccore is an equivalent alias of /vitalprobe.

API for mod authors

// Soft dependency: call reflectively and degrade gracefully when VitalProbe is absent
org.bytechen.bccore.api.BCHealth.get(LivingEntity);                    // read effective health
org.bytechen.bccore.api.BCHealth.set(LivingEntity, float);             // exact write (no 0 clamp)
org.bytechen.bccore.api.BCHealth.add(LivingEntity, float);             // add/subtract
org.bytechen.bccore.api.BCHealth.triggerVoidSword(Player, ItemStack);  // one area-wide pass

Resolve it behind ModList.get().isLoaded("vitalprobe") and wrap the whole chain in try/catch.

Known limits (stated honestly)

• Compile-time inlined constants cannot be changed: if the number inside getHealth() was inlined at compile time, there is no writable location at runtime.
• Borrowed primitives are as strong as the target allows: if the mod's own writer has i-frames or a per-hit cap, the result is reported as a partial success (never a fake "success"), and you either hit it repeatedly or let RECODE place the value in one shot.
• In the extreme combination of reflection filtered out and instance method handles unavailable, some targets genuinely have no reachable write location; the log then prints exactly which step failed (holders, reflection-vs-bytecode member comparison, candidate primitives) so it can be diagnosed.
• VitalProbe only touches effective health (the return value of getHealth()). It does not alter armor, resistances or attribute caps unless the MAX_HEALTH step is reached.

Compatibility & performance

• Purely runtime, on-demand disassembly: no load-time transformer, so it doesn't fight other CoreMods over classes.
• Reversal results are cached per class; work happens only on right-click / command / detected reverts, with no idle tick cost.
• Install on both client and server; the write logic runs server-side.

Installation

Drop it into mods/. Config: config/vitalprobe-common.toml.

License MIT. Use it, change it, redistribute it. If something breaks, attach the lines containing [VitalProbe] from logs/latest.log.