Lava Boats

Crimson and Warped boats that ride on lava like water - fireproof hull, fire-immune passengers, and dropped boats float back to the surface.

Загрузки: 6K
Подписчики: 17
Обновлён: 17 августа 2026 г.
Лицензия: All-Rights-Reserved

Опубликован 8 июня 2026 г.

Исходный код Сообщить об ошибке

Lava Boats

Ride lava like it's water. Lava Boats adds Crimson and Warped boats (regular and chest variants) that float and steer on lava exactly like ordinary boats on water. They never burn, riders never catch fire, dropped boats bob back to the surface, and Depth Strider works in lava. No custom packets - a vanilla client can still join a server running it. Client + server mod.

Ships as a Fabric, Forge, and NeoForge mod (Quilt runs the Fabric jar on the pre-26 lines).

Using Lava Boats

Craft a Crimson or Warped boat from 5 matching nether-stem planks (chest variants: a chest + the boat); they appear in the Tools & Utilities creative tab. Place one on lava and ride - it floats and steers just like a boat on water.

Boats and their riders are fully fire-immune while on lava; broken or dropped boats bob back up to the lava surface.
Depth Strider works in lava.
Adds 4 boat items (crimson / warped, plain + chest). No blocks, no commands, no custom packets.

Source

Source code: minecraft-1.20-26.3.

Support

Report bugs or request features at https://github.com/Kishku7/mod_support/issues

Ченджлог

1.4.10+26.3Бета26.3-snapshot-7 · 17 августа 2026 г.

Fixed

Lava boats sank on dedicated servers. The two mixins that create lava buoyancy -- AbstractBoatLavaMixin (the float boost and resurface bob) and the per-loader fluid hook (BoatWaterFabricMixin / BoatFluidForgeMixin / BoatFluidNeoForgeMixin) -- were registered under the "client" key of their mixin configs, so Mixin skipped them entirely in a SERVER environment. On a dedicated server AbstractBoat.getStatus() never saw lava as water, the status resolved to IN_AIR, and floatBoat() applied full gravity with no float boost. Because tick() gates floatBoat() on isLocalInstanceAuthoritative() -- true on the server whenever nobody is riding -- an unridden boat fell to the bottom of the lava, and a ridden one sank as soon as authority returned to the server (dismount, relog, chunk reload). Both mixins now register under "mixins" and run in either environment.
Single-player was never affected, which is why this went unnoticed: an integrated server runs inside the client JVM, where the client-only configs apply normally.
Every jar from 1.4.0 through 1.4.9 was affected, on all three loaders and every MC version from 1.20.1 to 26.3. The mixins were common before the 1.4.0 single-source unification; that commit filed them under "client" and silently undid the earlier multiplayer-sink fix.

Changed

Both fluid hooks now declare require = 3 on their three-method @Redirect. Mixin's default of require = 1 accepts a single successful injection out of the three target methods, so a partial application could pass silently; all three are now mandatory.
Full 44-jar matrix rebuilt (Fabric 10 / Forge 15 / NeoForge 19), -Xlint:all clean, zero javac warnings.
D23 -- the loader now reports the real mod version. Forge and early-NeoForge cells declare version = "${file.jarVersion}" in mods.toml, which FML fills from the jar manifest's Implementation-Version; that attribute was never written, so 18 cells reported 0.0NONE to the loader and Forge/NeoForge 1.20.6 reported a stale hardcoded 1.2.0. Every Forge and NeoForge cell now stamps Implementation-Title / Implementation-Version / Implementation-Vendor, with the -forge / -neoforge filename suffix stripped from the value. Caught by the pre-publish metadata gate, which lava-boats had never been run through before.

Testing

