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