- 版权类型
- 原创
- 插件中文名称
- 自定义世界高度
- 插件英文名称
- GlobalWorldHeight
- 原帖地址
- #
- 支持的核心（服务端）
- Paper
- Folia
- 语言支持
- 中文（简体）
- 适配版本（Java）
- 1.21
重要：height 必须是 16 的倍数（如 384/512/1024），否则维度构造会失败
[MD] --- ## 配置文件说明（`config.yml`） ### 1) 全局设置 ```yaml settings: allow-existing-chunks: false ``` - `allow-existing-chunks` - `false`：仅建议用于新世界。若世界已有区块数据，插件会跳过应用，避免高度图尺寸不匹配问题。 - `true`：强制对已有区块世界应用新高度（高风险，可能产生大量 heightmap 警告，建议先备份）。 --- ### 2) 规则结构 每个一级键就是一条规则，例如： ```yaml example-world: world: "world_example" min-y: -64 height: 384 logical-height: 384 dimension-type: "custom" ``` 规则可以通过两种方式匹配世界（**二选一**）： - `world: "xxx"`：精确匹配世界名 - `regex: "^xxx_.*$"`：正则匹配世界名 --- ### 3) 字段解释 - `world`：目标世界名（精确匹配） - `regex`：目标世界名正则（批量匹配） - `min-y`：世界最低 Y - `height`：世界总高度 - `logical-height`：逻辑高度（例如部分传送/判定相关逻辑会用到） - `dimension-type`：维度模板类型，可选： - `custom` - `overworld` - `the_nether` - `the_end` - `overworld_caves` --- ### 4) 数值关系 - 最高可建造上限通常与 `min-y` 和 `height` 相关： - `maxY = min-y + height - 1` 例如： - `min-y: -64` - `height: 1024` - 则 `maxY = 959` --- ### 5) 推荐写法 #### 单世界写法（最常用） ```yaml world-main: world: "world" min-y: -64 height: 1024 logical-height: 512 dimension-type: "overworld" ``` #### 多世界批量写法（正则） ```yaml test-worlds: regex: "^test_.*$" min-y: -64 height: 640 logical-height: 384 dimension-type: "custom" ``` --- ### 6) 编写注意事项 - 同一条规则里不要同时写 `world` 和 `regex`（建议只保留一个）。 - 多条规则如果都可能命中同一世界，实际命中顺序可能影响结果；建议避免重叠规则。 - 修改配置后请**重启服务器**生效，不建议 `/reload`。 - 对已有世界改高度前务必备份。 --- [/MD]
它的实际效果是
修改原版维度类型，而不是改单个世界配置
影响的是“之后创建的新世界”
目标是让这些世界拥有更大的竖直建造范围
没有额外游戏玩法逻辑，主要是底层世界参数补丁
原理
它的原理不是走 Bukkit/Paper 的高层 API，而是直接碰 NMS 注册表。
大致流程是：
在 onLoad() 里执行修补，而不是等 onEnable()
拿到 MinecraftServer
从多个 RegistryAccess / RegistryLayer 视图里收集 DIMENSION_TYPE 注册表
找到原版三个维度类型
克隆出一个“高度扩展版”的 DimensionType
用反射把 holder 绑定到新值
再把 MappedRegistry 内部的索引表同步改掉，保证注册表不会前后不一致
是否能够延伸已有的世界的限高？
这个插件做的事本质上是：
它没有做这些事情：
那已有世界到底有没有可能被延伸？
答案是：理论上有可能，实际不应默认指望。
分情况看：
1. 已有世界还没被服务端加载
如果这个世界只是已经存在于磁盘里，但服务器还没启动，而插件又能在世界加载前成功把原版维度类型补丁进去，那么：
这个世界在后续加载时，有机会读到新的高度定义
于是服务端层面可能表现出更高的 build height
但这只是“有机会”，不是完整保证。
2. 已有世界已经按旧高度生成了大量区块
这种情况下，即使维度定义变高了，也仍然会有很多现实问题：
老区块原本没有高空那部分 section 数据
高于旧上限的区域是否正常生成、保存、同步，要看服务端和具体版本的处理
一些插件、地图工具、编辑器、保护插件可能仍假设旧高度
已生成区块与新生成区块之间，可能会出现边界行为差异
所以它不是“无风险扩容”。
3. 世界不是直接使用原版维度类型
如果已有世界来自：
自定义维度
datapack 自定义 dimension_type
其他插件/模组自己注册的维度定义
所以更准确的表述应该是：
新世界：这是插件明确支持、也是最合理的主要用途
已有世界：可能部分生效，但插件没有把它作为承诺目标，也没有迁移逻辑来保证安全和完整性
[MD] --- ## 配置文件说明（`config.yml`） ### 1) 全局设置 ```yaml settings: allow-existing-chunks: false ``` - `allow-existing-chunks` - `false`：仅建议用于新世界。若世界已有区块数据，插件会跳过应用，避免高度图尺寸不匹配问题。 - `true`：强制对已有区块世界应用新高度（高风险，可能产生大量 heightmap 警告，建议先备份）。 --- ### 2) 规则结构 每个一级键就是一条规则，例如： ```yaml example-world: world: "world_example" min-y: -64 height: 384 logical-height: 384 dimension-type: "custom" ``` 规则可以通过两种方式匹配世界（**二选一**）： - `world: "xxx"`：精确匹配世界名 - `regex: "^xxx_.*$"`：正则匹配世界名 --- ### 3) 字段解释 - `world`：目标世界名（精确匹配） - `regex`：目标世界名正则（批量匹配） - `min-y`：世界最低 Y - `height`：世界总高度 - `logical-height`：逻辑高度（例如部分传送/判定相关逻辑会用到） - `dimension-type`：维度模板类型，可选： - `custom` - `overworld` - `the_nether` - `the_end` - `overworld_caves` --- ### 4) 数值关系 - 最高可建造上限通常与 `min-y` 和 `height` 相关： - `maxY = min-y + height - 1` 例如： - `min-y: -64` - `height: 1024` - 则 `maxY = 959` --- ### 5) 推荐写法 #### 单世界写法（最常用） ```yaml world-main: world: "world" min-y: -64 height: 1024 logical-height: 512 dimension-type: "overworld" ``` #### 多世界批量写法（正则） ```yaml test-worlds: regex: "^test_.*$" min-y: -64 height: 640 logical-height: 384 dimension-type: "custom" ``` --- ### 6) 编写注意事项 - 同一条规则里不要同时写 `world` 和 `regex`（建议只保留一个）。 - 多条规则如果都可能命中同一世界，实际命中顺序可能影响结果；建议避免重叠规则。 - 修改配置后请**重启服务器**生效，不建议 `/reload`。 - 对已有世界改高度前务必备份。 --- [/MD]
它的实际效果是
修改原版维度类型，而不是改单个世界配置
影响的是“之后创建的新世界”
目标是让这些世界拥有更大的竖直建造范围
没有额外游戏玩法逻辑，主要是底层世界参数补丁
原理
它的原理不是走 Bukkit/Paper 的高层 API，而是直接碰 NMS 注册表。
大致流程是：
在 onLoad() 里执行修补，而不是等 onEnable()
拿到 MinecraftServer
从多个 RegistryAccess / RegistryLayer 视图里收集 DIMENSION_TYPE 注册表
找到原版三个维度类型
克隆出一个“高度扩展版”的 DimensionType
用反射把 holder 绑定到新值
再把 MappedRegistry 内部的索引表同步改掉，保证注册表不会前后不一致
是否能够延伸已有的世界的限高？
这个插件做的事本质上是：
- 在 onLoad() 很早阶段
- 修改原版 DimensionType
- 让原版维度定义变成 -64..959
它没有做这些事情：
- 不改已有世界的 level.dat
- 不改已有区块 NBT
- 不重建旧区块的高度图、区块段结构
- 不做存档迁移或兼容性修复
- 也就是说，它改的是“维度定义来源”，不是“老存档数据本身”。
那已有世界到底有没有可能被延伸？
答案是：理论上有可能，实际不应默认指望。
分情况看：
1. 已有世界还没被服务端加载
如果这个世界只是已经存在于磁盘里，但服务器还没启动，而插件又能在世界加载前成功把原版维度类型补丁进去，那么：
这个世界在后续加载时，有机会读到新的高度定义
于是服务端层面可能表现出更高的 build height
但这只是“有机会”，不是完整保证。
2. 已有世界已经按旧高度生成了大量区块
这种情况下，即使维度定义变高了，也仍然会有很多现实问题：
老区块原本没有高空那部分 section 数据
高于旧上限的区域是否正常生成、保存、同步，要看服务端和具体版本的处理
一些插件、地图工具、编辑器、保护插件可能仍假设旧高度
已生成区块与新生成区块之间，可能会出现边界行为差异
所以它不是“无风险扩容”。
3. 世界不是直接使用原版维度类型
如果已有世界来自：
自定义维度
datapack 自定义 dimension_type
其他插件/模组自己注册的维度定义
所以更准确的表述应该是：
新世界：这是插件明确支持、也是最合理的主要用途
已有世界：可能部分生效，但插件没有把它作为承诺目标，也没有迁移逻辑来保证安全和完整性
