Neo Origins

Two new tools for pack authors, a pass over the ocean origins, and a fix for a bug that quietly undid part of your origin. neoorigins:ignore_fluid generalises ignore_water into a power that removes a fluid from the player's world outright: no buoyancy, no drag, no current push, no drowning, no lava burn, no fog, no swim pose, for modded fluids as much as vanilla ones. It gets there by intercepting fluid detection rather than each effect in turn, which is why third-party mods fall away with it. neoorigins:suppression is the first status effect NeoOrigins has ever registered: a ready-made ability lock to hang a boss mechanic, a debuff zone, or a PvP counter on. And size powers now stack across the origin and class layers, where picking a class used to wipe the origin layer's size instead of adding to it, so a Golem who took Titan stood at 1.25 rather than 1.55.

The aquatic origins get the pass they have been owed. Two vanilla rules were quietly undoing their signature abilities the moment they left the seafloor, so they swam and mined at their best while standing on a block and worst while genuinely swimming, which is the wrong way round. Both are corrected. Merling can see in the dark from tier 0 rather than tier 2, Siren's Beached penalty stops following her into the water, and the night vision key no longer claims success on the forty-nine built-in origins that have no night vision to toggle. Alongside them, breath_out_of_fluid honours the drain rate you author, which it had been parsing and then discarding for every custom origin that set one.

Supports: Minecraft 26.1.x (Java 25) · Minecraft 26.2 (Java 25) · Minecraft 1.21.1 (Java 21)

• neoorigins:ignore_fluid makes a fluid stop existing for the player. ignore_water removes water's speed penalty and its current pushing, and nothing else: you still float, still drown, still see the blue. The new power removes the fluid entirely. No buoyancy, no drag, no current push, no drowning, no lava burn, no fog or screen overlay, no swim pose. It works by intercepting fluid detection rather than cancelling each behaviour one at a time: the body scan that feeds buoyancy, drag, isInWater(), isInLava() and the swim pose hands back an empty fluid state for an ignored fluid, as does the eye scan behind drowning and the air bar, the camera query behind fog and the underwater distortion, and the block's own entityInside, which is how modded fluids deliver their damage. Because every vanilla fluid behaviour reads those same values, they all fall away together, and so do most third-party mods, since they ask the same standard questions. ignore_water is unchanged and still supported: reach for it when you only want the movement penalty gone, and for this when you want the fluid to stop registering at all.

• Naming a fluid covers its whole type, and a bad id costs you nothing. fluid takes a fluid id ("minecraft:lava"), a fluid tag ("#c:milk"), or an array of either; fluids is the plural spelling, and both keys are read and merged, so it does not matter which one you reach for. An entry without a namespace gets minecraft:. Naming any fluid of a type ignores the type, so "minecraft:water" also covers minecraft:flowing_water, which is what makes poured buckets work. If you give neither key the power defaults to water and lava, so a marker-only entry is never a silent no-op. An unknown or misspelled id is dropped quietly rather than failing the datapack load, which matters because the whole point is naming fluids from mods that may not be installed: parsing never touches the fluid registry, so an id for an absent mod cannot throw at load or during login sync. See POWER_TYPES.md for the field reference and worked examples.

• What ignore_fluid deliberately does not reach. Fluid rendering is untouched: the fluid still draws normally, you simply pass through it as if it were air. A mod that runs its own level.getFluidState(pos) check per tick, rather than asking the entity whether it is in a fluid, is doing its own detection and cannot be intercepted from here. The same goes for anything keyed off the block state rather than the fluid state. And one side effect is intended rather than tolerated: the entityInside guard is keyed on the block's fluid state, so a waterlogged block's own behaviour is suppressed too while you ignore water, which in practice means bubble columns stop pushing you. That is the honest reading of "water does not affect me". On Minecraft 26.1 and 26.2 there is a further limit, and it is worth reading before you write the pack: those versions track entity fluid interaction only for fluids in the minecraft:water and minecraft:lava tags, so an entry naming a fluid outside them is accepted and syncs its capability but drives nothing on the movement side. The entityInside guard still fires there, so a modded fluid's own damage is still cancelled even where its buoyancy and drag are not. The field shape is identical on every branch on purpose, so a pack written for 1.21.1 loads and validates unchanged on 26.x; just do not expect a modded fluid to stop pushing you there.