New float gate (Server_Tests/lavaboat-float-gate/ on the harness) -- a server-side BEHAVIOUR gate in the shape of the storm and catch-up gates. It builds a stone basin, fills it with three layers of lava, summons an UNRIDDEN boat above it, and asserts the boat's Y at 6s and 12s. A boot smoketest cannot see this bug: the mod loads clean and logs nothing.
Proven in both directions before being trusted. Pre-fix jars report Y=101.0 (resting on the basin floor, three lava layers down) on both the 1.20 Boat line and the 1.21.2+ AbstractBoat line; fixed jars report Y=103.72, stable across both samples.
CRITICAL tier green on all three loaders: Fabric 1.20.1 / 1.21.1 / 1.21.11 / 26.1.2 / 26.2 / 26.3-snapshot-7, NeoForge 1.20.1 / 1.21.1 / 1.21.11 / 26.1.2, Forge 1.20.1 / 1.21.1 / 1.21.11.

1.4.10+26.2-neoforgeРелиз26.2 · 17 августа 2026 г.

Fixed

Lava boats sank on dedicated servers. The two mixins that create lava buoyancy -- AbstractBoatLavaMixin (the float boost and resurface bob) and the per-loader fluid hook (BoatWaterFabricMixin / BoatFluidForgeMixin / BoatFluidNeoForgeMixin) -- were registered under the "client" key of their mixin configs, so Mixin skipped them entirely in a SERVER environment. On a dedicated server AbstractBoat.getStatus() never saw lava as water, the status resolved to IN_AIR, and floatBoat() applied full gravity with no float boost. Because tick() gates floatBoat() on isLocalInstanceAuthoritative() -- true on the server whenever nobody is riding -- an unridden boat fell to the bottom of the lava, and a ridden one sank as soon as authority returned to the server (dismount, relog, chunk reload). Both mixins now register under "mixins" and run in either environment.
Single-player was never affected, which is why this went unnoticed: an integrated server runs inside the client JVM, where the client-only configs apply normally.
Every jar from 1.4.0 through 1.4.9 was affected, on all three loaders and every MC version from 1.20.1 to 26.3. The mixins were common before the 1.4.0 single-source unification; that commit filed them under "client" and silently undid the earlier multiplayer-sink fix.

Changed

Both fluid hooks now declare require = 3 on their three-method @Redirect. Mixin's default of require = 1 accepts a single successful injection out of the three target methods, so a partial application could pass silently; all three are now mandatory.
Full 44-jar matrix rebuilt (Fabric 10 / Forge 15 / NeoForge 19), -Xlint:all clean, zero javac warnings.
D23 -- the loader now reports the real mod version. Forge and early-NeoForge cells declare version = "${file.jarVersion}" in mods.toml, which FML fills from the jar manifest's Implementation-Version; that attribute was never written, so 18 cells reported 0.0NONE to the loader and Forge/NeoForge 1.20.6 reported a stale hardcoded 1.2.0. Every Forge and NeoForge cell now stamps Implementation-Title / Implementation-Version / Implementation-Vendor, with the -forge / -neoforge filename suffix stripped from the value. Caught by the pre-publish metadata gate, which lava-boats had never been run through before.

Testing

New float gate (Server_Tests/lavaboat-float-gate/ on the harness) -- a server-side BEHAVIOUR gate in the shape of the storm and catch-up gates. It builds a stone basin, fills it with three layers of lava, summons an UNRIDDEN boat above it, and asserts the boat's Y at 6s and 12s. A boot smoketest cannot see this bug: the mod loads clean and logs nothing.
Proven in both directions before being trusted. Pre-fix jars report Y=101.0 (resting on the basin floor, three lava layers down) on both the 1.20 Boat line and the 1.21.2+ AbstractBoat line; fixed jars report Y=103.72, stable across both samples.
CRITICAL tier green on all three loaders: Fabric 1.20.1 / 1.21.1 / 1.21.11 / 26.1.2 / 26.2 / 26.3-snapshot-7, NeoForge 1.20.1 / 1.21.1 / 1.21.11 / 26.1.2, Forge 1.20.1 / 1.21.1 / 1.21.11.

