Simple World Hight

Simple World Height

Raise the build height of any dimension — separately, and without
fighting your other worldgen mods.

The rule

Only ever raises, never lowers.

Whatever another mod or datapack has already set is treated as the
floor. Ask for 512 in a Nether that Amplified Nether already runs at
640, and you get 640 plus a log line explaining why. The rule is
enforced in code, not just in the UI, so it holds no matter how the
value was set.

minY is deliberately left alone. Moving the bottom of the world
breaks cave generation and ore distribution in practically every
worldgen mod. Extending upward is safe; extending downward is not.

Setting it

Two paths to the same config file:

• A World Height button in the world creation screen, with presets from 384 up to 2032
• config/simple_world_height.json, for servers and for values that are not in the preset list

Both write the same file. The GUI is a convenience layer, not a second
source of truth.

Existing worlds are protected

The height a world was generated with is recorded in
simple_world_height.json inside the world folder. On every later
start it is compared against the config. If they differ, **the world
wins** and you get a warning in the log.

This is not optional politeness — changing the height of a generated
world leaves you with cut-off chunks and lost data. Set
lockToWorldValues to false if you really want to override it, and
back up first.

Multiplayer

The mod is required on both sides.

This is not a design choice. Since 1.20.5 the server only transmits
registry entries in full when they come from a datapack; for vanilla
dimension types it tells the client to use its own copy instead. A
server-only change never reaches the client, which then rejects every
chunk heightmap it receives.

In singleplayer the client reads the values straight from the
integrated server, so the world’s actual height always wins.

On a dedicated server, the config must match on both sides. The
client cannot query the server for these values, so it falls back to
its own config. If you ship a modpack, ship the same config file with
the client and server versions.

Commands

/worldheight info prints, per dimension, both the dimension type
values and the height limit the world itself reports. Useful for
checking what your other worldgen mods actually set, and for confirming
the two agree.

Configuration

config/simple_world_height.json

• lockToWorldValues — existing worlds keep their generated height (default true)
• dimensions — keyed by dimension type ID, not world ID
• enabled — false means default: the height is not touched at all
• height — target height in blocks, rounded down to a multiple of 16
• logicalHeight — 0 means match height. Affects portals and chorus fruit
• detectedBaseline / lastApplied — written by the mod, informational only

Dimensions without a config entry are never touched, so modded
dimensions are safe by default. Add their type ID to manage them.

Limits

Total height is capped so that minY + height stays within Y 2032, and
heights are rounded to a multiple of 16. Every additional chunk section
costs memory on every loaded chunk, and that scales with player count
and view distance — 1024 is comfortable, 2032 is not something to
enable on a busy server without testing.

Requirements

• Fabric Loader
• Fabric API
• Java 21