• neoorigins:suppression: a status effect that locks a player out of their abilities. The mod has never registered a status effect of its own before; this is the first, and it exists so you do not have to build an ability lock out of parts. While a player holds it, every active, keybind, and toggle power refuses to fire. A key press or a click in the power GUI gets an action bar line and a short sound, because an input that does nothing needs to come with a reason: unlike a cooldown, there is nothing on the HUD telling the player why. Refusals the player did not ask for stay silent, since neoorigins:activate_power and continuous held-key bindings can both fire every tick and announcing those would flood the action bar. A toggle power that is already on when the effect lands is forced off rather than left on and locked, which would otherwise strand a player mid-transformation with the one key that undoes it refused. The amplifier carries no meaning and is reserved. Delivery is /effect and the neoorigins:apply_effect action and nothing else: no brewing recipe, no tipped arrow, and no potion item, because a craftable ability lock is a balance decision that belongs to your pack rather than one the mod should make for every world.

• Passive powers are left to you, because you can already gate them. Suppression covers actives, keybinds, and toggles only. That is not an oversight and it is not a first instalment: put a power_condition on a passive that tests neoorigins:has_effect for neoorigins:suppression and leave the mode at its DENY default, and the power switches off for exactly as long as the effect is held. Building passive suppression into the effect would have duplicated a surface that already works. has_effect and status_effect resolve the new effect by id like any other, so nothing else was needed to reach it. See COOKBOOK.md for the worked example.

• Ocean origins keep their swim bonus when they leave the seafloor. Reported on Discord: aquatic origins sink and swim badly unless they are walking along the bottom. That is exactly what the numbers said should happen. Every ocean origin's swim bonus, and the shared Natural Swimmer power on top of it, is built on minecraft:water_movement_efficiency, and vanilla halves that attribute outright whenever the swimmer is not on the ground. So the entire swim kit ran at half strength in open water and full strength only while the player was standing on a block, which inverts what an ocean origin is meant to feel like. A new shared power, Open Water, carries +0.25 neoforge:swim_speed, an attribute vanilla reads in the same pass with no such condition, and it is granted to Merling, Siren, Kraken, and Abyssal beside their existing speed powers rather than in place of them. Nothing about water_movement_efficiency changes, so bottom-walking is as fast as it ever was and this only lifts the mid-water case that was lagging behind it. The figure is deliberately short of parity: cancelling the halving outright would take roughly +0.55, and swim_speed is not water-gated, so that would have shown up as a land movement change as well. About +0.21 restores non-sprint terminal velocity underwater, and +0.25 clears that with a little room, matches the magnitude Merling's own tier 1 bonus uses, and lifts the vertical swim impulse, which is the part that reads as sinking when it is missing. Pack authors reach the same attribute: neoforge:swim_speed resolves straight from datapack JSON in attribute_modifier, with no alias needed, and COOKBOOK.md now sets out when to reach for it and when for water_movement_efficiency.

• Aquatic origins mine at full speed while they are actually swimming. Also reported on Discord, and both halves of the report were accurate: Aqua Affinity says these origins mine at full speed submerged, and they did, but only with their feet planted on a block. Vanilla charges two independent penalties. The first is the submerged-mining attribute, applied when the eyes are in water, which underwater_mining_speed has always cancelled. The second is a flat divide by five a few lines later for anyone off the ground, and nothing in the mod touched it, so an aquatic origin paid a fifth of its speed for the whole time it was genuinely swimming and got the full rate only in the one posture the power was least meant for. That fifth is now refunded, gated on all three of eyes in water, off the ground, and holding the power. The off-ground penalty on dry land is a separate anti-cheese rule about mining out of a jump and is deliberately left alone. The correction reads the same synced value the client holds, so break progress is predicted correctly rather than the local player watching the slow animation while the server runs the fast one. Affects Merling, Siren, Kraken, and Abyssal, plus any pack origin using underwater_mining_speed.