1.4.10+26.2Релиз26.2 · 17 августа 2026 г.

Fixed

Lava boats sank on dedicated servers. The two mixins that create lava buoyancy -- AbstractBoatLavaMixin (the float boost and resurface bob) and the per-loader fluid hook (BoatWaterFabricMixin / BoatFluidForgeMixin / BoatFluidNeoForgeMixin) -- were registered under the "client" key of their mixin configs, so Mixin skipped them entirely in a SERVER environment. On a dedicated server AbstractBoat.getStatus() never saw lava as water, the status resolved to IN_AIR, and floatBoat() applied full gravity with no float boost. Because tick() gates floatBoat() on isLocalInstanceAuthoritative() -- true on the server whenever nobody is riding -- an unridden boat fell to the bottom of the lava, and a ridden one sank as soon as authority returned to the server (dismount, relog, chunk reload). Both mixins now register under "mixins" and run in either environment.
Single-player was never affected, which is why this went unnoticed: an integrated server runs inside the client JVM, where the client-only configs apply normally.
Every jar from 1.4.0 through 1.4.9 was affected, on all three loaders and every MC version from 1.20.1 to 26.3. The mixins were common before the 1.4.0 single-source unification; that commit filed them under "client" and silently undid the earlier multiplayer-sink fix.

Changed

Both fluid hooks now declare require = 3 on their three-method @Redirect. Mixin's default of require = 1 accepts a single successful injection out of the three target methods, so a partial application could pass silently; all three are now mandatory.
Full 44-jar matrix rebuilt (Fabric 10 / Forge 15 / NeoForge 19), -Xlint:all clean, zero javac warnings.
D23 -- the loader now reports the real mod version. Forge and early-NeoForge cells declare version = "${file.jarVersion}" in mods.toml, which FML fills from the jar manifest's Implementation-Version; that attribute was never written, so 18 cells reported 0.0NONE to the loader and Forge/NeoForge 1.20.6 reported a stale hardcoded 1.2.0. Every Forge and NeoForge cell now stamps Implementation-Title / Implementation-Version / Implementation-Vendor, with the -forge / -neoforge filename suffix stripped from the value. Caught by the pre-publish metadata gate, which lava-boats had never been run through before.

Testing

New float gate (Server_Tests/lavaboat-float-gate/ on the harness) -- a server-side BEHAVIOUR gate in the shape of the storm and catch-up gates. It builds a stone basin, fills it with three layers of lava, summons an UNRIDDEN boat above it, and asserts the boat's Y at 6s and 12s. A boot smoketest cannot see this bug: the mod loads clean and logs nothing.
Proven in both directions before being trusted. Pre-fix jars report Y=101.0 (resting on the basin floor, three lava layers down) on both the 1.20 Boat line and the 1.21.2+ AbstractBoat line; fixed jars report Y=103.72, stable across both samples.
CRITICAL tier green on all three loaders: Fabric 1.20.1 / 1.21.1 / 1.21.11 / 26.1.2 / 26.2 / 26.3-snapshot-7, NeoForge 1.20.1 / 1.21.1 / 1.21.11 / 26.1.2, Forge 1.20.1 / 1.21.1 / 1.21.11.

1.4.10+26.1-neoforgeРелиз26.1, 26.1.1, 26.1.2 · 17 августа 2026 г.

Fixed

Lava boats sank on dedicated servers. The two mixins that create lava buoyancy -- AbstractBoatLavaMixin (the float boost and resurface bob) and the per-loader fluid hook (BoatWaterFabricMixin / BoatFluidForgeMixin / BoatFluidNeoForgeMixin) -- were registered under the "client" key of their mixin configs, so Mixin skipped them entirely in a SERVER environment. On a dedicated server AbstractBoat.getStatus() never saw lava as water, the status resolved to IN_AIR, and floatBoat() applied full gravity with no float boost. Because tick() gates floatBoat() on isLocalInstanceAuthoritative() -- true on the server whenever nobody is riding -- an unridden boat fell to the bottom of the lava, and a ridden one sank as soon as authority returned to the server (dismount, relog, chunk reload). Both mixins now register under "mixins" and run in either environment.
Single-player was never affected, which is why this went unnoticed: an integrated server runs inside the client JVM, where the client-only configs apply normally.
Every jar from 1.4.0 through 1.4.9 was affected, on all three loaders and every MC version from 1.20.1 to 26.3. The mixins were common before the 1.4.0 single-source unification; that commit filed them under "client" and silently undid the earlier multiplayer-sink fix.

