Make ice balls freeze entities instead of slowing them down

[Hugman76]

Closes #118.

An ice ball no longer hands out a slowness effect: it traps whatever it hits in a block of ice.

What a frozen entity does

• Cannot move — LivingEntity.isImmobile() returns true, which cuts off the movement input and skips serverAiStep() entirely. The same check runs on the client that moves a player, so a frozen player cannot walk out of their own block of ice either.
• Holds its last animation — the render state age is wound back to what it was when the ice took hold, so everything driven by it stands still; the walk animation is pinned at zero on top of that, since a shoved block of ice does travel.
• Turns ice blue — drawn through super_mario:core/frozen_entity, which remaps the entity onto the six colours of the vanilla ice block texture. Built the same way as the Gold power-up's shader, with its own render pipeline and render type.
• Is filled by a visible ice cube — the vanilla ice block model, scaled to the entity hitbox and handed to the block renderer, so it picks up the ice block texture directly.
• Is solid — canBeCollidedWith returns true while frozen, so others walk into it and stand on top of it.
• Slides when shoved — a player walking into its side sends it off along the heading they walked into it at, so coming at it from a corner sends it towards that corner. Ice has very little drag, so a shove carries it several blocks, and one that meets a wall at speed shatters against it.
• Floats — a block of ice rides the water surface rather than sinking. The lift is what it displaces, scaled so it cancels gravity at FLOAT_SUBMERSION, which is where it comes to rest. That is set well above what real ice would ride at, so the head of whoever is inside stays out of the water.
• Turns the next ice ball away — one that hits an entity already in the ice bursts against it the way it would against a wall, hurting neither what is inside nor the ice it landed on.

Who resists it

Resistance is judged on hitbox volume, with the bosses named one by one since nothing about a hitbox tells them apart from any other oversized mob:

	Behaviour
Regular (a pig, a player)	Frozen for 10 s, unharmed once it thaws
Big — hitbox volume ≥ 2 blocks³, i.e. an iron golem and up	Cracks the ice open after 3 s, taking 4 damage doing so
Creative player	An ice ball leaves them alone; /freeze still takes them
super_mario:freeze_immune (ender dragon, wither), spectators	Never trapped, takes 4 damage instead

The last row is what Freezing.isUnfreezable covers — nothing at all can hold those. Everything above it is Freezing.resistanceOf, which is only what an ice ball asks.

The issue asks to copy the "big" conditions from the bubble catching system. Bubbles have since landed on dev (#113) and brought super_mario:bubble_can_trap / super_mario:bubble_cannot_trap with them, so the two systems now judge "big" by different rules — the volume rule here, tags there. Aligning them is left as follow-up rather than folded into this branch.

A frozen player can smash any of their movement keys to melt their way out sooner, 15 ticks per press, sent over a new super_mario:freeze/struggle payload.

/freeze

/freeze set <target> <time> puts an entity in the ice by hand, and /freeze query <target> reads back whether one is in there, answering with the usual 1 or 0.

The time is the whole of it, and it is mandatory — there is no toggle to trip over:

<time>
0	Thaws the target. Fails if it was not frozen, the way /effect clear does with nothing to clear
any other number	Freezes for that many ticks, replacing whatever the target was already serving
infinite	A freeze that nothing chips away at, and only a command or fire calls off

How it is stored

The freeze lives in a synced, persistent FreezeState attachment rather than on the entities themselves, which is what makes every living entity freezable without any of them knowing about it. It holds the start and the end of the freeze as game times rather than as a countdown, so the whole thing only has to reach the clients once and they work the rest out on their own — a countdown would have been a packet per entity per tick. An endless freeze is that end set to NEVER.

Tests

FreezeGameTest covers the three resistances, the solidity, the sliding, the floating and the struggling; FreezeCommandGameTest covers the command; BallGameTest.iceballSlowsDownWhatItHits became iceballFreezesWhatItHits, alongside a test that an ice ball bursts on what is already frozen.

./gradlew runDatagen && ./gradlew test && ./gradlew runGameTest — all 184 game tests pass, datagen reports no drift, and the unit tests are green.

The ice shader is not covered by those: render pipelines compile lazily on first use, so it wants a look during playtesting. The mixin behind it was checked by booting the client headless with -Dmixin.debug.export=true — FrozenLivingEntityRendererMixin applies to LivingEntityRenderer cleanly and its @ModifyReturnValue wraps all four of getRenderType's vanilla returns.

🤖 Generated with Claude Code

https://claude.ai/code/session_01CYij5pCRAcCecyXMAKSsz2

[Hugman76]

Feature has been playtested and validated