• Merling sees in the dark from tier 0, as Siren already did. Reported as the night vision keybind doing nothing on a fresh Merling while working on a Siren. Both are ocean origins that spawn in deep water, so the difference read as a bug rather than a design line, and it was neither: Siren's base power list carried night vision and Merling's carried none at all. Merling only picked it up at tier 2, folded into the Ascended Conduit alongside water breathing and haste, which left two tiers of swimming around a pitch-black ocean floor with no way to see. Deep Sight is now a base power, a straight copy of Siren's Ocean Eyes, and it retires at tier 2 where the conduit takes over, mirroring how Caveborn swaps its base night vision for the ascended one. There is no gap: the same tier overlay that removes the base power grants the conduit, so night vision is continuous from tier 0 upward.

• Size powers now stack across the origin and class layers instead of the last pick winning. A Golem (1.3) who takes the Titan class (1.25) should stand at 1.55, and did not: whichever layer was picked most recently took effect and the other was lost, in both directions. The two obvious explanations were both wrong, which is part of what kept this alive. The modifier ids are already namespaced per power, so the origin and class layers were never colliding, and the maths was already additive: the JSON authors an absolute "scale": 1.3, but the power converts that to a delta and adds it, so the operation was correct too. The fault was in removal. Revoking any one size power cleared every neoorigins:size_* modifier on scale and on both interaction ranges, and the layer-change step then re-granted only the layer that had actually changed, so the other layer's size was gone for good. That also explains why it looked intermittent: the first time you were granted two size layers they really did stack, and the collapse only happened when you re-picked. The over-broad sweep was not careless, it was guarding a real bug. A power whose JSON is deleted or renamed leaves a modifier behind that nothing owns, and players were once left permanently rescaled by it. So rather than narrowing the sweep and reopening that, the two jobs are now separate: revoking a power clears only the modifiers that power itself created, and the sweep for genuinely orphaned modifiers moved to the layer-change step, which is the one place that knows the full set of powers a player still has and can therefore tell an orphan from another layer's live modifier. Twelve built-in size powers are affected: Golem, Kraken, Inchling, Tiny, Dwarf, Hiveling, Gorgon, Draconic, Breeze, Caveborn, Warden, and the Titan class. Reported on Discord.

• On Minecraft 26.1 and 26.2, changing any layer wiped every other layer's attribute_modifier bonuses. Found while porting the fix above, unreported and considerably wider than the size bug. Those two versions had no per-layer sweep at all and cleared every origin-owned attribute modifier whenever any layer changed, so picking a class stripped the max health, armour, and reach your origin granted, and picking an origin stripped the class's, until you relogged. Both branches now use the same targeted sweep as 1.21.1. Players on 26.1 and 26.2 will notice bonuses persisting that used to quietly disappear.

• breath_out_of_fluid honours the drain rate you authored. Reported on Discord: a custom origin built in the web editor always dried out in about twenty seconds whatever the field said, twenty ticks and two ticks alike. The power parsed the field correctly and then threw it away. A tick handler overwrote it with the global [ocean_origins] drain_rate_ticks config on every pass, so the authored value reached nothing and every custom origin dried out at the server's rate instead of its own. The override was deliberate rather than an oversight, but it was too broad: it was written to drive the four built-in aquatic origins from one config option, and it caught custom powers on the way past. The interval is now resolved per power in the same priority order breath_in_fluid already uses, air_loss_per_second first, then drain_interval_ticks, then drain_rate as the legacy spelling, and the config applies only when none of the three is present. That last clause is the whole fix. The four built-in *_dries_out powers author no drain field at all, so they still track the config exactly as #120 left them, while an origin that names a value gets the value it named; where several such powers apply at once, the tightest interval wins. The schema is what made this reportable rather than merely wrong: it advertised drain_rate with a default of forty and a description of what it would do, with nothing to say it was inert, and the editor builds its form from the schema. All three keys are described now, and POWER_TYPES.md carries the arithmetic, so land time in seconds is roughly (300 * drain_interval_ticks) / 20 and the number stays checkable against the behaviour.