Changed

Both fluid hooks now declare require = 3 on their three-method @Redirect. Mixin's default of require = 1 accepts a single successful injection out of the three target methods, so a partial application could pass silently; all three are now mandatory.
Full 44-jar matrix rebuilt (Fabric 10 / Forge 15 / NeoForge 19), -Xlint:all clean, zero javac warnings.
D23 -- the loader now reports the real mod version. Forge and early-NeoForge cells declare version = "${file.jarVersion}" in mods.toml, which FML fills from the jar manifest's Implementation-Version; that attribute was never written, so 18 cells reported 0.0NONE to the loader and Forge/NeoForge 1.20.6 reported a stale hardcoded 1.2.0. Every Forge and NeoForge cell now stamps Implementation-Title / Implementation-Version / Implementation-Vendor, with the -forge / -neoforge filename suffix stripped from the value. Caught by the pre-publish metadata gate, which lava-boats had never been run through before.

Testing

New float gate (Server_Tests/lavaboat-float-gate/ on the harness) -- a server-side BEHAVIOUR gate in the shape of the storm and catch-up gates. It builds a stone basin, fills it with three layers of lava, summons an UNRIDDEN boat above it, and asserts the boat's Y at 6s and 12s. A boot smoketest cannot see this bug: the mod loads clean and logs nothing.
Proven in both directions before being trusted. Pre-fix jars report Y=101.0 (resting on the basin floor, three lava layers down) on both the 1.20 Boat line and the 1.21.2+ AbstractBoat line; fixed jars report Y=103.72, stable across both samples.
CRITICAL tier green on all three loaders: Fabric 1.20.1 / 1.21.1 / 1.21.11 / 26.1.2 / 26.2 / 26.3-snapshot-7, NeoForge 1.20.1 / 1.21.1 / 1.21.11 / 26.1.2, Forge 1.20.1 / 1.21.1 / 1.21.11.

1.4.10+26.1Релиз26.1, 26.1.1, 26.1.2 · 17 августа 2026 г.

Fixed

Lava boats sank on dedicated servers. The two mixins that create lava buoyancy -- AbstractBoatLavaMixin (the float boost and resurface bob) and the per-loader fluid hook (BoatWaterFabricMixin / BoatFluidForgeMixin / BoatFluidNeoForgeMixin) -- were registered under the "client" key of their mixin configs, so Mixin skipped them entirely in a SERVER environment. On a dedicated server AbstractBoat.getStatus() never saw lava as water, the status resolved to IN_AIR, and floatBoat() applied full gravity with no float boost. Because tick() gates floatBoat() on isLocalInstanceAuthoritative() -- true on the server whenever nobody is riding -- an unridden boat fell to the bottom of the lava, and a ridden one sank as soon as authority returned to the server (dismount, relog, chunk reload). Both mixins now register under "mixins" and run in either environment.
Single-player was never affected, which is why this went unnoticed: an integrated server runs inside the client JVM, where the client-only configs apply normally.
Every jar from 1.4.0 through 1.4.9 was affected, on all three loaders and every MC version from 1.20.1 to 26.3. The mixins were common before the 1.4.0 single-source unification; that commit filed them under "client" and silently undid the earlier multiplayer-sink fix.

Changed

