Flooding caused by lanterns

[FinnTheFox]

Almost every lantern seems to be loaded in with a water source block as well, causing my underground villages to be completely flooded.

I'm running Minecraft 1.20.1 with Forge 47.4.0

(Also: Love this mod! Thank you for your time and effort.)

[SamBurnt]

Same here! It’s pretty annoying… I wish we could disable underwater villages from spawning.

[Reggarfgod]

We’ve released an update addressing the reported issues:

• The Underwater Village has been temporarily removed from Forge 1.20.1 to prevent the flooding problem.
• Fixed loot table issues.
• Additional improvements and fixes have been made.
  For full details, please check out the latest changelog on the mod page.

https://github.com/Reggarfgod/Underground-Village/blob/Multiloader-1.21.x/Changelog.md

[erutobusiness]

I looked into this on 1.20.1 Forge (Underground Village 1.5.5) and measured where the water
actually comes from, in case it helps.

It is the waterlogging, and it is not fixable from a datapack on 1.20.1.

StructurePlaceSettings sets keepLiquids to true in its constructor — it is the only boolean
the constructor turns on — and SinglePoolElement.getSettings keeps it. So every block in a piece
that implements LiquidBlockContainer (stairs, slabs, fences, iron bars, chains, lanterns)
picks up the sea water it is placed into. Those blocks are then water sources and the water
spreads from them into the air the template placed. The liquid_settings /
ignore_waterlogging structure field that would control this only exists from 1.21, so on 1.20.1
the only way to change it is in code.

The "liquid_settings": "ignore_waterlogging" line currently in
data/underground_village/worldgen/structure/underwater_village.json has no reader on 1.20.1 —
I searched the mod classes, the Minecraft jar and the vanilla worldgen data and the string does
not appear anywhere.

Counts. Fixed seed, structure placed at the same coordinates each time, counting waterlogged
blocks in the same 32x32x32 box with
/fill <box> <block>[waterlogged=false] replace <block>[waterlogged=true]:

block	stock	with keepLiquids off
iron bars	84	0
stone brick stairs	64	0
chains	34	0
stone brick slabs	17	0
lanterns	13	0
stone brick wall	1	0
total	213	0

What did not work. I first tried terrain_adaptation: beard_thin on the structure (the
underwater variant has no terrain_adaptation while the land one does). Measured on the same
seed and coordinates, water went up, not down (+252 and +134 in two sample boxes) — that
setting adds terrain below the structure, it does not remove liquid.

What did work. A one-method mixin: in SinglePoolElement.getSettings, call
setKeepLiquids(false) when the element's template is in the stoneholm namespace. Shapes and
textures are unchanged; the pieces simply arrive dry. Water that the template itself contains,
such as the fountain, is a real block in the template and is still placed.

Posting this in case you would rather fix the water than keep the underwater village out of
1.20.1 — it is a small change and it is contained to your own namespace.

[erutobusiness]

Correction to my comment above: I measured on 1.5.5 and had not checked this repository for
anything newer. I see now that the Forge/1.20.1 branch here already drops the underwater village
from the structure sets, which matches your 2026-02-16 note. So the numbers above describe the
older build, not the current one.

The reason I am leaving the comment up rather than deleting it: it points at a fix that keeps the
underwater village instead of removing it, in case that is ever interesting to you. The whole
change is one line — in SinglePoolElement.getSettings, call setKeepLiquids(false) when the
element's template is in the stoneholm namespace. On a fixed seed that took the waterlogged
blocks inside the village from 213 to 0 (13 of them lanterns), with shapes and textures unchanged
and the fountain's own water still placed.

We are staying on 1.5.5 with that patch on our side, because we would rather keep the underwater
village than lose it. Not asking you to change course — just leaving the measurement where it is
findable.