• Siren's Beached penalty no longer follows her into the water. The power carried a fifteen percent movement penalty with no condition on it, so a Siren swam fifteen percent slower than every other ocean origin as well as walking that much slower. It is called Beached and described as a land penalty, which is what the other three ocean origins actually do: Merling, Kraken, and Abyssal all carry "condition": "on_land" on the same power, and Siren was the odd one out, with the penalty landing hardest exactly where the origin is supposed to be strong. It is gated on land now. Its description also said ten percent while the value has always been -0.15, so the text is corrected to fifteen rather than the value being changed: Merling is the one at ten percent, and the two were most likely copied and only half edited.

• The night vision key no longer reports success on origins that have none. Pressing it flipped the stored flag and printed a green "Night vision on" whatever you were playing, with no check that your origin had any night vision to switch. That flag is read in exactly one place, when deciding whether to apply a night vision effect an origin actually specifies, so on an origin without one the key was reporting success for an operation that could not have an effect. Forty-nine of the seventy-eight built-in origins are in that position, so this was the common case rather than the corner one. The key now refuses with a message when there is nothing to toggle, leaves the flag untouched, and re-sends the current state, so a client that has drifted still resyncs. A power gated on a condition still counts as owning night vision, since the question is whether the origin has it rather than whether it happens to be lit at that moment: otherwise a Caveborn who walked into daylight would be told they had none. The admin kill switch is unaffected and still takes precedence, so a server that has turned night vision off gives its own message regardless of what the player is playing.

• A parameterised particle named by bare id no longer takes the whole power down with it. Found while boot-testing this release against a third-party pack, unreported and not new to this cycle. mrt_chemist:immunity-shot failed to load on Minecraft 26.1 and 26.2 with "missing or unknown 'particle' field" while loading fine on 1.21.1, and the pack does nothing unusual: it writes "particle": "minecraft:dragon_breath". Minecraft 26 reclassified four particles that took no arguments on 1.21.1 into parameterised ones, dragon_breath, effect, instant_effect and flash, and the power accepted an argument-free particle only by bare id. So on those versions the four stopped resolving, and because the particle field is required, the failure dropped the entire power rather than just its decoration. A parameterised particle named with no arguments now falls back to its plainest form, opaque white at unit scale with no delay, which for those four is what they looked like before the reclassification, so a pack written for 1.21.1 renders unchanged on 26.x. The same fallback picks up entity_effect, dust, sculk_charge and shriek, which are parameterised on every version and were equally unusable bare. Particles that need a referent rather than a decoration, block, item and vibration, still require the object or inline-argument form: there is no honest default for which block, so those stay an error and say so.

• The Blazeling entries described a version of the origin that has not shipped since 2.2. Checked against the live JSON rather than against the previous text, and four of its powers were wrong: Blaze Scales is +6 max health, not natural armour; Nether-Born grants Speed in the Nether, not faster healing; and Internal Heat costs you hunger twenty-five percent faster, so it is a drawback rather than the passive warmth aura it was written up as. The tier table was wrong in both directions too. The second tier was listed as granting Fire Resistance, which 2.2 replaced with +4 max health, and its removal entry named a power that no longer exists, so it read as removing nothing; the third tier was described as removing the Evolved health bonus when it removes the Ascended one. ORIGINS.md and EVOLUTION.md now match what the origin actually grants.

• An on_fire condition can never be true on a fire-immune origin. Worth knowing before you build a mechanic on it. Fire-immune players have their remaining fire ticks zeroed every tick, which was done deliberately to stop the burning overlay flickering on origins that cannot burn, and on_fire reads that same counter. So on Blazeling, or on anything else carrying prevent_action: fire, a power gated on on_fire is not merely unlikely to fire, it is structurally dead. CONDITIONS.md says so now, and points at in_lava or a dimension test as the workable alternatives.

• modify_reach scales by default, whatever the cookbook said. COOKBOOK.md had claimed since v1.14 that reach only scales when explicitly enabled. The field has defaulted to true on every branch for as long as it has existed, so anyone who wrote a size power expecting reach to stay put has been getting scaled reach the whole time. Corrected.

• How the two layers stack is now written down. The bug above was possible partly because nothing said what the intended behaviour was. POWER_TYPES.md now states the stacking rule under both size_scaling and attribute_modifier, CLASSES.md has a section on how a class layer combines with the origin layer rather than replacing it, and COOKBOOK.md gains the cross-layer pitfall as a worked case.