Both fluid hooks now declare require = 3 on their three-method @Redirect. Mixin's default of require = 1 accepts a single successful injection out of the three target methods, so a partial application could pass silently; all three are now mandatory.
Full 44-jar matrix rebuilt (Fabric 10 / Forge 15 / NeoForge 19), -Xlint:all clean, zero javac warnings.
D23 -- the loader now reports the real mod version. Forge and early-NeoForge cells declare version = "${file.jarVersion}" in mods.toml, which FML fills from the jar manifest's Implementation-Version; that attribute was never written, so 18 cells reported 0.0NONE to the loader and Forge/NeoForge 1.20.6 reported a stale hardcoded 1.2.0. Every Forge and NeoForge cell now stamps Implementation-Title / Implementation-Version / Implementation-Vendor, with the -forge / -neoforge filename suffix stripped from the value. Caught by the pre-publish metadata gate, which lava-boats had never been run through before.

Testing

New float gate (Server_Tests/lavaboat-float-gate/ on the harness) -- a server-side BEHAVIOUR gate in the shape of the storm and catch-up gates. It builds a stone basin, fills it with three layers of lava, summons an UNRIDDEN boat above it, and asserts the boat's Y at 6s and 12s. A boot smoketest cannot see this bug: the mod loads clean and logs nothing.
Proven in both directions before being trusted. Pre-fix jars report Y=101.0 (resting on the basin floor, three lava layers down) on both the 1.20 Boat line and the 1.21.2+ AbstractBoat line; fixed jars report Y=103.72, stable across both samples.
CRITICAL tier green on all three loaders: Fabric 1.20.1 / 1.21.1 / 1.21.11 / 26.1.2 / 26.2 / 26.3-snapshot-7, NeoForge 1.20.1 / 1.21.1 / 1.21.11 / 26.1.2, Forge 1.20.1 / 1.21.1 / 1.21.11.

1.4.10+1.21.9Релиз1.21.9, 1.21.10 · 17 августа 2026 г.

Fixed

Lava boats sank on dedicated servers. The two mixins that create lava buoyancy -- AbstractBoatLavaMixin (the float boost and resurface bob) and the per-loader fluid hook (BoatWaterFabricMixin / BoatFluidForgeMixin / BoatFluidNeoForgeMixin) -- were registered under the "client" key of their mixin configs, so Mixin skipped them entirely in a SERVER environment. On a dedicated server AbstractBoat.getStatus() never saw lava as water, the status resolved to IN_AIR, and floatBoat() applied full gravity with no float boost. Because tick() gates floatBoat() on isLocalInstanceAuthoritative() -- true on the server whenever nobody is riding -- an unridden boat fell to the bottom of the lava, and a ridden one sank as soon as authority returned to the server (dismount, relog, chunk reload). Both mixins now register under "mixins" and run in either environment.
Single-player was never affected, which is why this went unnoticed: an integrated server runs inside the client JVM, where the client-only configs apply normally.
Every jar from 1.4.0 through 1.4.9 was affected, on all three loaders and every MC version from 1.20.1 to 26.3. The mixins were common before the 1.4.0 single-source unification; that commit filed them under "client" and silently undid the earlier multiplayer-sink fix.

Changed

Both fluid hooks now declare require = 3 on their three-method @Redirect. Mixin's default of require = 1 accepts a single successful injection out of the three target methods, so a partial application could pass silently; all three are now mandatory.
Full 44-jar matrix rebuilt (Fabric 10 / Forge 15 / NeoForge 19), -Xlint:all clean, zero javac warnings.
D23 -- the loader now reports the real mod version. Forge and early-NeoForge cells declare version = "${file.jarVersion}" in mods.toml, which FML fills from the jar manifest's Implementation-Version; that attribute was never written, so 18 cells reported 0.0NONE to the loader and Forge/NeoForge 1.20.6 reported a stale hardcoded 1.2.0. Every Forge and NeoForge cell now stamps Implementation-Title / Implementation-Version / Implementation-Vendor, with the -forge / -neoforge filename suffix stripped from the value. Caught by the pre-publish metadata gate, which lava-boats had never been run through before.

Testing

New float gate (Server_Tests/lavaboat-float-gate/ on the harness) -- a server-side BEHAVIOUR gate in the shape of the storm and catch-up gates. It builds a stone basin, fills it with three layers of lava, summons an UNRIDDEN boat above it, and asserts the boat's Y at 6s and 12s. A boot smoketest cannot see this bug: the mod loads clean and logs nothing.
Proven in both directions before being trusted. Pre-fix jars report Y=101.0 (resting on the basin floor, three lava layers down) on both the 1.20 Boat line and the 1.21.2+ AbstractBoat line; fixed jars report Y=103.72, stable across both samples.
CRITICAL tier green on all three loaders: Fabric 1.20.1 / 1.21.1 / 1.21.11 / 26.1.2 / 26.2 / 26.3-snapshot-7, NeoForge 1.20.1 / 1.21.1 / 1.21.11 / 26.1.2, Forge 1.20.1 / 1.21.1 / 1.21.11.

1.4.10+1.21.9-neoforgeРелиз1.21.9 · 17 августа 2026 г.

Fixed

Lava boats sank on dedicated servers. The two mixins that create lava buoyancy -- AbstractBoatLavaMixin (the float boost and resurface bob) and the per-loader fluid hook (BoatWaterFabricMixin / BoatFluidForgeMixin / BoatFluidNeoForgeMixin) -- were registered under the "client" key of their mixin configs, so Mixin skipped them entirely in a SERVER environment. On a dedicated server AbstractBoat.getStatus() never saw lava as water, the status resolved to IN_AIR, and floatBoat() applied full gravity with no float boost. Because tick() gates floatBoat() on isLocalInstanceAuthoritative() -- true on the server whenever nobody is riding -- an unridden boat fell to the bottom of the lava, and a ridden one sank as soon as authority returned to the server (dismount, relog, chunk reload). Both mixins now register under "mixins" and run in either environment.
Single-player was never affected, which is why this went unnoticed: an integrated server runs inside the client JVM, where the client-only configs apply normally.
Every jar from 1.4.0 through 1.4.9 was affected, on all three loaders and every MC version from 1.20.1 to 26.3. The mixins were common before the 1.4.0 single-source unification; that commit filed them under "client" and silently undid the earlier multiplayer-sink fix.

Changed

Both fluid hooks now declare require = 3 on their three-method @Redirect. Mixin's default of require = 1 accepts a single successful injection out of the three target methods, so a partial application could pass silently; all three are now mandatory.
Full 44-jar matrix rebuilt (Fabric 10 / Forge 15 / NeoForge 19), -Xlint:all clean, zero javac warnings.
D23 -- the loader now reports the real mod version. Forge and early-NeoForge cells declare version = "${file.jarVersion}" in mods.toml, which FML fills from the jar manifest's Implementation-Version; that attribute was never written, so 18 cells reported 0.0NONE to the loader and Forge/NeoForge 1.20.6 reported a stale hardcoded 1.2.0. Every Forge and NeoForge cell now stamps Implementation-Title / Implementation-Version / Implementation-Vendor, with the -forge / -neoforge filename suffix stripped from the value. Caught by the pre-publish metadata gate, which lava-boats had never been run through before.

Testing

New float gate (Server_Tests/lavaboat-float-gate/ on the harness) -- a server-side BEHAVIOUR gate in the shape of the storm and catch-up gates. It builds a stone basin, fills it with three layers of lava, summons an UNRIDDEN boat above it, and asserts the boat's Y at 6s and 12s. A boot smoketest cannot see this bug: the mod loads clean and logs nothing.
Proven in both directions before being trusted. Pre-fix jars report Y=101.0 (resting on the basin floor, three lava layers down) on both the 1.20 Boat line and the 1.21.2+ AbstractBoat line; fixed jars report Y=103.72, stable across both samples.
CRITICAL tier green on all three loaders: Fabric 1.20.1 / 1.21.1 / 1.21.11 / 26.1.2 / 26.2 / 26.3-snapshot-7, NeoForge 1.20.1 / 1.21.1 / 1.21.11 / 26.1.2, Forge 1.20.1 / 1.21.1 / 1.21.11.

1.4.10+1.21.8Релиз1.21.6, 1.21.7, 1.21.8 · 17 августа 2026 г.

Fixed

Lava boats sank on dedicated servers. The two mixins that create lava buoyancy -- AbstractBoatLavaMixin (the float boost and resurface bob) and the per-loader fluid hook (BoatWaterFabricMixin / BoatFluidForgeMixin / BoatFluidNeoForgeMixin) -- were registered under the "client" key of their mixin configs, so Mixin skipped them entirely in a SERVER environment. On a dedicated server AbstractBoat.getStatus() never saw lava as water, the status resolved to IN_AIR, and floatBoat() applied full gravity with no float boost. Because tick() gates floatBoat() on isLocalInstanceAuthoritative() -- true on the server whenever nobody is riding -- an unridden boat fell to the bottom of the lava, and a ridden one sank as soon as authority returned to the server (dismount, relog, chunk reload). Both mixins now register under "mixins" and run in either environment.
Single-player was never affected, which is why this went unnoticed: an integrated server runs inside the client JVM, where the client-only configs apply normally.
Every jar from 1.4.0 through 1.4.9 was affected, on all three loaders and every MC version from 1.20.1 to 26.3. The mixins were common before the 1.4.0 single-source unification; that commit filed them under "client" and silently undid the earlier multiplayer-sink fix.

Changed

Both fluid hooks now declare require = 3 on their three-method @Redirect. Mixin's default of require = 1 accepts a single successful injection out of the three target methods, so a partial application could pass silently; all three are now mandatory.
Full 44-jar matrix rebuilt (Fabric 10 / Forge 15 / NeoForge 19), -Xlint:all clean, zero javac warnings.
D23 -- the loader now reports the real mod version. Forge and early-NeoForge cells declare version = "${file.jarVersion}" in mods.toml, which FML fills from the jar manifest's Implementation-Version; that attribute was never written, so 18 cells reported 0.0NONE to the loader and Forge/NeoForge 1.20.6 reported a stale hardcoded 1.2.0. Every Forge and NeoForge cell now stamps Implementation-Title / Implementation-Version / Implementation-Vendor, with the -forge / -neoforge filename suffix stripped from the value. Caught by the pre-publish metadata gate, which lava-boats had never been run through before.

Testing

New float gate (Server_Tests/lavaboat-float-gate/ on the harness) -- a server-side BEHAVIOUR gate in the shape of the storm and catch-up gates. It builds a stone basin, fills it with three layers of lava, summons an UNRIDDEN boat above it, and asserts the boat's Y at 6s and 12s. A boot smoketest cannot see this bug: the mod loads clean and logs nothing.
Proven in both directions before being trusted. Pre-fix jars report Y=101.0 (resting on the basin floor, three lava layers down) on both the 1.20 Boat line and the 1.21.2+ AbstractBoat line; fixed jars report Y=103.72, stable across both samples.
CRITICAL tier green on all three loaders: Fabric 1.20.1 / 1.21.1 / 1.21.11 / 26.1.2 / 26.2 / 26.3-snapshot-7, NeoForge 1.20.1 / 1.21.1 / 1.21.11 / 26.1.2, Forge 1.20.1 / 1.21.1 / 1.21.11.

Lava Boats

Lava Boats

Using Lava Boats

Source

Support

Ченджлог

Fixed

Changed

Testing

Fixed

Changed

Testing

Fixed

Changed

Testing

Fixed

Changed

Testing

Fixed

Changed

Testing

Fixed

Changed

Testing

Fixed

Changed

Testing

Fixed

Changed

Testing

Комментарии

Открытый код