ВЕРСИИ (491)

# CodxLib 1.6.1 *This file is for **NeoForge 26.3**. Every loader ships the same CodxLib version, so the notes below apply here too.* **Minecraft 26.3 support. Nothing else changed.** CodxLib now ships for **Minecraft 26.3** on **Fabric** and **NeoForge**. There is no Forge build for 26.3 yet — Forge has not released one — so it will be added here if and when it ships. Every other version is byte-for-byte the same library as 1.6.0: no API changes, no behaviour changes, nothing to do on your side. If you are not playing 26.3, there is no reason to update.

# CodxLib 1.6.1 *This file is for **NeoForge 26.2**. Every loader ships the same CodxLib version, so the notes below apply here too.* **Minecraft 26.3 support. Nothing else changed.** CodxLib now ships for **Minecraft 26.3** on **Fabric** and **NeoForge**. There is no Forge build for 26.3 yet — Forge has not released one — so it will be added here if and when it ships. Every other version is byte-for-byte the same library as 1.6.0: no API changes, no behaviour changes, nothing to do on your side. If you are not playing 26.3, there is no reason to update.

# CodxLib 1.6.1 *This file is for **Forge 26.2**. Every loader ships the same CodxLib version, so the notes below apply here too.* **Minecraft 26.3 support. Nothing else changed.** CodxLib now ships for **Minecraft 26.3** on **Fabric** and **NeoForge**. There is no Forge build for 26.3 yet — Forge has not released one — so it will be added here if and when it ships. Every other version is byte-for-byte the same library as 1.6.0: no API changes, no behaviour changes, nothing to do on your side. If you are not playing 26.3, there is no reason to update.

# CodxLib 1.6.1 *This file is for **Fabric 26.2**. It requires **Fabric Loader 0.18.4 or newer** — exactly what Fabric API already needs on 26.2, so CodxLib adds no restriction of its own — and **Fabric API 0.155.2+26.2 or newer**.* **Minecraft 26.3 support. Nothing else changed.** CodxLib now ships for **Minecraft 26.3** on **Fabric** and **NeoForge**. There is no Forge build for 26.3 yet — Forge has not released one — so it will be added here if and when it ships. Every other version is byte-for-byte the same library as 1.6.0: no API changes, no behaviour changes, nothing to do on your side. If you are not playing 26.3, there is no reason to update.

# CodxLib 1.6.1 *This file is for **NeoForge 26.1.2**. Every loader ships the same CodxLib version, so the notes below apply here too.* **Minecraft 26.3 support. Nothing else changed.** CodxLib now ships for **Minecraft 26.3** on **Fabric** and **NeoForge**. There is no Forge build for 26.3 yet — Forge has not released one — so it will be added here if and when it ships. Every other version is byte-for-byte the same library as 1.6.0: no API changes, no behaviour changes, nothing to do on your side. If you are not playing 26.3, there is no reason to update.

# CodxLib 1.6.1 *This file is for **Forge 26.1.2**. Every loader ships the same CodxLib version, so the notes below apply here too.* **Minecraft 26.3 support. Nothing else changed.** CodxLib now ships for **Minecraft 26.3** on **Fabric** and **NeoForge**. There is no Forge build for 26.3 yet — Forge has not released one — so it will be added here if and when it ships. Every other version is byte-for-byte the same library as 1.6.0: no API changes, no behaviour changes, nothing to do on your side. If you are not playing 26.3, there is no reason to update.

# CodxLib 1.6.1 *This file is for **Fabric 26.1.2**. It requires **Fabric Loader 0.18.4 or newer** — exactly what Fabric API already needs on 26.1.2, so CodxLib adds no restriction of its own — and **Fabric API 0.145.4+26.1.2 or newer**.* **Minecraft 26.3 support. Nothing else changed.** CodxLib now ships for **Minecraft 26.3** on **Fabric** and **NeoForge**. There is no Forge build for 26.3 yet — Forge has not released one — so it will be added here if and when it ships. Every other version is byte-for-byte the same library as 1.6.0: no API changes, no behaviour changes, nothing to do on your side. If you are not playing 26.3, there is no reason to update.

# CodxLib 1.6.1 *This file is for **NeoForge 26.1.1**. Every loader ships the same CodxLib version, so the notes below apply here too.* **Minecraft 26.3 support. Nothing else changed.** CodxLib now ships for **Minecraft 26.3** on **Fabric** and **NeoForge**. There is no Forge build for 26.3 yet — Forge has not released one — so it will be added here if and when it ships. Every other version is byte-for-byte the same library as 1.6.0: no API changes, no behaviour changes, nothing to do on your side. If you are not playing 26.3, there is no reason to update.

# CodxLib 1.6.1 *This file is for **Forge 26.1.1**. Every loader ships the same CodxLib version, so the notes below apply here too.* **Minecraft 26.3 support. Nothing else changed.** CodxLib now ships for **Minecraft 26.3** on **Fabric** and **NeoForge**. There is no Forge build for 26.3 yet — Forge has not released one — so it will be added here if and when it ships. Every other version is byte-for-byte the same library as 1.6.0: no API changes, no behaviour changes, nothing to do on your side. If you are not playing 26.3, there is no reason to update.

# CodxLib 1.6.1 *This file is for **Fabric 26.1.1**. It requires **Fabric Loader 0.18.4 or newer** — exactly what Fabric API already needs on 26.1.1, so CodxLib adds no restriction of its own — and **Fabric API 0.145.4+26.1.1 or newer**.* **Minecraft 26.3 support. Nothing else changed.** CodxLib now ships for **Minecraft 26.3** on **Fabric** and **NeoForge**. There is no Forge build for 26.3 yet — Forge has not released one — so it will be added here if and when it ships. Every other version is byte-for-byte the same library as 1.6.0: no API changes, no behaviour changes, nothing to do on your side. If you are not playing 26.3, there is no reason to update.

# CodxLib 1.6.1 *This file is for **NeoForge 26.1**. Every loader ships the same CodxLib version, so the notes below apply here too.* **Minecraft 26.3 support. Nothing else changed.** CodxLib now ships for **Minecraft 26.3** on **Fabric** and **NeoForge**. There is no Forge build for 26.3 yet — Forge has not released one — so it will be added here if and when it ships. Every other version is byte-for-byte the same library as 1.6.0: no API changes, no behaviour changes, nothing to do on your side. If you are not playing 26.3, there is no reason to update.

# CodxLib 1.6.1 *This file is for **Forge 26.1**. Every loader ships the same CodxLib version, so the notes below apply here too.* **Minecraft 26.3 support. Nothing else changed.** CodxLib now ships for **Minecraft 26.3** on **Fabric** and **NeoForge**. There is no Forge build for 26.3 yet — Forge has not released one — so it will be added here if and when it ships. Every other version is byte-for-byte the same library as 1.6.0: no API changes, no behaviour changes, nothing to do on your side. If you are not playing 26.3, there is no reason to update.

# CodxLib 1.6.1 *This file is for **Fabric 26.1**. It requires **Fabric Loader 0.18.4 or newer** — exactly what Fabric API already needs on 26.1, so CodxLib adds no restriction of its own — and **Fabric API 0.145.1+26.1 or newer**.* **Minecraft 26.3 support. Nothing else changed.** CodxLib now ships for **Minecraft 26.3** on **Fabric** and **NeoForge**. There is no Forge build for 26.3 yet — Forge has not released one — so it will be added here if and when it ships. Every other version is byte-for-byte the same library as 1.6.0: no API changes, no behaviour changes, nothing to do on your side. If you are not playing 26.3, there is no reason to update.

# CodxLib 1.6.1 *This file is for **NeoForge 1.21.11**. Every loader ships the same CodxLib version, so the notes below apply here too.* **Minecraft 26.3 support. Nothing else changed.** CodxLib now ships for **Minecraft 26.3** on **Fabric** and **NeoForge**. There is no Forge build for 26.3 yet — Forge has not released one — so it will be added here if and when it ships. Every other version is byte-for-byte the same library as 1.6.0: no API changes, no behaviour changes, nothing to do on your side. If you are not playing 26.3, there is no reason to update.

# CodxLib 1.6.1 *This file is for **Forge 1.21.11**. Every loader ships the same CodxLib version, so the notes below apply here too.* **Minecraft 26.3 support. Nothing else changed.** CodxLib now ships for **Minecraft 26.3** on **Fabric** and **NeoForge**. There is no Forge build for 26.3 yet — Forge has not released one — so it will be added here if and when it ships. Every other version is byte-for-byte the same library as 1.6.0: no API changes, no behaviour changes, nothing to do on your side. If you are not playing 26.3, there is no reason to update.

# CodxLib 1.6.1 *This file is for **Fabric 1.21.11**. It requires **Fabric Loader 0.17.3 or newer** — exactly what Fabric API already needs on 1.21.11, so CodxLib adds no restriction of its own — and **Fabric API 0.141.5+1.21.11 or newer**.* **Minecraft 26.3 support. Nothing else changed.** CodxLib now ships for **Minecraft 26.3** on **Fabric** and **NeoForge**. There is no Forge build for 26.3 yet — Forge has not released one — so it will be added here if and when it ships. Every other version is byte-for-byte the same library as 1.6.0: no API changes, no behaviour changes, nothing to do on your side. If you are not playing 26.3, there is no reason to update.

# CodxLib 1.6.1 *This file is for **NeoForge 1.21.10**. Every loader ships the same CodxLib version, so the notes below apply here too.* **Minecraft 26.3 support. Nothing else changed.** CodxLib now ships for **Minecraft 26.3** on **Fabric** and **NeoForge**. There is no Forge build for 26.3 yet — Forge has not released one — so it will be added here if and when it ships. Every other version is byte-for-byte the same library as 1.6.0: no API changes, no behaviour changes, nothing to do on your side. If you are not playing 26.3, there is no reason to update.

# CodxLib 1.6.1 *This file is for **Forge 1.21.10**. Every loader ships the same CodxLib version, so the notes below apply here too.* **Minecraft 26.3 support. Nothing else changed.** CodxLib now ships for **Minecraft 26.3** on **Fabric** and **NeoForge**. There is no Forge build for 26.3 yet — Forge has not released one — so it will be added here if and when it ships. Every other version is byte-for-byte the same library as 1.6.0: no API changes, no behaviour changes, nothing to do on your side. If you are not playing 26.3, there is no reason to update.

# CodxLib 1.6.1 *This file is for **Fabric 1.21.10**. It requires **Fabric Loader 0.17.0 or newer** — exactly what Fabric API already needs on 1.21.10, so CodxLib adds no restriction of its own — and **Fabric API 0.138.4+1.21.10 or newer**.* **Minecraft 26.3 support. Nothing else changed.** CodxLib now ships for **Minecraft 26.3** on **Fabric** and **NeoForge**. There is no Forge build for 26.3 yet — Forge has not released one — so it will be added here if and when it ships. Every other version is byte-for-byte the same library as 1.6.0: no API changes, no behaviour changes, nothing to do on your side. If you are not playing 26.3, there is no reason to update.

# CodxLib 1.6.1 *This file is for **NeoForge 1.21.9**. Every loader ships the same CodxLib version, so the notes below apply here too.* **Minecraft 26.3 support. Nothing else changed.** CodxLib now ships for **Minecraft 26.3** on **Fabric** and **NeoForge**. There is no Forge build for 26.3 yet — Forge has not released one — so it will be added here if and when it ships. Every other version is byte-for-byte the same library as 1.6.0: no API changes, no behaviour changes, nothing to do on your side. If you are not playing 26.3, there is no reason to update.

# CodxLib 1.6.1 *This file is for **Forge 1.21.9**. Every loader ships the same CodxLib version, so the notes below apply here too.* **Minecraft 26.3 support. Nothing else changed.** CodxLib now ships for **Minecraft 26.3** on **Fabric** and **NeoForge**. There is no Forge build for 26.3 yet — Forge has not released one — so it will be added here if and when it ships. Every other version is byte-for-byte the same library as 1.6.0: no API changes, no behaviour changes, nothing to do on your side. If you are not playing 26.3, there is no reason to update.

# CodxLib 1.6.1 *This file is for **Fabric 1.21.9**. It requires **Fabric Loader 0.17.0 or newer** — exactly what Fabric API already needs on 1.21.9, so CodxLib adds no restriction of its own — and **Fabric API 0.134.1+1.21.9 or newer**.* **Minecraft 26.3 support. Nothing else changed.** CodxLib now ships for **Minecraft 26.3** on **Fabric** and **NeoForge**. There is no Forge build for 26.3 yet — Forge has not released one — so it will be added here if and when it ships. Every other version is byte-for-byte the same library as 1.6.0: no API changes, no behaviour changes, nothing to do on your side. If you are not playing 26.3, there is no reason to update.

# CodxLib 1.6.1 *This file is for **NeoForge 1.21.8**. Every loader ships the same CodxLib version, so the notes below apply here too.* **Minecraft 26.3 support. Nothing else changed.** CodxLib now ships for **Minecraft 26.3** on **Fabric** and **NeoForge**. There is no Forge build for 26.3 yet — Forge has not released one — so it will be added here if and when it ships. Every other version is byte-for-byte the same library as 1.6.0: no API changes, no behaviour changes, nothing to do on your side. If you are not playing 26.3, there is no reason to update.

# CodxLib 1.6.1 *This file is for **Forge 1.21.8**. Every loader ships the same CodxLib version, so the notes below apply here too.* **Minecraft 26.3 support. Nothing else changed.** CodxLib now ships for **Minecraft 26.3** on **Fabric** and **NeoForge**. There is no Forge build for 26.3 yet — Forge has not released one — so it will be added here if and when it ships. Every other version is byte-for-byte the same library as 1.6.0: no API changes, no behaviour changes, nothing to do on your side. If you are not playing 26.3, there is no reason to update.

# CodxLib 1.6.1 *This file is for **Fabric 1.21.8**. It requires **Fabric Loader 0.16.13 or newer** — exactly what Fabric API already needs on 1.21.8, so CodxLib adds no restriction of its own — and **Fabric API 0.136.1+1.21.8 or newer**.* **Minecraft 26.3 support. Nothing else changed.** CodxLib now ships for **Minecraft 26.3** on **Fabric** and **NeoForge**. There is no Forge build for 26.3 yet — Forge has not released one — so it will be added here if and when it ships. Every other version is byte-for-byte the same library as 1.6.0: no API changes, no behaviour changes, nothing to do on your side. If you are not playing 26.3, there is no reason to update.

# CodxLib 1.6.1 *This file is for **NeoForge 1.21.7**. Every loader ships the same CodxLib version, so the notes below apply here too.* **Minecraft 26.3 support. Nothing else changed.** CodxLib now ships for **Minecraft 26.3** on **Fabric** and **NeoForge**. There is no Forge build for 26.3 yet — Forge has not released one — so it will be added here if and when it ships. Every other version is byte-for-byte the same library as 1.6.0: no API changes, no behaviour changes, nothing to do on your side. If you are not playing 26.3, there is no reason to update.

# CodxLib 1.6.1 *This file is for **Forge 1.21.7**. Every loader ships the same CodxLib version, so the notes below apply here too.* **Minecraft 26.3 support. Nothing else changed.** CodxLib now ships for **Minecraft 26.3** on **Fabric** and **NeoForge**. There is no Forge build for 26.3 yet — Forge has not released one — so it will be added here if and when it ships. Every other version is byte-for-byte the same library as 1.6.0: no API changes, no behaviour changes, nothing to do on your side. If you are not playing 26.3, there is no reason to update.

# CodxLib 1.6.1 *This file is for **Fabric 1.21.7**. It requires **Fabric Loader 0.16.13 or newer** — exactly what Fabric API already needs on 1.21.7, so CodxLib adds no restriction of its own — and **Fabric API 0.129.0+1.21.7 or newer**.* **Minecraft 26.3 support. Nothing else changed.** CodxLib now ships for **Minecraft 26.3** on **Fabric** and **NeoForge**. There is no Forge build for 26.3 yet — Forge has not released one — so it will be added here if and when it ships. Every other version is byte-for-byte the same library as 1.6.0: no API changes, no behaviour changes, nothing to do on your side. If you are not playing 26.3, there is no reason to update.

# CodxLib 1.6.1 *This file is for **NeoForge 1.21.6**. Every loader ships the same CodxLib version, so the notes below apply here too.* **Minecraft 26.3 support. Nothing else changed.** CodxLib now ships for **Minecraft 26.3** on **Fabric** and **NeoForge**. There is no Forge build for 26.3 yet — Forge has not released one — so it will be added here if and when it ships. Every other version is byte-for-byte the same library as 1.6.0: no API changes, no behaviour changes, nothing to do on your side. If you are not playing 26.3, there is no reason to update.

# CodxLib 1.6.1 *This file is for **Forge 1.21.6**. Every loader ships the same CodxLib version, so the notes below apply here too.* **Minecraft 26.3 support. Nothing else changed.** CodxLib now ships for **Minecraft 26.3** on **Fabric** and **NeoForge**. There is no Forge build for 26.3 yet — Forge has not released one — so it will be added here if and when it ships. Every other version is byte-for-byte the same library as 1.6.0: no API changes, no behaviour changes, nothing to do on your side. If you are not playing 26.3, there is no reason to update.

# CodxLib 1.6.1 *This file is for **Fabric 1.21.6**. It requires **Fabric Loader 0.16.13 or newer** — exactly what Fabric API already needs on 1.21.6, so CodxLib adds no restriction of its own — and **Fabric API 0.128.2+1.21.6 or newer**.* **Minecraft 26.3 support. Nothing else changed.** CodxLib now ships for **Minecraft 26.3** on **Fabric** and **NeoForge**. There is no Forge build for 26.3 yet — Forge has not released one — so it will be added here if and when it ships. Every other version is byte-for-byte the same library as 1.6.0: no API changes, no behaviour changes, nothing to do on your side. If you are not playing 26.3, there is no reason to update.

# CodxLib 1.6.1 *This file is for **NeoForge 1.21.5**. Every loader ships the same CodxLib version, so the notes below apply here too.* **Minecraft 26.3 support. Nothing else changed.** CodxLib now ships for **Minecraft 26.3** on **Fabric** and **NeoForge**. There is no Forge build for 26.3 yet — Forge has not released one — so it will be added here if and when it ships. Every other version is byte-for-byte the same library as 1.6.0: no API changes, no behaviour changes, nothing to do on your side. If you are not playing 26.3, there is no reason to update.

# CodxLib 1.6.1 *This file is for **Forge 1.21.5**. Every loader ships the same CodxLib version, so the notes below apply here too.* **Minecraft 26.3 support. Nothing else changed.** CodxLib now ships for **Minecraft 26.3** on **Fabric** and **NeoForge**. There is no Forge build for 26.3 yet — Forge has not released one — so it will be added here if and when it ships. Every other version is byte-for-byte the same library as 1.6.0: no API changes, no behaviour changes, nothing to do on your side. If you are not playing 26.3, there is no reason to update.

# CodxLib 1.6.1 *This file is for **Fabric 1.21.5**. It requires **Fabric Loader 0.16.10 or newer** — exactly what Fabric API already needs on 1.21.5, so CodxLib adds no restriction of its own — and **Fabric API 0.128.2+1.21.5 or newer**.* **Minecraft 26.3 support. Nothing else changed.** CodxLib now ships for **Minecraft 26.3** on **Fabric** and **NeoForge**. There is no Forge build for 26.3 yet — Forge has not released one — so it will be added here if and when it ships. Every other version is byte-for-byte the same library as 1.6.0: no API changes, no behaviour changes, nothing to do on your side. If you are not playing 26.3, there is no reason to update.

# CodxLib 1.6.1 *This file is for **NeoForge 1.21.4**. Every loader ships the same CodxLib version, so the notes below apply here too.* **Minecraft 26.3 support. Nothing else changed.** CodxLib now ships for **Minecraft 26.3** on **Fabric** and **NeoForge**. There is no Forge build for 26.3 yet — Forge has not released one — so it will be added here if and when it ships. Every other version is byte-for-byte the same library as 1.6.0: no API changes, no behaviour changes, nothing to do on your side. If you are not playing 26.3, there is no reason to update.

# CodxLib 1.6.1 *This file is for **Forge 1.21.4**. Every loader ships the same CodxLib version, so the notes below apply here too.* **Minecraft 26.3 support. Nothing else changed.** CodxLib now ships for **Minecraft 26.3** on **Fabric** and **NeoForge**. There is no Forge build for 26.3 yet — Forge has not released one — so it will be added here if and when it ships. Every other version is byte-for-byte the same library as 1.6.0: no API changes, no behaviour changes, nothing to do on your side. If you are not playing 26.3, there is no reason to update.

# CodxLib 1.6.1 *This file is for **Fabric 1.21.4**. It requires **Fabric Loader 0.16.9 or newer** — exactly what Fabric API already needs on 1.21.4, so CodxLib adds no restriction of its own — and **Fabric API 0.119.4+1.21.4 or newer**.* **Minecraft 26.3 support. Nothing else changed.** CodxLib now ships for **Minecraft 26.3** on **Fabric** and **NeoForge**. There is no Forge build for 26.3 yet — Forge has not released one — so it will be added here if and when it ships. Every other version is byte-for-byte the same library as 1.6.0: no API changes, no behaviour changes, nothing to do on your side. If you are not playing 26.3, there is no reason to update.

# CodxLib 1.6.1 *This file is for **NeoForge 1.21.3**. Every loader ships the same CodxLib version, so the notes below apply here too.* **Minecraft 26.3 support. Nothing else changed.** CodxLib now ships for **Minecraft 26.3** on **Fabric** and **NeoForge**. There is no Forge build for 26.3 yet — Forge has not released one — so it will be added here if and when it ships. Every other version is byte-for-byte the same library as 1.6.0: no API changes, no behaviour changes, nothing to do on your side. If you are not playing 26.3, there is no reason to update.

# CodxLib 1.6.1 *This file is for **Forge 1.21.3**. Every loader ships the same CodxLib version, so the notes below apply here too.* **Minecraft 26.3 support. Nothing else changed.** CodxLib now ships for **Minecraft 26.3** on **Fabric** and **NeoForge**. There is no Forge build for 26.3 yet — Forge has not released one — so it will be added here if and when it ships. Every other version is byte-for-byte the same library as 1.6.0: no API changes, no behaviour changes, nothing to do on your side. If you are not playing 26.3, there is no reason to update.

# CodxLib 1.6.1 *This file is for **Fabric 1.21.3**. It requires **Fabric Loader 0.16.8 or newer** — exactly what Fabric API already needs on 1.21.3, so CodxLib adds no restriction of its own — and **Fabric API 0.114.1+1.21.3 or newer**.* **Minecraft 26.3 support. Nothing else changed.** CodxLib now ships for **Minecraft 26.3** on **Fabric** and **NeoForge**. There is no Forge build for 26.3 yet — Forge has not released one — so it will be added here if and when it ships. Every other version is byte-for-byte the same library as 1.6.0: no API changes, no behaviour changes, nothing to do on your side. If you are not playing 26.3, there is no reason to update.

# CodxLib 1.6.1 *This file is for **NeoForge 1.21.2**. Every loader ships the same CodxLib version, so the notes below apply here too.* **Minecraft 26.3 support. Nothing else changed.** CodxLib now ships for **Minecraft 26.3** on **Fabric** and **NeoForge**. There is no Forge build for 26.3 yet — Forge has not released one — so it will be added here if and when it ships. Every other version is byte-for-byte the same library as 1.6.0: no API changes, no behaviour changes, nothing to do on your side. If you are not playing 26.3, there is no reason to update.

# CodxLib 1.6.1 *This file is for **Fabric 1.21.2**. It requires **Fabric Loader 0.16.7 or newer** — exactly what Fabric API already needs on 1.21.2, so CodxLib adds no restriction of its own — and **Fabric API 0.106.1+1.21.2 or newer**.* **Minecraft 26.3 support. Nothing else changed.** CodxLib now ships for **Minecraft 26.3** on **Fabric** and **NeoForge**. There is no Forge build for 26.3 yet — Forge has not released one — so it will be added here if and when it ships. Every other version is byte-for-byte the same library as 1.6.0: no API changes, no behaviour changes, nothing to do on your side. If you are not playing 26.3, there is no reason to update.

# CodxLib 1.6.1 *This file is for **NeoForge 1.21.1**. Every loader ships the same CodxLib version, so the notes below apply here too.* **Minecraft 26.3 support. Nothing else changed.** CodxLib now ships for **Minecraft 26.3** on **Fabric** and **NeoForge**. There is no Forge build for 26.3 yet — Forge has not released one — so it will be added here if and when it ships. Every other version is byte-for-byte the same library as 1.6.0: no API changes, no behaviour changes, nothing to do on your side. If you are not playing 26.3, there is no reason to update.

# CodxLib 1.6.1 *This file is for **Forge 1.21.1**. Every loader ships the same CodxLib version, so the notes below apply here too.* **Minecraft 26.3 support. Nothing else changed.** CodxLib now ships for **Minecraft 26.3** on **Fabric** and **NeoForge**. There is no Forge build for 26.3 yet — Forge has not released one — so it will be added here if and when it ships. Every other version is byte-for-byte the same library as 1.6.0: no API changes, no behaviour changes, nothing to do on your side. If you are not playing 26.3, there is no reason to update.

# CodxLib 1.6.1 *This file is for **Fabric 1.21.1**. It requires **Fabric Loader 0.15.11 or newer** — exactly what Fabric API already needs on 1.21.1, so CodxLib adds no restriction of its own — and **Fabric API 0.116.4+1.21.1 or newer**.* **Minecraft 26.3 support. Nothing else changed.** CodxLib now ships for **Minecraft 26.3** on **Fabric** and **NeoForge**. There is no Forge build for 26.3 yet — Forge has not released one — so it will be added here if and when it ships. Every other version is byte-for-byte the same library as 1.6.0: no API changes, no behaviour changes, nothing to do on your side. If you are not playing 26.3, there is no reason to update.

# CodxLib 1.6.1 *This file is for **NeoForge 1.21**. Every loader ships the same CodxLib version, so the notes below apply here too.* **Minecraft 26.3 support. Nothing else changed.** CodxLib now ships for **Minecraft 26.3** on **Fabric** and **NeoForge**. There is no Forge build for 26.3 yet — Forge has not released one — so it will be added here if and when it ships. Every other version is byte-for-byte the same library as 1.6.0: no API changes, no behaviour changes, nothing to do on your side. If you are not playing 26.3, there is no reason to update.

# CodxLib 1.6.1 *This file is for **Forge 1.21**. Every loader ships the same CodxLib version, so the notes below apply here too.* **Minecraft 26.3 support. Nothing else changed.** CodxLib now ships for **Minecraft 26.3** on **Fabric** and **NeoForge**. There is no Forge build for 26.3 yet — Forge has not released one — so it will be added here if and when it ships. Every other version is byte-for-byte the same library as 1.6.0: no API changes, no behaviour changes, nothing to do on your side. If you are not playing 26.3, there is no reason to update.

# CodxLib 1.6.1 *This file is for **Fabric 1.21**. It requires **Fabric Loader 0.15.11 or newer** — exactly what Fabric API already needs on 1.21, so CodxLib adds no restriction of its own — and **Fabric API 0.102.0+1.21 or newer**.* **Minecraft 26.3 support. Nothing else changed.** CodxLib now ships for **Minecraft 26.3** on **Fabric** and **NeoForge**. There is no Forge build for 26.3 yet — Forge has not released one — so it will be added here if and when it ships. Every other version is byte-for-byte the same library as 1.6.0: no API changes, no behaviour changes, nothing to do on your side. If you are not playing 26.3, there is no reason to update.

# CodxLib 1.6.1 *This file is for **NeoForge 1.20.6**. Every loader ships the same CodxLib version, so the notes below apply here too.* **Minecraft 26.3 support. Nothing else changed.** CodxLib now ships for **Minecraft 26.3** on **Fabric** and **NeoForge**. There is no Forge build for 26.3 yet — Forge has not released one — so it will be added here if and when it ships. Every other version is byte-for-byte the same library as 1.6.0: no API changes, no behaviour changes, nothing to do on your side. If you are not playing 26.3, there is no reason to update.

# CodxLib 1.6.1 *This file is for **Forge 1.20.6**. Every loader ships the same CodxLib version, so the notes below apply here too.* **Minecraft 26.3 support. Nothing else changed.** CodxLib now ships for **Minecraft 26.3** on **Fabric** and **NeoForge**. There is no Forge build for 26.3 yet — Forge has not released one — so it will be added here if and when it ships. Every other version is byte-for-byte the same library as 1.6.0: no API changes, no behaviour changes, nothing to do on your side. If you are not playing 26.3, there is no reason to update.

# CodxLib 1.6.1 *This file is for **Fabric 1.20.6**. It requires **Fabric Loader 0.15.6 or newer** — exactly what Fabric API already needs on 1.20.6, so CodxLib adds no restriction of its own — and **Fabric API 0.100.8+1.20.6 or newer**.* **Minecraft 26.3 support. Nothing else changed.** CodxLib now ships for **Minecraft 26.3** on **Fabric** and **NeoForge**. There is no Forge build for 26.3 yet — Forge has not released one — so it will be added here if and when it ships. Every other version is byte-for-byte the same library as 1.6.0: no API changes, no behaviour changes, nothing to do on your side. If you are not playing 26.3, there is no reason to update.

# CodxLib 1.6.1 *This file is for **Fabric 1.20.5**. It requires **Fabric Loader 0.15.6 or newer** — exactly what Fabric API already needs on 1.20.5, so CodxLib adds no restriction of its own — and **Fabric API 0.97.8+1.20.5 or newer**.* **Minecraft 26.3 support. Nothing else changed.** CodxLib now ships for **Minecraft 26.3** on **Fabric** and **NeoForge**. There is no Forge build for 26.3 yet — Forge has not released one — so it will be added here if and when it ships. Every other version is byte-for-byte the same library as 1.6.0: no API changes, no behaviour changes, nothing to do on your side. If you are not playing 26.3, there is no reason to update.

# CodxLib 1.6.1 *This file is for **NeoForge 1.20.4**. Every loader ships the same CodxLib version, so the notes below apply here too.* **Minecraft 26.3 support. Nothing else changed.** CodxLib now ships for **Minecraft 26.3** on **Fabric** and **NeoForge**. There is no Forge build for 26.3 yet — Forge has not released one — so it will be added here if and when it ships. Every other version is byte-for-byte the same library as 1.6.0: no API changes, no behaviour changes, nothing to do on your side. If you are not playing 26.3, there is no reason to update.

# CodxLib 1.6.1 *This file is for **Forge 1.20.4**. Every loader ships the same CodxLib version, so the notes below apply here too.* **Minecraft 26.3 support. Nothing else changed.** CodxLib now ships for **Minecraft 26.3** on **Fabric** and **NeoForge**. There is no Forge build for 26.3 yet — Forge has not released one — so it will be added here if and when it ships. Every other version is byte-for-byte the same library as 1.6.0: no API changes, no behaviour changes, nothing to do on your side. If you are not playing 26.3, there is no reason to update.

# CodxLib 1.6.1 *This file is for **Fabric 1.20.4**. It requires **Fabric Loader 0.15.1 or newer** — exactly what Fabric API already needs on 1.20.4, so CodxLib adds no restriction of its own — and **Fabric API 0.97.3+1.20.4 or newer**.* **Minecraft 26.3 support. Nothing else changed.** CodxLib now ships for **Minecraft 26.3** on **Fabric** and **NeoForge**. There is no Forge build for 26.3 yet — Forge has not released one — so it will be added here if and when it ships. Every other version is byte-for-byte the same library as 1.6.0: no API changes, no behaviour changes, nothing to do on your side. If you are not playing 26.3, there is no reason to update.

# CodxLib 1.6.1 *This file is for **Fabric 1.20.3**. It requires **Fabric Loader 0.14.23 or newer** — exactly what Fabric API already needs on 1.20.3, so CodxLib adds no restriction of its own — and **Fabric API 0.91.1+1.20.3 or newer**.* **Minecraft 26.3 support. Nothing else changed.** CodxLib now ships for **Minecraft 26.3** on **Fabric** and **NeoForge**. There is no Forge build for 26.3 yet — Forge has not released one — so it will be added here if and when it ships. Every other version is byte-for-byte the same library as 1.6.0: no API changes, no behaviour changes, nothing to do on your side. If you are not playing 26.3, there is no reason to update.

# CodxLib 1.6.1 *This file is for **Fabric 1.20.2**. It requires **Fabric Loader 0.14.22 or newer** — exactly what Fabric API already needs on 1.20.2, so CodxLib adds no restriction of its own — and **Fabric API 0.91.6+1.20.2 or newer**.* **Minecraft 26.3 support. Nothing else changed.** CodxLib now ships for **Minecraft 26.3** on **Fabric** and **NeoForge**. There is no Forge build for 26.3 yet — Forge has not released one — so it will be added here if and when it ships. Every other version is byte-for-byte the same library as 1.6.0: no API changes, no behaviour changes, nothing to do on your side. If you are not playing 26.3, there is no reason to update.

# CodxLib 1.6.1 *This file is for **Forge 1.20.1**. Every loader ships the same CodxLib version, so the notes below apply here too.* **Minecraft 26.3 support. Nothing else changed.** CodxLib now ships for **Minecraft 26.3** on **Fabric** and **NeoForge**. There is no Forge build for 26.3 yet — Forge has not released one — so it will be added here if and when it ships. Every other version is byte-for-byte the same library as 1.6.0: no API changes, no behaviour changes, nothing to do on your side. If you are not playing 26.3, there is no reason to update.

# CodxLib 1.6.1 *This file is for **Fabric 26.3**. It requires **Fabric Loader 0.19.3 or newer** — exactly what Fabric API already needs on 26.3, so CodxLib adds no restriction of its own — and **Fabric API 0.160.5+26.3 or newer**.* **Minecraft 26.3 support. Nothing else changed.** CodxLib now ships for **Minecraft 26.3** on **Fabric** and **NeoForge**. There is no Forge build for 26.3 yet — Forge has not released one — so it will be added here if and when it ships. Every other version is byte-for-byte the same library as 1.6.0: no API changes, no behaviour changes, nothing to do on your side. If you are not playing 26.3, there is no reason to update.

# CodxLib 1.6.1 *This file is for **Fabric 1.20.1**. It requires **Fabric Loader 0.16.10 or newer** — exactly what Fabric API already needs on 1.20.1, so CodxLib adds no restriction of its own — and **Fabric API 0.92.8+1.20.1 or newer**.* **Minecraft 26.3 support. Nothing else changed.** CodxLib now ships for **Minecraft 26.3** on **Fabric** and **NeoForge**. There is no Forge build for 26.3 yet — Forge has not released one — so it will be added here if and when it ships. Every other version is byte-for-byte the same library as 1.6.0: no API changes, no behaviour changes, nothing to do on your side. If you are not playing 26.3, there is no reason to update.

# CodxLib 1.6.0 *This file is for **NeoForge 26.2**. Every loader ships the same CodxLib version, so the notes below apply here too.* **A settings menu fix everyone should take, and a new hook for mod authors.** ## Fixed: number settings in the chest menu jumped to their maximum Clicking + or − on any numeric setting in a `/<mod> menu` screen added the new value on top of the old one instead of replacing it, so two or three clicks pinned the setting to its ceiling no matter which button you pressed. Sliders were fine; the +/− tiles were not. This affected every mod that uses CodxLib's settings menu, so if you have edited a number that way, it is worth checking what it actually says now. ## New: a mod can put its own page behind one setting Lists and text settings could only be shown read-only in the chest menu, because there is no keyboard in a chest UI. Mods can now hand a single setting a page of their own, so a list of entity ids and numbers can be presented as a row of buttons instead of a line of text pointing at the config file. Alex's Mobs Continued uses it for its new spawn group size editor. Ungrouped settings in a category also now come before the group buttons rather than after them, so a setting that belongs to the category as a whole is on the first page instead of the last.

# CodxLib 1.6.0 *This file is for **Forge 26.2**. Every loader ships the same CodxLib version, so the notes below apply here too.* **A settings menu fix everyone should take, and a new hook for mod authors.** ## Fixed: number settings in the chest menu jumped to their maximum Clicking + or − on any numeric setting in a `/<mod> menu` screen added the new value on top of the old one instead of replacing it, so two or three clicks pinned the setting to its ceiling no matter which button you pressed. Sliders were fine; the +/− tiles were not. This affected every mod that uses CodxLib's settings menu, so if you have edited a number that way, it is worth checking what it actually says now. ## New: a mod can put its own page behind one setting Lists and text settings could only be shown read-only in the chest menu, because there is no keyboard in a chest UI. Mods can now hand a single setting a page of their own, so a list of entity ids and numbers can be presented as a row of buttons instead of a line of text pointing at the config file. Alex's Mobs Continued uses it for its new spawn group size editor. Ungrouped settings in a category also now come before the group buttons rather than after them, so a setting that belongs to the category as a whole is on the first page instead of the last.

# CodxLib 1.6.0 *This file is for **NeoForge 26.1.2**. Every loader ships the same CodxLib version, so the notes below apply here too.* **A settings menu fix everyone should take, and a new hook for mod authors.** ## Fixed: number settings in the chest menu jumped to their maximum Clicking + or − on any numeric setting in a `/<mod> menu` screen added the new value on top of the old one instead of replacing it, so two or three clicks pinned the setting to its ceiling no matter which button you pressed. Sliders were fine; the +/− tiles were not. This affected every mod that uses CodxLib's settings menu, so if you have edited a number that way, it is worth checking what it actually says now. ## New: a mod can put its own page behind one setting Lists and text settings could only be shown read-only in the chest menu, because there is no keyboard in a chest UI. Mods can now hand a single setting a page of their own, so a list of entity ids and numbers can be presented as a row of buttons instead of a line of text pointing at the config file. Alex's Mobs Continued uses it for its new spawn group size editor. Ungrouped settings in a category also now come before the group buttons rather than after them, so a setting that belongs to the category as a whole is on the first page instead of the last.

# CodxLib 1.6.0 *This file is for **Forge 26.1.2**. Every loader ships the same CodxLib version, so the notes below apply here too.* **A settings menu fix everyone should take, and a new hook for mod authors.** ## Fixed: number settings in the chest menu jumped to their maximum Clicking + or − on any numeric setting in a `/<mod> menu` screen added the new value on top of the old one instead of replacing it, so two or three clicks pinned the setting to its ceiling no matter which button you pressed. Sliders were fine; the +/− tiles were not. This affected every mod that uses CodxLib's settings menu, so if you have edited a number that way, it is worth checking what it actually says now. ## New: a mod can put its own page behind one setting Lists and text settings could only be shown read-only in the chest menu, because there is no keyboard in a chest UI. Mods can now hand a single setting a page of their own, so a list of entity ids and numbers can be presented as a row of buttons instead of a line of text pointing at the config file. Alex's Mobs Continued uses it for its new spawn group size editor. Ungrouped settings in a category also now come before the group buttons rather than after them, so a setting that belongs to the category as a whole is on the first page instead of the last.

# CodxLib 1.6.0 *This file is for **Fabric 26.1.2**. It requires **Fabric Loader 0.18.4 or newer** — exactly what Fabric API already needs on 26.1.2, so CodxLib adds no restriction of its own — and **Fabric API 0.145.4+26.1.2 or newer**.* **A settings menu fix everyone should take, and a new hook for mod authors.** ## Fixed: number settings in the chest menu jumped to their maximum Clicking + or − on any numeric setting in a `/<mod> menu` screen added the new value on top of the old one instead of replacing it, so two or three clicks pinned the setting to its ceiling no matter which button you pressed. Sliders were fine; the +/− tiles were not. This affected every mod that uses CodxLib's settings menu, so if you have edited a number that way, it is worth checking what it actually says now. ## New: a mod can put its own page behind one setting Lists and text settings could only be shown read-only in the chest menu, because there is no keyboard in a chest UI. Mods can now hand a single setting a page of their own, so a list of entity ids and numbers can be presented as a row of buttons instead of a line of text pointing at the config file. Alex's Mobs Continued uses it for its new spawn group size editor. Ungrouped settings in a category also now come before the group buttons rather than after them, so a setting that belongs to the category as a whole is on the first page instead of the last.

# CodxLib 1.6.0 *This file is for **NeoForge 26.1.1**. Every loader ships the same CodxLib version, so the notes below apply here too.* **A settings menu fix everyone should take, and a new hook for mod authors.** ## Fixed: number settings in the chest menu jumped to their maximum Clicking + or − on any numeric setting in a `/<mod> menu` screen added the new value on top of the old one instead of replacing it, so two or three clicks pinned the setting to its ceiling no matter which button you pressed. Sliders were fine; the +/− tiles were not. This affected every mod that uses CodxLib's settings menu, so if you have edited a number that way, it is worth checking what it actually says now. ## New: a mod can put its own page behind one setting Lists and text settings could only be shown read-only in the chest menu, because there is no keyboard in a chest UI. Mods can now hand a single setting a page of their own, so a list of entity ids and numbers can be presented as a row of buttons instead of a line of text pointing at the config file. Alex's Mobs Continued uses it for its new spawn group size editor. Ungrouped settings in a category also now come before the group buttons rather than after them, so a setting that belongs to the category as a whole is on the first page instead of the last.

# CodxLib 1.6.0 *This file is for **Forge 26.1.1**. Every loader ships the same CodxLib version, so the notes below apply here too.* **A settings menu fix everyone should take, and a new hook for mod authors.** ## Fixed: number settings in the chest menu jumped to their maximum Clicking + or − on any numeric setting in a `/<mod> menu` screen added the new value on top of the old one instead of replacing it, so two or three clicks pinned the setting to its ceiling no matter which button you pressed. Sliders were fine; the +/− tiles were not. This affected every mod that uses CodxLib's settings menu, so if you have edited a number that way, it is worth checking what it actually says now. ## New: a mod can put its own page behind one setting Lists and text settings could only be shown read-only in the chest menu, because there is no keyboard in a chest UI. Mods can now hand a single setting a page of their own, so a list of entity ids and numbers can be presented as a row of buttons instead of a line of text pointing at the config file. Alex's Mobs Continued uses it for its new spawn group size editor. Ungrouped settings in a category also now come before the group buttons rather than after them, so a setting that belongs to the category as a whole is on the first page instead of the last.

# CodxLib 1.6.0 *This file is for **Fabric 26.1.1**. It requires **Fabric Loader 0.18.4 or newer** — exactly what Fabric API already needs on 26.1.1, so CodxLib adds no restriction of its own — and **Fabric API 0.145.4+26.1.1 or newer**.* **A settings menu fix everyone should take, and a new hook for mod authors.** ## Fixed: number settings in the chest menu jumped to their maximum Clicking + or − on any numeric setting in a `/<mod> menu` screen added the new value on top of the old one instead of replacing it, so two or three clicks pinned the setting to its ceiling no matter which button you pressed. Sliders were fine; the +/− tiles were not. This affected every mod that uses CodxLib's settings menu, so if you have edited a number that way, it is worth checking what it actually says now. ## New: a mod can put its own page behind one setting Lists and text settings could only be shown read-only in the chest menu, because there is no keyboard in a chest UI. Mods can now hand a single setting a page of their own, so a list of entity ids and numbers can be presented as a row of buttons instead of a line of text pointing at the config file. Alex's Mobs Continued uses it for its new spawn group size editor. Ungrouped settings in a category also now come before the group buttons rather than after them, so a setting that belongs to the category as a whole is on the first page instead of the last.

# CodxLib 1.6.0 *This file is for **NeoForge 26.1**. Every loader ships the same CodxLib version, so the notes below apply here too.* **A settings menu fix everyone should take, and a new hook for mod authors.** ## Fixed: number settings in the chest menu jumped to their maximum Clicking + or − on any numeric setting in a `/<mod> menu` screen added the new value on top of the old one instead of replacing it, so two or three clicks pinned the setting to its ceiling no matter which button you pressed. Sliders were fine; the +/− tiles were not. This affected every mod that uses CodxLib's settings menu, so if you have edited a number that way, it is worth checking what it actually says now. ## New: a mod can put its own page behind one setting Lists and text settings could only be shown read-only in the chest menu, because there is no keyboard in a chest UI. Mods can now hand a single setting a page of their own, so a list of entity ids and numbers can be presented as a row of buttons instead of a line of text pointing at the config file. Alex's Mobs Continued uses it for its new spawn group size editor. Ungrouped settings in a category also now come before the group buttons rather than after them, so a setting that belongs to the category as a whole is on the first page instead of the last.

# CodxLib 1.6.0 *This file is for **Forge 26.1**. Every loader ships the same CodxLib version, so the notes below apply here too.* **A settings menu fix everyone should take, and a new hook for mod authors.** ## Fixed: number settings in the chest menu jumped to their maximum Clicking + or − on any numeric setting in a `/<mod> menu` screen added the new value on top of the old one instead of replacing it, so two or three clicks pinned the setting to its ceiling no matter which button you pressed. Sliders were fine; the +/− tiles were not. This affected every mod that uses CodxLib's settings menu, so if you have edited a number that way, it is worth checking what it actually says now. ## New: a mod can put its own page behind one setting Lists and text settings could only be shown read-only in the chest menu, because there is no keyboard in a chest UI. Mods can now hand a single setting a page of their own, so a list of entity ids and numbers can be presented as a row of buttons instead of a line of text pointing at the config file. Alex's Mobs Continued uses it for its new spawn group size editor. Ungrouped settings in a category also now come before the group buttons rather than after them, so a setting that belongs to the category as a whole is on the first page instead of the last.

# CodxLib 1.6.0 *This file is for **Fabric 26.1**. It requires **Fabric Loader 0.18.4 or newer** — exactly what Fabric API already needs on 26.1, so CodxLib adds no restriction of its own — and **Fabric API 0.145.1+26.1 or newer**.* **A settings menu fix everyone should take, and a new hook for mod authors.** ## Fixed: number settings in the chest menu jumped to their maximum Clicking + or − on any numeric setting in a `/<mod> menu` screen added the new value on top of the old one instead of replacing it, so two or three clicks pinned the setting to its ceiling no matter which button you pressed. Sliders were fine; the +/− tiles were not. This affected every mod that uses CodxLib's settings menu, so if you have edited a number that way, it is worth checking what it actually says now. ## New: a mod can put its own page behind one setting Lists and text settings could only be shown read-only in the chest menu, because there is no keyboard in a chest UI. Mods can now hand a single setting a page of their own, so a list of entity ids and numbers can be presented as a row of buttons instead of a line of text pointing at the config file. Alex's Mobs Continued uses it for its new spawn group size editor. Ungrouped settings in a category also now come before the group buttons rather than after them, so a setting that belongs to the category as a whole is on the first page instead of the last.

# CodxLib 1.6.0 *This file is for **NeoForge 1.21.11**. Every loader ships the same CodxLib version, so the notes below apply here too.* **A settings menu fix everyone should take, and a new hook for mod authors.** ## Fixed: number settings in the chest menu jumped to their maximum Clicking + or − on any numeric setting in a `/<mod> menu` screen added the new value on top of the old one instead of replacing it, so two or three clicks pinned the setting to its ceiling no matter which button you pressed. Sliders were fine; the +/− tiles were not. This affected every mod that uses CodxLib's settings menu, so if you have edited a number that way, it is worth checking what it actually says now. ## New: a mod can put its own page behind one setting Lists and text settings could only be shown read-only in the chest menu, because there is no keyboard in a chest UI. Mods can now hand a single setting a page of their own, so a list of entity ids and numbers can be presented as a row of buttons instead of a line of text pointing at the config file. Alex's Mobs Continued uses it for its new spawn group size editor. Ungrouped settings in a category also now come before the group buttons rather than after them, so a setting that belongs to the category as a whole is on the first page instead of the last.

# CodxLib 1.6.0 *This file is for **Forge 1.21.11**. Every loader ships the same CodxLib version, so the notes below apply here too.* **A settings menu fix everyone should take, and a new hook for mod authors.** ## Fixed: number settings in the chest menu jumped to their maximum Clicking + or − on any numeric setting in a `/<mod> menu` screen added the new value on top of the old one instead of replacing it, so two or three clicks pinned the setting to its ceiling no matter which button you pressed. Sliders were fine; the +/− tiles were not. This affected every mod that uses CodxLib's settings menu, so if you have edited a number that way, it is worth checking what it actually says now. ## New: a mod can put its own page behind one setting Lists and text settings could only be shown read-only in the chest menu, because there is no keyboard in a chest UI. Mods can now hand a single setting a page of their own, so a list of entity ids and numbers can be presented as a row of buttons instead of a line of text pointing at the config file. Alex's Mobs Continued uses it for its new spawn group size editor. Ungrouped settings in a category also now come before the group buttons rather than after them, so a setting that belongs to the category as a whole is on the first page instead of the last.

# CodxLib 1.6.0 *This file is for **Fabric 1.21.11**. It requires **Fabric Loader 0.17.3 or newer** — exactly what Fabric API already needs on 1.21.11, so CodxLib adds no restriction of its own — and **Fabric API 0.141.5+1.21.11 or newer**.* **A settings menu fix everyone should take, and a new hook for mod authors.** ## Fixed: number settings in the chest menu jumped to their maximum Clicking + or − on any numeric setting in a `/<mod> menu` screen added the new value on top of the old one instead of replacing it, so two or three clicks pinned the setting to its ceiling no matter which button you pressed. Sliders were fine; the +/− tiles were not. This affected every mod that uses CodxLib's settings menu, so if you have edited a number that way, it is worth checking what it actually says now. ## New: a mod can put its own page behind one setting Lists and text settings could only be shown read-only in the chest menu, because there is no keyboard in a chest UI. Mods can now hand a single setting a page of their own, so a list of entity ids and numbers can be presented as a row of buttons instead of a line of text pointing at the config file. Alex's Mobs Continued uses it for its new spawn group size editor. Ungrouped settings in a category also now come before the group buttons rather than after them, so a setting that belongs to the category as a whole is on the first page instead of the last.

# CodxLib 1.6.0 *This file is for **NeoForge 1.21.10**. Every loader ships the same CodxLib version, so the notes below apply here too.* **A settings menu fix everyone should take, and a new hook for mod authors.** ## Fixed: number settings in the chest menu jumped to their maximum Clicking + or − on any numeric setting in a `/<mod> menu` screen added the new value on top of the old one instead of replacing it, so two or three clicks pinned the setting to its ceiling no matter which button you pressed. Sliders were fine; the +/− tiles were not. This affected every mod that uses CodxLib's settings menu, so if you have edited a number that way, it is worth checking what it actually says now. ## New: a mod can put its own page behind one setting Lists and text settings could only be shown read-only in the chest menu, because there is no keyboard in a chest UI. Mods can now hand a single setting a page of their own, so a list of entity ids and numbers can be presented as a row of buttons instead of a line of text pointing at the config file. Alex's Mobs Continued uses it for its new spawn group size editor. Ungrouped settings in a category also now come before the group buttons rather than after them, so a setting that belongs to the category as a whole is on the first page instead of the last.

# CodxLib 1.6.0 *This file is for **Forge 1.21.10**. Every loader ships the same CodxLib version, so the notes below apply here too.* **A settings menu fix everyone should take, and a new hook for mod authors.** ## Fixed: number settings in the chest menu jumped to their maximum Clicking + or − on any numeric setting in a `/<mod> menu` screen added the new value on top of the old one instead of replacing it, so two or three clicks pinned the setting to its ceiling no matter which button you pressed. Sliders were fine; the +/− tiles were not. This affected every mod that uses CodxLib's settings menu, so if you have edited a number that way, it is worth checking what it actually says now. ## New: a mod can put its own page behind one setting Lists and text settings could only be shown read-only in the chest menu, because there is no keyboard in a chest UI. Mods can now hand a single setting a page of their own, so a list of entity ids and numbers can be presented as a row of buttons instead of a line of text pointing at the config file. Alex's Mobs Continued uses it for its new spawn group size editor. Ungrouped settings in a category also now come before the group buttons rather than after them, so a setting that belongs to the category as a whole is on the first page instead of the last.

# CodxLib 1.6.0 *This file is for **Fabric 1.21.10**. It requires **Fabric Loader 0.17.0 or newer** — exactly what Fabric API already needs on 1.21.10, so CodxLib adds no restriction of its own — and **Fabric API 0.138.4+1.21.10 or newer**.* **A settings menu fix everyone should take, and a new hook for mod authors.** ## Fixed: number settings in the chest menu jumped to their maximum Clicking + or − on any numeric setting in a `/<mod> menu` screen added the new value on top of the old one instead of replacing it, so two or three clicks pinned the setting to its ceiling no matter which button you pressed. Sliders were fine; the +/− tiles were not. This affected every mod that uses CodxLib's settings menu, so if you have edited a number that way, it is worth checking what it actually says now. ## New: a mod can put its own page behind one setting Lists and text settings could only be shown read-only in the chest menu, because there is no keyboard in a chest UI. Mods can now hand a single setting a page of their own, so a list of entity ids and numbers can be presented as a row of buttons instead of a line of text pointing at the config file. Alex's Mobs Continued uses it for its new spawn group size editor. Ungrouped settings in a category also now come before the group buttons rather than after them, so a setting that belongs to the category as a whole is on the first page instead of the last.

# CodxLib 1.6.0 *This file is for **NeoForge 1.21.9**. Every loader ships the same CodxLib version, so the notes below apply here too.* **A settings menu fix everyone should take, and a new hook for mod authors.** ## Fixed: number settings in the chest menu jumped to their maximum Clicking + or − on any numeric setting in a `/<mod> menu` screen added the new value on top of the old one instead of replacing it, so two or three clicks pinned the setting to its ceiling no matter which button you pressed. Sliders were fine; the +/− tiles were not. This affected every mod that uses CodxLib's settings menu, so if you have edited a number that way, it is worth checking what it actually says now. ## New: a mod can put its own page behind one setting Lists and text settings could only be shown read-only in the chest menu, because there is no keyboard in a chest UI. Mods can now hand a single setting a page of their own, so a list of entity ids and numbers can be presented as a row of buttons instead of a line of text pointing at the config file. Alex's Mobs Continued uses it for its new spawn group size editor. Ungrouped settings in a category also now come before the group buttons rather than after them, so a setting that belongs to the category as a whole is on the first page instead of the last.

# CodxLib 1.6.0 *This file is for **Forge 1.21.9**. Every loader ships the same CodxLib version, so the notes below apply here too.* **A settings menu fix everyone should take, and a new hook for mod authors.** ## Fixed: number settings in the chest menu jumped to their maximum Clicking + or − on any numeric setting in a `/<mod> menu` screen added the new value on top of the old one instead of replacing it, so two or three clicks pinned the setting to its ceiling no matter which button you pressed. Sliders were fine; the +/− tiles were not. This affected every mod that uses CodxLib's settings menu, so if you have edited a number that way, it is worth checking what it actually says now. ## New: a mod can put its own page behind one setting Lists and text settings could only be shown read-only in the chest menu, because there is no keyboard in a chest UI. Mods can now hand a single setting a page of their own, so a list of entity ids and numbers can be presented as a row of buttons instead of a line of text pointing at the config file. Alex's Mobs Continued uses it for its new spawn group size editor. Ungrouped settings in a category also now come before the group buttons rather than after them, so a setting that belongs to the category as a whole is on the first page instead of the last.

# CodxLib 1.6.0 *This file is for **Fabric 1.21.9**. It requires **Fabric Loader 0.17.0 or newer** — exactly what Fabric API already needs on 1.21.9, so CodxLib adds no restriction of its own — and **Fabric API 0.134.1+1.21.9 or newer**.* **A settings menu fix everyone should take, and a new hook for mod authors.** ## Fixed: number settings in the chest menu jumped to their maximum Clicking + or − on any numeric setting in a `/<mod> menu` screen added the new value on top of the old one instead of replacing it, so two or three clicks pinned the setting to its ceiling no matter which button you pressed. Sliders were fine; the +/− tiles were not. This affected every mod that uses CodxLib's settings menu, so if you have edited a number that way, it is worth checking what it actually says now. ## New: a mod can put its own page behind one setting Lists and text settings could only be shown read-only in the chest menu, because there is no keyboard in a chest UI. Mods can now hand a single setting a page of their own, so a list of entity ids and numbers can be presented as a row of buttons instead of a line of text pointing at the config file. Alex's Mobs Continued uses it for its new spawn group size editor. Ungrouped settings in a category also now come before the group buttons rather than after them, so a setting that belongs to the category as a whole is on the first page instead of the last.

# CodxLib 1.6.0 *This file is for **NeoForge 1.21.8**. Every loader ships the same CodxLib version, so the notes below apply here too.* **A settings menu fix everyone should take, and a new hook for mod authors.** ## Fixed: number settings in the chest menu jumped to their maximum Clicking + or − on any numeric setting in a `/<mod> menu` screen added the new value on top of the old one instead of replacing it, so two or three clicks pinned the setting to its ceiling no matter which button you pressed. Sliders were fine; the +/− tiles were not. This affected every mod that uses CodxLib's settings menu, so if you have edited a number that way, it is worth checking what it actually says now. ## New: a mod can put its own page behind one setting Lists and text settings could only be shown read-only in the chest menu, because there is no keyboard in a chest UI. Mods can now hand a single setting a page of their own, so a list of entity ids and numbers can be presented as a row of buttons instead of a line of text pointing at the config file. Alex's Mobs Continued uses it for its new spawn group size editor. Ungrouped settings in a category also now come before the group buttons rather than after them, so a setting that belongs to the category as a whole is on the first page instead of the last.

# CodxLib 1.6.0 *This file is for **Forge 1.21.8**. Every loader ships the same CodxLib version, so the notes below apply here too.* **A settings menu fix everyone should take, and a new hook for mod authors.** ## Fixed: number settings in the chest menu jumped to their maximum Clicking + or − on any numeric setting in a `/<mod> menu` screen added the new value on top of the old one instead of replacing it, so two or three clicks pinned the setting to its ceiling no matter which button you pressed. Sliders were fine; the +/− tiles were not. This affected every mod that uses CodxLib's settings menu, so if you have edited a number that way, it is worth checking what it actually says now. ## New: a mod can put its own page behind one setting Lists and text settings could only be shown read-only in the chest menu, because there is no keyboard in a chest UI. Mods can now hand a single setting a page of their own, so a list of entity ids and numbers can be presented as a row of buttons instead of a line of text pointing at the config file. Alex's Mobs Continued uses it for its new spawn group size editor. Ungrouped settings in a category also now come before the group buttons rather than after them, so a setting that belongs to the category as a whole is on the first page instead of the last.

# CodxLib 1.6.0 *This file is for **Fabric 1.21.8**. It requires **Fabric Loader 0.16.13 or newer** — exactly what Fabric API already needs on 1.21.8, so CodxLib adds no restriction of its own — and **Fabric API 0.136.1+1.21.8 or newer**.* **A settings menu fix everyone should take, and a new hook for mod authors.** ## Fixed: number settings in the chest menu jumped to their maximum Clicking + or − on any numeric setting in a `/<mod> menu` screen added the new value on top of the old one instead of replacing it, so two or three clicks pinned the setting to its ceiling no matter which button you pressed. Sliders were fine; the +/− tiles were not. This affected every mod that uses CodxLib's settings menu, so if you have edited a number that way, it is worth checking what it actually says now. ## New: a mod can put its own page behind one setting Lists and text settings could only be shown read-only in the chest menu, because there is no keyboard in a chest UI. Mods can now hand a single setting a page of their own, so a list of entity ids and numbers can be presented as a row of buttons instead of a line of text pointing at the config file. Alex's Mobs Continued uses it for its new spawn group size editor. Ungrouped settings in a category also now come before the group buttons rather than after them, so a setting that belongs to the category as a whole is on the first page instead of the last.

# CodxLib 1.6.0 *This file is for **NeoForge 1.21.7**. Every loader ships the same CodxLib version, so the notes below apply here too.* **A settings menu fix everyone should take, and a new hook for mod authors.** ## Fixed: number settings in the chest menu jumped to their maximum Clicking + or − on any numeric setting in a `/<mod> menu` screen added the new value on top of the old one instead of replacing it, so two or three clicks pinned the setting to its ceiling no matter which button you pressed. Sliders were fine; the +/− tiles were not. This affected every mod that uses CodxLib's settings menu, so if you have edited a number that way, it is worth checking what it actually says now. ## New: a mod can put its own page behind one setting Lists and text settings could only be shown read-only in the chest menu, because there is no keyboard in a chest UI. Mods can now hand a single setting a page of their own, so a list of entity ids and numbers can be presented as a row of buttons instead of a line of text pointing at the config file. Alex's Mobs Continued uses it for its new spawn group size editor. Ungrouped settings in a category also now come before the group buttons rather than after them, so a setting that belongs to the category as a whole is on the first page instead of the last.

# CodxLib 1.6.0 *This file is for **Forge 1.21.7**. Every loader ships the same CodxLib version, so the notes below apply here too.* **A settings menu fix everyone should take, and a new hook for mod authors.** ## Fixed: number settings in the chest menu jumped to their maximum Clicking + or − on any numeric setting in a `/<mod> menu` screen added the new value on top of the old one instead of replacing it, so two or three clicks pinned the setting to its ceiling no matter which button you pressed. Sliders were fine; the +/− tiles were not. This affected every mod that uses CodxLib's settings menu, so if you have edited a number that way, it is worth checking what it actually says now. ## New: a mod can put its own page behind one setting Lists and text settings could only be shown read-only in the chest menu, because there is no keyboard in a chest UI. Mods can now hand a single setting a page of their own, so a list of entity ids and numbers can be presented as a row of buttons instead of a line of text pointing at the config file. Alex's Mobs Continued uses it for its new spawn group size editor. Ungrouped settings in a category also now come before the group buttons rather than after them, so a setting that belongs to the category as a whole is on the first page instead of the last.

# CodxLib 1.6.0 *This file is for **Fabric 1.21.7**. It requires **Fabric Loader 0.16.13 or newer** — exactly what Fabric API already needs on 1.21.7, so CodxLib adds no restriction of its own — and **Fabric API 0.129.0+1.21.7 or newer**.* **A settings menu fix everyone should take, and a new hook for mod authors.** ## Fixed: number settings in the chest menu jumped to their maximum Clicking + or − on any numeric setting in a `/<mod> menu` screen added the new value on top of the old one instead of replacing it, so two or three clicks pinned the setting to its ceiling no matter which button you pressed. Sliders were fine; the +/− tiles were not. This affected every mod that uses CodxLib's settings menu, so if you have edited a number that way, it is worth checking what it actually says now. ## New: a mod can put its own page behind one setting Lists and text settings could only be shown read-only in the chest menu, because there is no keyboard in a chest UI. Mods can now hand a single setting a page of their own, so a list of entity ids and numbers can be presented as a row of buttons instead of a line of text pointing at the config file. Alex's Mobs Continued uses it for its new spawn group size editor. Ungrouped settings in a category also now come before the group buttons rather than after them, so a setting that belongs to the category as a whole is on the first page instead of the last.

# CodxLib 1.6.0 *This file is for **NeoForge 1.21.6**. Every loader ships the same CodxLib version, so the notes below apply here too.* **A settings menu fix everyone should take, and a new hook for mod authors.** ## Fixed: number settings in the chest menu jumped to their maximum Clicking + or − on any numeric setting in a `/<mod> menu` screen added the new value on top of the old one instead of replacing it, so two or three clicks pinned the setting to its ceiling no matter which button you pressed. Sliders were fine; the +/− tiles were not. This affected every mod that uses CodxLib's settings menu, so if you have edited a number that way, it is worth checking what it actually says now. ## New: a mod can put its own page behind one setting Lists and text settings could only be shown read-only in the chest menu, because there is no keyboard in a chest UI. Mods can now hand a single setting a page of their own, so a list of entity ids and numbers can be presented as a row of buttons instead of a line of text pointing at the config file. Alex's Mobs Continued uses it for its new spawn group size editor. Ungrouped settings in a category also now come before the group buttons rather than after them, so a setting that belongs to the category as a whole is on the first page instead of the last.

# CodxLib 1.6.0 *This file is for **Forge 1.21.6**. Every loader ships the same CodxLib version, so the notes below apply here too.* **A settings menu fix everyone should take, and a new hook for mod authors.** ## Fixed: number settings in the chest menu jumped to their maximum Clicking + or − on any numeric setting in a `/<mod> menu` screen added the new value on top of the old one instead of replacing it, so two or three clicks pinned the setting to its ceiling no matter which button you pressed. Sliders were fine; the +/− tiles were not. This affected every mod that uses CodxLib's settings menu, so if you have edited a number that way, it is worth checking what it actually says now. ## New: a mod can put its own page behind one setting Lists and text settings could only be shown read-only in the chest menu, because there is no keyboard in a chest UI. Mods can now hand a single setting a page of their own, so a list of entity ids and numbers can be presented as a row of buttons instead of a line of text pointing at the config file. Alex's Mobs Continued uses it for its new spawn group size editor. Ungrouped settings in a category also now come before the group buttons rather than after them, so a setting that belongs to the category as a whole is on the first page instead of the last.

# CodxLib 1.6.0 *This file is for **Fabric 1.21.6**. It requires **Fabric Loader 0.16.13 or newer** — exactly what Fabric API already needs on 1.21.6, so CodxLib adds no restriction of its own — and **Fabric API 0.128.2+1.21.6 or newer**.* **A settings menu fix everyone should take, and a new hook for mod authors.** ## Fixed: number settings in the chest menu jumped to their maximum Clicking + or − on any numeric setting in a `/<mod> menu` screen added the new value on top of the old one instead of replacing it, so two or three clicks pinned the setting to its ceiling no matter which button you pressed. Sliders were fine; the +/− tiles were not. This affected every mod that uses CodxLib's settings menu, so if you have edited a number that way, it is worth checking what it actually says now. ## New: a mod can put its own page behind one setting Lists and text settings could only be shown read-only in the chest menu, because there is no keyboard in a chest UI. Mods can now hand a single setting a page of their own, so a list of entity ids and numbers can be presented as a row of buttons instead of a line of text pointing at the config file. Alex's Mobs Continued uses it for its new spawn group size editor. Ungrouped settings in a category also now come before the group buttons rather than after them, so a setting that belongs to the category as a whole is on the first page instead of the last.

# CodxLib 1.6.0 *This file is for **NeoForge 1.21.5**. Every loader ships the same CodxLib version, so the notes below apply here too.* **A settings menu fix everyone should take, and a new hook for mod authors.** ## Fixed: number settings in the chest menu jumped to their maximum Clicking + or − on any numeric setting in a `/<mod> menu` screen added the new value on top of the old one instead of replacing it, so two or three clicks pinned the setting to its ceiling no matter which button you pressed. Sliders were fine; the +/− tiles were not. This affected every mod that uses CodxLib's settings menu, so if you have edited a number that way, it is worth checking what it actually says now. ## New: a mod can put its own page behind one setting Lists and text settings could only be shown read-only in the chest menu, because there is no keyboard in a chest UI. Mods can now hand a single setting a page of their own, so a list of entity ids and numbers can be presented as a row of buttons instead of a line of text pointing at the config file. Alex's Mobs Continued uses it for its new spawn group size editor. Ungrouped settings in a category also now come before the group buttons rather than after them, so a setting that belongs to the category as a whole is on the first page instead of the last.

# CodxLib 1.6.0 *This file is for **Forge 1.21.5**. Every loader ships the same CodxLib version, so the notes below apply here too.* **A settings menu fix everyone should take, and a new hook for mod authors.** ## Fixed: number settings in the chest menu jumped to their maximum Clicking + or − on any numeric setting in a `/<mod> menu` screen added the new value on top of the old one instead of replacing it, so two or three clicks pinned the setting to its ceiling no matter which button you pressed. Sliders were fine; the +/− tiles were not. This affected every mod that uses CodxLib's settings menu, so if you have edited a number that way, it is worth checking what it actually says now. ## New: a mod can put its own page behind one setting Lists and text settings could only be shown read-only in the chest menu, because there is no keyboard in a chest UI. Mods can now hand a single setting a page of their own, so a list of entity ids and numbers can be presented as a row of buttons instead of a line of text pointing at the config file. Alex's Mobs Continued uses it for its new spawn group size editor. Ungrouped settings in a category also now come before the group buttons rather than after them, so a setting that belongs to the category as a whole is on the first page instead of the last.

# CodxLib 1.6.0 *This file is for **Fabric 1.21.5**. It requires **Fabric Loader 0.16.10 or newer** — exactly what Fabric API already needs on 1.21.5, so CodxLib adds no restriction of its own — and **Fabric API 0.128.2+1.21.5 or newer**.* **A settings menu fix everyone should take, and a new hook for mod authors.** ## Fixed: number settings in the chest menu jumped to their maximum Clicking + or − on any numeric setting in a `/<mod> menu` screen added the new value on top of the old one instead of replacing it, so two or three clicks pinned the setting to its ceiling no matter which button you pressed. Sliders were fine; the +/− tiles were not. This affected every mod that uses CodxLib's settings menu, so if you have edited a number that way, it is worth checking what it actually says now. ## New: a mod can put its own page behind one setting Lists and text settings could only be shown read-only in the chest menu, because there is no keyboard in a chest UI. Mods can now hand a single setting a page of their own, so a list of entity ids and numbers can be presented as a row of buttons instead of a line of text pointing at the config file. Alex's Mobs Continued uses it for its new spawn group size editor. Ungrouped settings in a category also now come before the group buttons rather than after them, so a setting that belongs to the category as a whole is on the first page instead of the last.

# CodxLib 1.6.0 *This file is for **NeoForge 1.21.4**. Every loader ships the same CodxLib version, so the notes below apply here too.* **A settings menu fix everyone should take, and a new hook for mod authors.** ## Fixed: number settings in the chest menu jumped to their maximum Clicking + or − on any numeric setting in a `/<mod> menu` screen added the new value on top of the old one instead of replacing it, so two or three clicks pinned the setting to its ceiling no matter which button you pressed. Sliders were fine; the +/− tiles were not. This affected every mod that uses CodxLib's settings menu, so if you have edited a number that way, it is worth checking what it actually says now. ## New: a mod can put its own page behind one setting Lists and text settings could only be shown read-only in the chest menu, because there is no keyboard in a chest UI. Mods can now hand a single setting a page of their own, so a list of entity ids and numbers can be presented as a row of buttons instead of a line of text pointing at the config file. Alex's Mobs Continued uses it for its new spawn group size editor. Ungrouped settings in a category also now come before the group buttons rather than after them, so a setting that belongs to the category as a whole is on the first page instead of the last.

# CodxLib 1.6.0 *This file is for **Forge 1.21.4**. Every loader ships the same CodxLib version, so the notes below apply here too.* **A settings menu fix everyone should take, and a new hook for mod authors.** ## Fixed: number settings in the chest menu jumped to their maximum Clicking + or − on any numeric setting in a `/<mod> menu` screen added the new value on top of the old one instead of replacing it, so two or three clicks pinned the setting to its ceiling no matter which button you pressed. Sliders were fine; the +/− tiles were not. This affected every mod that uses CodxLib's settings menu, so if you have edited a number that way, it is worth checking what it actually says now. ## New: a mod can put its own page behind one setting Lists and text settings could only be shown read-only in the chest menu, because there is no keyboard in a chest UI. Mods can now hand a single setting a page of their own, so a list of entity ids and numbers can be presented as a row of buttons instead of a line of text pointing at the config file. Alex's Mobs Continued uses it for its new spawn group size editor. Ungrouped settings in a category also now come before the group buttons rather than after them, so a setting that belongs to the category as a whole is on the first page instead of the last.

# CodxLib 1.6.0 *This file is for **Fabric 1.21.4**. It requires **Fabric Loader 0.16.9 or newer** — exactly what Fabric API already needs on 1.21.4, so CodxLib adds no restriction of its own — and **Fabric API 0.119.4+1.21.4 or newer**.* **A settings menu fix everyone should take, and a new hook for mod authors.** ## Fixed: number settings in the chest menu jumped to their maximum Clicking + or − on any numeric setting in a `/<mod> menu` screen added the new value on top of the old one instead of replacing it, so two or three clicks pinned the setting to its ceiling no matter which button you pressed. Sliders were fine; the +/− tiles were not. This affected every mod that uses CodxLib's settings menu, so if you have edited a number that way, it is worth checking what it actually says now. ## New: a mod can put its own page behind one setting Lists and text settings could only be shown read-only in the chest menu, because there is no keyboard in a chest UI. Mods can now hand a single setting a page of their own, so a list of entity ids and numbers can be presented as a row of buttons instead of a line of text pointing at the config file. Alex's Mobs Continued uses it for its new spawn group size editor. Ungrouped settings in a category also now come before the group buttons rather than after them, so a setting that belongs to the category as a whole is on the first page instead of the last.

# CodxLib 1.6.0 *This file is for **NeoForge 1.21.3**. Every loader ships the same CodxLib version, so the notes below apply here too.* **A settings menu fix everyone should take, and a new hook for mod authors.** ## Fixed: number settings in the chest menu jumped to their maximum Clicking + or − on any numeric setting in a `/<mod> menu` screen added the new value on top of the old one instead of replacing it, so two or three clicks pinned the setting to its ceiling no matter which button you pressed. Sliders were fine; the +/− tiles were not. This affected every mod that uses CodxLib's settings menu, so if you have edited a number that way, it is worth checking what it actually says now. ## New: a mod can put its own page behind one setting Lists and text settings could only be shown read-only in the chest menu, because there is no keyboard in a chest UI. Mods can now hand a single setting a page of their own, so a list of entity ids and numbers can be presented as a row of buttons instead of a line of text pointing at the config file. Alex's Mobs Continued uses it for its new spawn group size editor. Ungrouped settings in a category also now come before the group buttons rather than after them, so a setting that belongs to the category as a whole is on the first page instead of the last.

# CodxLib 1.6.0 *This file is for **Forge 1.21.3**. Every loader ships the same CodxLib version, so the notes below apply here too.* **A settings menu fix everyone should take, and a new hook for mod authors.** ## Fixed: number settings in the chest menu jumped to their maximum Clicking + or − on any numeric setting in a `/<mod> menu` screen added the new value on top of the old one instead of replacing it, so two or three clicks pinned the setting to its ceiling no matter which button you pressed. Sliders were fine; the +/− tiles were not. This affected every mod that uses CodxLib's settings menu, so if you have edited a number that way, it is worth checking what it actually says now. ## New: a mod can put its own page behind one setting Lists and text settings could only be shown read-only in the chest menu, because there is no keyboard in a chest UI. Mods can now hand a single setting a page of their own, so a list of entity ids and numbers can be presented as a row of buttons instead of a line of text pointing at the config file. Alex's Mobs Continued uses it for its new spawn group size editor. Ungrouped settings in a category also now come before the group buttons rather than after them, so a setting that belongs to the category as a whole is on the first page instead of the last.

# CodxLib 1.6.0 *This file is for **Fabric 1.21.3**. It requires **Fabric Loader 0.16.8 or newer** — exactly what Fabric API already needs on 1.21.3, so CodxLib adds no restriction of its own — and **Fabric API 0.114.1+1.21.3 or newer**.* **A settings menu fix everyone should take, and a new hook for mod authors.** ## Fixed: number settings in the chest menu jumped to their maximum Clicking + or − on any numeric setting in a `/<mod> menu` screen added the new value on top of the old one instead of replacing it, so two or three clicks pinned the setting to its ceiling no matter which button you pressed. Sliders were fine; the +/− tiles were not. This affected every mod that uses CodxLib's settings menu, so if you have edited a number that way, it is worth checking what it actually says now. ## New: a mod can put its own page behind one setting Lists and text settings could only be shown read-only in the chest menu, because there is no keyboard in a chest UI. Mods can now hand a single setting a page of their own, so a list of entity ids and numbers can be presented as a row of buttons instead of a line of text pointing at the config file. Alex's Mobs Continued uses it for its new spawn group size editor. Ungrouped settings in a category also now come before the group buttons rather than after them, so a setting that belongs to the category as a whole is on the first page instead of the last.

# CodxLib 1.6.0 *This file is for **NeoForge 1.21.2**. Every loader ships the same CodxLib version, so the notes below apply here too.* **A settings menu fix everyone should take, and a new hook for mod authors.** ## Fixed: number settings in the chest menu jumped to their maximum Clicking + or − on any numeric setting in a `/<mod> menu` screen added the new value on top of the old one instead of replacing it, so two or three clicks pinned the setting to its ceiling no matter which button you pressed. Sliders were fine; the +/− tiles were not. This affected every mod that uses CodxLib's settings menu, so if you have edited a number that way, it is worth checking what it actually says now. ## New: a mod can put its own page behind one setting Lists and text settings could only be shown read-only in the chest menu, because there is no keyboard in a chest UI. Mods can now hand a single setting a page of their own, so a list of entity ids and numbers can be presented as a row of buttons instead of a line of text pointing at the config file. Alex's Mobs Continued uses it for its new spawn group size editor. Ungrouped settings in a category also now come before the group buttons rather than after them, so a setting that belongs to the category as a whole is on the first page instead of the last.

# CodxLib 1.6.0 *This file is for **Fabric 1.21.2**. It requires **Fabric Loader 0.16.7 or newer** — exactly what Fabric API already needs on 1.21.2, so CodxLib adds no restriction of its own — and **Fabric API 0.106.1+1.21.2 or newer**.* **A settings menu fix everyone should take, and a new hook for mod authors.** ## Fixed: number settings in the chest menu jumped to their maximum Clicking + or − on any numeric setting in a `/<mod> menu` screen added the new value on top of the old one instead of replacing it, so two or three clicks pinned the setting to its ceiling no matter which button you pressed. Sliders were fine; the +/− tiles were not. This affected every mod that uses CodxLib's settings menu, so if you have edited a number that way, it is worth checking what it actually says now. ## New: a mod can put its own page behind one setting Lists and text settings could only be shown read-only in the chest menu, because there is no keyboard in a chest UI. Mods can now hand a single setting a page of their own, so a list of entity ids and numbers can be presented as a row of buttons instead of a line of text pointing at the config file. Alex's Mobs Continued uses it for its new spawn group size editor. Ungrouped settings in a category also now come before the group buttons rather than after them, so a setting that belongs to the category as a whole is on the first page instead of the last.

# CodxLib 1.6.0 *This file is for **NeoForge 1.21.1**. Every loader ships the same CodxLib version, so the notes below apply here too.* **A settings menu fix everyone should take, and a new hook for mod authors.** ## Fixed: number settings in the chest menu jumped to their maximum Clicking + or − on any numeric setting in a `/<mod> menu` screen added the new value on top of the old one instead of replacing it, so two or three clicks pinned the setting to its ceiling no matter which button you pressed. Sliders were fine; the +/− tiles were not. This affected every mod that uses CodxLib's settings menu, so if you have edited a number that way, it is worth checking what it actually says now. ## New: a mod can put its own page behind one setting Lists and text settings could only be shown read-only in the chest menu, because there is no keyboard in a chest UI. Mods can now hand a single setting a page of their own, so a list of entity ids and numbers can be presented as a row of buttons instead of a line of text pointing at the config file. Alex's Mobs Continued uses it for its new spawn group size editor. Ungrouped settings in a category also now come before the group buttons rather than after them, so a setting that belongs to the category as a whole is on the first page instead of the last.

# CodxLib 1.6.0 *This file is for **Forge 1.21.1**. Every loader ships the same CodxLib version, so the notes below apply here too.* **A settings menu fix everyone should take, and a new hook for mod authors.** ## Fixed: number settings in the chest menu jumped to their maximum Clicking + or − on any numeric setting in a `/<mod> menu` screen added the new value on top of the old one instead of replacing it, so two or three clicks pinned the setting to its ceiling no matter which button you pressed. Sliders were fine; the +/− tiles were not. This affected every mod that uses CodxLib's settings menu, so if you have edited a number that way, it is worth checking what it actually says now. ## New: a mod can put its own page behind one setting Lists and text settings could only be shown read-only in the chest menu, because there is no keyboard in a chest UI. Mods can now hand a single setting a page of their own, so a list of entity ids and numbers can be presented as a row of buttons instead of a line of text pointing at the config file. Alex's Mobs Continued uses it for its new spawn group size editor. Ungrouped settings in a category also now come before the group buttons rather than after them, so a setting that belongs to the category as a whole is on the first page instead of the last.

# CodxLib 1.6.0 *This file is for **Fabric 1.21.1**. It requires **Fabric Loader 0.15.11 or newer** — exactly what Fabric API already needs on 1.21.1, so CodxLib adds no restriction of its own — and **Fabric API 0.116.4+1.21.1 or newer**.* **A settings menu fix everyone should take, and a new hook for mod authors.** ## Fixed: number settings in the chest menu jumped to their maximum Clicking + or − on any numeric setting in a `/<mod> menu` screen added the new value on top of the old one instead of replacing it, so two or three clicks pinned the setting to its ceiling no matter which button you pressed. Sliders were fine; the +/− tiles were not. This affected every mod that uses CodxLib's settings menu, so if you have edited a number that way, it is worth checking what it actually says now. ## New: a mod can put its own page behind one setting Lists and text settings could only be shown read-only in the chest menu, because there is no keyboard in a chest UI. Mods can now hand a single setting a page of their own, so a list of entity ids and numbers can be presented as a row of buttons instead of a line of text pointing at the config file. Alex's Mobs Continued uses it for its new spawn group size editor. Ungrouped settings in a category also now come before the group buttons rather than after them, so a setting that belongs to the category as a whole is on the first page instead of the last.

# CodxLib 1.6.0 *This file is for **NeoForge 1.21**. Every loader ships the same CodxLib version, so the notes below apply here too.* **A settings menu fix everyone should take, and a new hook for mod authors.** ## Fixed: number settings in the chest menu jumped to their maximum Clicking + or − on any numeric setting in a `/<mod> menu` screen added the new value on top of the old one instead of replacing it, so two or three clicks pinned the setting to its ceiling no matter which button you pressed. Sliders were fine; the +/− tiles were not. This affected every mod that uses CodxLib's settings menu, so if you have edited a number that way, it is worth checking what it actually says now. ## New: a mod can put its own page behind one setting Lists and text settings could only be shown read-only in the chest menu, because there is no keyboard in a chest UI. Mods can now hand a single setting a page of their own, so a list of entity ids and numbers can be presented as a row of buttons instead of a line of text pointing at the config file. Alex's Mobs Continued uses it for its new spawn group size editor. Ungrouped settings in a category also now come before the group buttons rather than after them, so a setting that belongs to the category as a whole is on the first page instead of the last.

# CodxLib 1.6.0 *This file is for **Forge 1.21**. Every loader ships the same CodxLib version, so the notes below apply here too.* **A settings menu fix everyone should take, and a new hook for mod authors.** ## Fixed: number settings in the chest menu jumped to their maximum Clicking + or − on any numeric setting in a `/<mod> menu` screen added the new value on top of the old one instead of replacing it, so two or three clicks pinned the setting to its ceiling no matter which button you pressed. Sliders were fine; the +/− tiles were not. This affected every mod that uses CodxLib's settings menu, so if you have edited a number that way, it is worth checking what it actually says now. ## New: a mod can put its own page behind one setting Lists and text settings could only be shown read-only in the chest menu, because there is no keyboard in a chest UI. Mods can now hand a single setting a page of their own, so a list of entity ids and numbers can be presented as a row of buttons instead of a line of text pointing at the config file. Alex's Mobs Continued uses it for its new spawn group size editor. Ungrouped settings in a category also now come before the group buttons rather than after them, so a setting that belongs to the category as a whole is on the first page instead of the last.

# CodxLib 1.6.0 *This file is for **Fabric 1.21**. It requires **Fabric Loader 0.15.11 or newer** — exactly what Fabric API already needs on 1.21, so CodxLib adds no restriction of its own — and **Fabric API 0.102.0+1.21 or newer**.* **A settings menu fix everyone should take, and a new hook for mod authors.** ## Fixed: number settings in the chest menu jumped to their maximum Clicking + or − on any numeric setting in a `/<mod> menu` screen added the new value on top of the old one instead of replacing it, so two or three clicks pinned the setting to its ceiling no matter which button you pressed. Sliders were fine; the +/− tiles were not. This affected every mod that uses CodxLib's settings menu, so if you have edited a number that way, it is worth checking what it actually says now. ## New: a mod can put its own page behind one setting Lists and text settings could only be shown read-only in the chest menu, because there is no keyboard in a chest UI. Mods can now hand a single setting a page of their own, so a list of entity ids and numbers can be presented as a row of buttons instead of a line of text pointing at the config file. Alex's Mobs Continued uses it for its new spawn group size editor. Ungrouped settings in a category also now come before the group buttons rather than after them, so a setting that belongs to the category as a whole is on the first page instead of the last.

# CodxLib 1.6.0 *This file is for **NeoForge 1.20.6**. Every loader ships the same CodxLib version, so the notes below apply here too.* **A settings menu fix everyone should take, and a new hook for mod authors.** ## Fixed: number settings in the chest menu jumped to their maximum Clicking + or − on any numeric setting in a `/<mod> menu` screen added the new value on top of the old one instead of replacing it, so two or three clicks pinned the setting to its ceiling no matter which button you pressed. Sliders were fine; the +/− tiles were not. This affected every mod that uses CodxLib's settings menu, so if you have edited a number that way, it is worth checking what it actually says now. ## New: a mod can put its own page behind one setting Lists and text settings could only be shown read-only in the chest menu, because there is no keyboard in a chest UI. Mods can now hand a single setting a page of their own, so a list of entity ids and numbers can be presented as a row of buttons instead of a line of text pointing at the config file. Alex's Mobs Continued uses it for its new spawn group size editor. Ungrouped settings in a category also now come before the group buttons rather than after them, so a setting that belongs to the category as a whole is on the first page instead of the last.

# CodxLib 1.6.0 *This file is for **Forge 1.20.6**. Every loader ships the same CodxLib version, so the notes below apply here too.* **A settings menu fix everyone should take, and a new hook for mod authors.** ## Fixed: number settings in the chest menu jumped to their maximum Clicking + or − on any numeric setting in a `/<mod> menu` screen added the new value on top of the old one instead of replacing it, so two or three clicks pinned the setting to its ceiling no matter which button you pressed. Sliders were fine; the +/− tiles were not. This affected every mod that uses CodxLib's settings menu, so if you have edited a number that way, it is worth checking what it actually says now. ## New: a mod can put its own page behind one setting Lists and text settings could only be shown read-only in the chest menu, because there is no keyboard in a chest UI. Mods can now hand a single setting a page of their own, so a list of entity ids and numbers can be presented as a row of buttons instead of a line of text pointing at the config file. Alex's Mobs Continued uses it for its new spawn group size editor. Ungrouped settings in a category also now come before the group buttons rather than after them, so a setting that belongs to the category as a whole is on the first page instead of the last.

# CodxLib 1.6.0 *This file is for **Fabric 1.20.6**. It requires **Fabric Loader 0.15.6 or newer** — exactly what Fabric API already needs on 1.20.6, so CodxLib adds no restriction of its own — and **Fabric API 0.100.8+1.20.6 or newer**.* **A settings menu fix everyone should take, and a new hook for mod authors.** ## Fixed: number settings in the chest menu jumped to their maximum Clicking + or − on any numeric setting in a `/<mod> menu` screen added the new value on top of the old one instead of replacing it, so two or three clicks pinned the setting to its ceiling no matter which button you pressed. Sliders were fine; the +/− tiles were not. This affected every mod that uses CodxLib's settings menu, so if you have edited a number that way, it is worth checking what it actually says now. ## New: a mod can put its own page behind one setting Lists and text settings could only be shown read-only in the chest menu, because there is no keyboard in a chest UI. Mods can now hand a single setting a page of their own, so a list of entity ids and numbers can be presented as a row of buttons instead of a line of text pointing at the config file. Alex's Mobs Continued uses it for its new spawn group size editor. Ungrouped settings in a category also now come before the group buttons rather than after them, so a setting that belongs to the category as a whole is on the first page instead of the last.

# CodxLib 1.6.0 *This file is for **Fabric 1.20.5**. It requires **Fabric Loader 0.15.6 or newer** — exactly what Fabric API already needs on 1.20.5, so CodxLib adds no restriction of its own — and **Fabric API 0.97.8+1.20.5 or newer**.* **A settings menu fix everyone should take, and a new hook for mod authors.** ## Fixed: number settings in the chest menu jumped to their maximum Clicking + or − on any numeric setting in a `/<mod> menu` screen added the new value on top of the old one instead of replacing it, so two or three clicks pinned the setting to its ceiling no matter which button you pressed. Sliders were fine; the +/− tiles were not. This affected every mod that uses CodxLib's settings menu, so if you have edited a number that way, it is worth checking what it actually says now. ## New: a mod can put its own page behind one setting Lists and text settings could only be shown read-only in the chest menu, because there is no keyboard in a chest UI. Mods can now hand a single setting a page of their own, so a list of entity ids and numbers can be presented as a row of buttons instead of a line of text pointing at the config file. Alex's Mobs Continued uses it for its new spawn group size editor. Ungrouped settings in a category also now come before the group buttons rather than after them, so a setting that belongs to the category as a whole is on the first page instead of the last.

# CodxLib 1.6.0 *This file is for **NeoForge 1.20.4**. Every loader ships the same CodxLib version, so the notes below apply here too.* **A settings menu fix everyone should take, and a new hook for mod authors.** ## Fixed: number settings in the chest menu jumped to their maximum Clicking + or − on any numeric setting in a `/<mod> menu` screen added the new value on top of the old one instead of replacing it, so two or three clicks pinned the setting to its ceiling no matter which button you pressed. Sliders were fine; the +/− tiles were not. This affected every mod that uses CodxLib's settings menu, so if you have edited a number that way, it is worth checking what it actually says now. ## New: a mod can put its own page behind one setting Lists and text settings could only be shown read-only in the chest menu, because there is no keyboard in a chest UI. Mods can now hand a single setting a page of their own, so a list of entity ids and numbers can be presented as a row of buttons instead of a line of text pointing at the config file. Alex's Mobs Continued uses it for its new spawn group size editor. Ungrouped settings in a category also now come before the group buttons rather than after them, so a setting that belongs to the category as a whole is on the first page instead of the last.

# CodxLib 1.6.0 *This file is for **Forge 1.20.4**. Every loader ships the same CodxLib version, so the notes below apply here too.* **A settings menu fix everyone should take, and a new hook for mod authors.** ## Fixed: number settings in the chest menu jumped to their maximum Clicking + or − on any numeric setting in a `/<mod> menu` screen added the new value on top of the old one instead of replacing it, so two or three clicks pinned the setting to its ceiling no matter which button you pressed. Sliders were fine; the +/− tiles were not. This affected every mod that uses CodxLib's settings menu, so if you have edited a number that way, it is worth checking what it actually says now. ## New: a mod can put its own page behind one setting Lists and text settings could only be shown read-only in the chest menu, because there is no keyboard in a chest UI. Mods can now hand a single setting a page of their own, so a list of entity ids and numbers can be presented as a row of buttons instead of a line of text pointing at the config file. Alex's Mobs Continued uses it for its new spawn group size editor. Ungrouped settings in a category also now come before the group buttons rather than after them, so a setting that belongs to the category as a whole is on the first page instead of the last.

# CodxLib 1.6.0 *This file is for **Fabric 1.20.4**. It requires **Fabric Loader 0.15.1 or newer** — exactly what Fabric API already needs on 1.20.4, so CodxLib adds no restriction of its own — and **Fabric API 0.97.3+1.20.4 or newer**.* **A settings menu fix everyone should take, and a new hook for mod authors.** ## Fixed: number settings in the chest menu jumped to their maximum Clicking + or − on any numeric setting in a `/<mod> menu` screen added the new value on top of the old one instead of replacing it, so two or three clicks pinned the setting to its ceiling no matter which button you pressed. Sliders were fine; the +/− tiles were not. This affected every mod that uses CodxLib's settings menu, so if you have edited a number that way, it is worth checking what it actually says now. ## New: a mod can put its own page behind one setting Lists and text settings could only be shown read-only in the chest menu, because there is no keyboard in a chest UI. Mods can now hand a single setting a page of their own, so a list of entity ids and numbers can be presented as a row of buttons instead of a line of text pointing at the config file. Alex's Mobs Continued uses it for its new spawn group size editor. Ungrouped settings in a category also now come before the group buttons rather than after them, so a setting that belongs to the category as a whole is on the first page instead of the last.

# CodxLib 1.6.0 *This file is for **Fabric 1.20.3**. It requires **Fabric Loader 0.14.23 or newer** — exactly what Fabric API already needs on 1.20.3, so CodxLib adds no restriction of its own — and **Fabric API 0.91.1+1.20.3 or newer**.* **A settings menu fix everyone should take, and a new hook for mod authors.** ## Fixed: number settings in the chest menu jumped to their maximum Clicking + or − on any numeric setting in a `/<mod> menu` screen added the new value on top of the old one instead of replacing it, so two or three clicks pinned the setting to its ceiling no matter which button you pressed. Sliders were fine; the +/− tiles were not. This affected every mod that uses CodxLib's settings menu, so if you have edited a number that way, it is worth checking what it actually says now. ## New: a mod can put its own page behind one setting Lists and text settings could only be shown read-only in the chest menu, because there is no keyboard in a chest UI. Mods can now hand a single setting a page of their own, so a list of entity ids and numbers can be presented as a row of buttons instead of a line of text pointing at the config file. Alex's Mobs Continued uses it for its new spawn group size editor. Ungrouped settings in a category also now come before the group buttons rather than after them, so a setting that belongs to the category as a whole is on the first page instead of the last.

# CodxLib 1.6.0 *This file is for **Fabric 1.20.2**. It requires **Fabric Loader 0.14.22 or newer** — exactly what Fabric API already needs on 1.20.2, so CodxLib adds no restriction of its own — and **Fabric API 0.91.6+1.20.2 or newer**.* **A settings menu fix everyone should take, and a new hook for mod authors.** ## Fixed: number settings in the chest menu jumped to their maximum Clicking + or − on any numeric setting in a `/<mod> menu` screen added the new value on top of the old one instead of replacing it, so two or three clicks pinned the setting to its ceiling no matter which button you pressed. Sliders were fine; the +/− tiles were not. This affected every mod that uses CodxLib's settings menu, so if you have edited a number that way, it is worth checking what it actually says now. ## New: a mod can put its own page behind one setting Lists and text settings could only be shown read-only in the chest menu, because there is no keyboard in a chest UI. Mods can now hand a single setting a page of their own, so a list of entity ids and numbers can be presented as a row of buttons instead of a line of text pointing at the config file. Alex's Mobs Continued uses it for its new spawn group size editor. Ungrouped settings in a category also now come before the group buttons rather than after them, so a setting that belongs to the category as a whole is on the first page instead of the last.

# CodxLib 1.6.0 *This file is for **Forge 1.20.1**. Every loader ships the same CodxLib version, so the notes below apply here too.* **A settings menu fix everyone should take, and a new hook for mod authors.** ## Fixed: number settings in the chest menu jumped to their maximum Clicking + or − on any numeric setting in a `/<mod> menu` screen added the new value on top of the old one instead of replacing it, so two or three clicks pinned the setting to its ceiling no matter which button you pressed. Sliders were fine; the +/− tiles were not. This affected every mod that uses CodxLib's settings menu, so if you have edited a number that way, it is worth checking what it actually says now. ## New: a mod can put its own page behind one setting Lists and text settings could only be shown read-only in the chest menu, because there is no keyboard in a chest UI. Mods can now hand a single setting a page of their own, so a list of entity ids and numbers can be presented as a row of buttons instead of a line of text pointing at the config file. Alex's Mobs Continued uses it for its new spawn group size editor. Ungrouped settings in a category also now come before the group buttons rather than after them, so a setting that belongs to the category as a whole is on the first page instead of the last.

# CodxLib 1.6.0 *This file is for **Fabric 1.20.1**. It requires **Fabric Loader 0.16.10 or newer** — exactly what Fabric API already needs on 1.20.1, so CodxLib adds no restriction of its own — and **Fabric API 0.92.8+1.20.1 or newer**.* **A settings menu fix everyone should take, and a new hook for mod authors.** ## Fixed: number settings in the chest menu jumped to their maximum Clicking + or − on any numeric setting in a `/<mod> menu` screen added the new value on top of the old one instead of replacing it, so two or three clicks pinned the setting to its ceiling no matter which button you pressed. Sliders were fine; the +/− tiles were not. This affected every mod that uses CodxLib's settings menu, so if you have edited a number that way, it is worth checking what it actually says now. ## New: a mod can put its own page behind one setting Lists and text settings could only be shown read-only in the chest menu, because there is no keyboard in a chest UI. Mods can now hand a single setting a page of their own, so a list of entity ids and numbers can be presented as a row of buttons instead of a line of text pointing at the config file. Alex's Mobs Continued uses it for its new spawn group size editor. Ungrouped settings in a category also now come before the group buttons rather than after them, so a setting that belongs to the category as a whole is on the first page instead of the last.

# CodxLib 1.6.0 *This file is for **Fabric 26.2**. It requires **Fabric Loader 0.18.4 or newer** — exactly what Fabric API already needs on 26.2, so CodxLib adds no restriction of its own — and **Fabric API 0.155.2+26.2 or newer**.* **A settings menu fix everyone should take, and a new hook for mod authors.** ## Fixed: number settings in the chest menu jumped to their maximum Clicking + or − on any numeric setting in a `/<mod> menu` screen added the new value on top of the old one instead of replacing it, so two or three clicks pinned the setting to its ceiling no matter which button you pressed. Sliders were fine; the +/− tiles were not. This affected every mod that uses CodxLib's settings menu, so if you have edited a number that way, it is worth checking what it actually says now. ## New: a mod can put its own page behind one setting Lists and text settings could only be shown read-only in the chest menu, because there is no keyboard in a chest UI. Mods can now hand a single setting a page of their own, so a list of entity ids and numbers can be presented as a row of buttons instead of a line of text pointing at the config file. Alex's Mobs Continued uses it for its new spawn group size editor. Ungrouped settings in a category also now come before the group buttons rather than after them, so a setting that belongs to the category as a whole is on the first page instead of the last.

# CodxLib 1.5.1 *This file is for **NeoForge 26.2**. Every loader ships the same CodxLib version, so the notes below apply here too.* **Fabric only, one fix: CodxLib no longer refuses older builds of Fabric API.** Every Fabric jar was declaring the exact Fabric API build it had been compiled against as its minimum, instead of the oldest one it actually works with. Anything older was rejected outright — even though nothing in the library needed the newer build. Because mods that use CodxLib depend on it hard, that floor was theirs too: a mod could declare a lower Fabric API requirement of its own and still be blocked, because the library's number won. On **1.20.1** that meant Fabric API 0.92.11 or nothing. It now accepts **0.92.8 and up**, which is what people asked for — 0.92.11 clashes with a couple of other mods. The other Minecraft versions keep the same floor they had; the difference is that it is now a real minimum rather than whatever the build machine happened to use. Nothing else changed. Forge and NeoForge builds are unaffected, and no API changed, so there is no reason to raise your version range.

# CodxLib 1.5.1 *This file is for **Forge 26.2**. Every loader ships the same CodxLib version, so the notes below apply here too.* **Fabric only, one fix: CodxLib no longer refuses older builds of Fabric API.** Every Fabric jar was declaring the exact Fabric API build it had been compiled against as its minimum, instead of the oldest one it actually works with. Anything older was rejected outright — even though nothing in the library needed the newer build. Because mods that use CodxLib depend on it hard, that floor was theirs too: a mod could declare a lower Fabric API requirement of its own and still be blocked, because the library's number won. On **1.20.1** that meant Fabric API 0.92.11 or nothing. It now accepts **0.92.8 and up**, which is what people asked for — 0.92.11 clashes with a couple of other mods. The other Minecraft versions keep the same floor they had; the difference is that it is now a real minimum rather than whatever the build machine happened to use. Nothing else changed. Forge and NeoForge builds are unaffected, and no API changed, so there is no reason to raise your version range.

# CodxLib 1.5.1 *This file is for **Fabric 26.2**. It requires **Fabric Loader 0.18.4 or newer** — exactly what Fabric API already needs on 26.2, so CodxLib adds no restriction of its own — and **Fabric API 0.155.2+26.2 or newer**.* **Fabric only, one fix: CodxLib no longer refuses older builds of Fabric API.** Every Fabric jar was declaring the exact Fabric API build it had been compiled against as its minimum, instead of the oldest one it actually works with. Anything older was rejected outright — even though nothing in the library needed the newer build. Because mods that use CodxLib depend on it hard, that floor was theirs too: a mod could declare a lower Fabric API requirement of its own and still be blocked, because the library's number won. On **1.20.1** that meant Fabric API 0.92.11 or nothing. It now accepts **0.92.8 and up**, which is what people asked for — 0.92.11 clashes with a couple of other mods. The other Minecraft versions keep the same floor they had; the difference is that it is now a real minimum rather than whatever the build machine happened to use. Nothing else changed. Forge and NeoForge builds are unaffected, and no API changed, so there is no reason to raise your version range.

# CodxLib 1.5.1 *This file is for **NeoForge 26.1.2**. Every loader ships the same CodxLib version, so the notes below apply here too.* **Fabric only, one fix: CodxLib no longer refuses older builds of Fabric API.** Every Fabric jar was declaring the exact Fabric API build it had been compiled against as its minimum, instead of the oldest one it actually works with. Anything older was rejected outright — even though nothing in the library needed the newer build. Because mods that use CodxLib depend on it hard, that floor was theirs too: a mod could declare a lower Fabric API requirement of its own and still be blocked, because the library's number won. On **1.20.1** that meant Fabric API 0.92.11 or nothing. It now accepts **0.92.8 and up**, which is what people asked for — 0.92.11 clashes with a couple of other mods. The other Minecraft versions keep the same floor they had; the difference is that it is now a real minimum rather than whatever the build machine happened to use. Nothing else changed. Forge and NeoForge builds are unaffected, and no API changed, so there is no reason to raise your version range.

# CodxLib 1.5.1 *This file is for **Forge 26.1.2**. Every loader ships the same CodxLib version, so the notes below apply here too.* **Fabric only, one fix: CodxLib no longer refuses older builds of Fabric API.** Every Fabric jar was declaring the exact Fabric API build it had been compiled against as its minimum, instead of the oldest one it actually works with. Anything older was rejected outright — even though nothing in the library needed the newer build. Because mods that use CodxLib depend on it hard, that floor was theirs too: a mod could declare a lower Fabric API requirement of its own and still be blocked, because the library's number won. On **1.20.1** that meant Fabric API 0.92.11 or nothing. It now accepts **0.92.8 and up**, which is what people asked for — 0.92.11 clashes with a couple of other mods. The other Minecraft versions keep the same floor they had; the difference is that it is now a real minimum rather than whatever the build machine happened to use. Nothing else changed. Forge and NeoForge builds are unaffected, and no API changed, so there is no reason to raise your version range.

# CodxLib 1.5.1 *This file is for **Fabric 26.1.2**. It requires **Fabric Loader 0.18.4 or newer** — exactly what Fabric API already needs on 26.1.2, so CodxLib adds no restriction of its own — and **Fabric API 0.145.4+26.1.2 or newer**.* **Fabric only, one fix: CodxLib no longer refuses older builds of Fabric API.** Every Fabric jar was declaring the exact Fabric API build it had been compiled against as its minimum, instead of the oldest one it actually works with. Anything older was rejected outright — even though nothing in the library needed the newer build. Because mods that use CodxLib depend on it hard, that floor was theirs too: a mod could declare a lower Fabric API requirement of its own and still be blocked, because the library's number won. On **1.20.1** that meant Fabric API 0.92.11 or nothing. It now accepts **0.92.8 and up**, which is what people asked for — 0.92.11 clashes with a couple of other mods. The other Minecraft versions keep the same floor they had; the difference is that it is now a real minimum rather than whatever the build machine happened to use. Nothing else changed. Forge and NeoForge builds are unaffected, and no API changed, so there is no reason to raise your version range.

# CodxLib 1.5.1 *This file is for **NeoForge 26.1.1**. Every loader ships the same CodxLib version, so the notes below apply here too.* **Fabric only, one fix: CodxLib no longer refuses older builds of Fabric API.** Every Fabric jar was declaring the exact Fabric API build it had been compiled against as its minimum, instead of the oldest one it actually works with. Anything older was rejected outright — even though nothing in the library needed the newer build. Because mods that use CodxLib depend on it hard, that floor was theirs too: a mod could declare a lower Fabric API requirement of its own and still be blocked, because the library's number won. On **1.20.1** that meant Fabric API 0.92.11 or nothing. It now accepts **0.92.8 and up**, which is what people asked for — 0.92.11 clashes with a couple of other mods. The other Minecraft versions keep the same floor they had; the difference is that it is now a real minimum rather than whatever the build machine happened to use. Nothing else changed. Forge and NeoForge builds are unaffected, and no API changed, so there is no reason to raise your version range.

# CodxLib 1.5.1 *This file is for **Forge 26.1.1**. Every loader ships the same CodxLib version, so the notes below apply here too.* **Fabric only, one fix: CodxLib no longer refuses older builds of Fabric API.** Every Fabric jar was declaring the exact Fabric API build it had been compiled against as its minimum, instead of the oldest one it actually works with. Anything older was rejected outright — even though nothing in the library needed the newer build. Because mods that use CodxLib depend on it hard, that floor was theirs too: a mod could declare a lower Fabric API requirement of its own and still be blocked, because the library's number won. On **1.20.1** that meant Fabric API 0.92.11 or nothing. It now accepts **0.92.8 and up**, which is what people asked for — 0.92.11 clashes with a couple of other mods. The other Minecraft versions keep the same floor they had; the difference is that it is now a real minimum rather than whatever the build machine happened to use. Nothing else changed. Forge and NeoForge builds are unaffected, and no API changed, so there is no reason to raise your version range.

# CodxLib 1.5.1 *This file is for **Fabric 26.1.1**. It requires **Fabric Loader 0.18.4 or newer** — exactly what Fabric API already needs on 26.1.1, so CodxLib adds no restriction of its own — and **Fabric API 0.145.4+26.1.1 or newer**.* **Fabric only, one fix: CodxLib no longer refuses older builds of Fabric API.** Every Fabric jar was declaring the exact Fabric API build it had been compiled against as its minimum, instead of the oldest one it actually works with. Anything older was rejected outright — even though nothing in the library needed the newer build. Because mods that use CodxLib depend on it hard, that floor was theirs too: a mod could declare a lower Fabric API requirement of its own and still be blocked, because the library's number won. On **1.20.1** that meant Fabric API 0.92.11 or nothing. It now accepts **0.92.8 and up**, which is what people asked for — 0.92.11 clashes with a couple of other mods. The other Minecraft versions keep the same floor they had; the difference is that it is now a real minimum rather than whatever the build machine happened to use. Nothing else changed. Forge and NeoForge builds are unaffected, and no API changed, so there is no reason to raise your version range.

# CodxLib 1.5.1 *This file is for **NeoForge 26.1**. Every loader ships the same CodxLib version, so the notes below apply here too.* **Fabric only, one fix: CodxLib no longer refuses older builds of Fabric API.** Every Fabric jar was declaring the exact Fabric API build it had been compiled against as its minimum, instead of the oldest one it actually works with. Anything older was rejected outright — even though nothing in the library needed the newer build. Because mods that use CodxLib depend on it hard, that floor was theirs too: a mod could declare a lower Fabric API requirement of its own and still be blocked, because the library's number won. On **1.20.1** that meant Fabric API 0.92.11 or nothing. It now accepts **0.92.8 and up**, which is what people asked for — 0.92.11 clashes with a couple of other mods. The other Minecraft versions keep the same floor they had; the difference is that it is now a real minimum rather than whatever the build machine happened to use. Nothing else changed. Forge and NeoForge builds are unaffected, and no API changed, so there is no reason to raise your version range.

# CodxLib 1.5.1 *This file is for **Forge 26.1**. Every loader ships the same CodxLib version, so the notes below apply here too.* **Fabric only, one fix: CodxLib no longer refuses older builds of Fabric API.** Every Fabric jar was declaring the exact Fabric API build it had been compiled against as its minimum, instead of the oldest one it actually works with. Anything older was rejected outright — even though nothing in the library needed the newer build. Because mods that use CodxLib depend on it hard, that floor was theirs too: a mod could declare a lower Fabric API requirement of its own and still be blocked, because the library's number won. On **1.20.1** that meant Fabric API 0.92.11 or nothing. It now accepts **0.92.8 and up**, which is what people asked for — 0.92.11 clashes with a couple of other mods. The other Minecraft versions keep the same floor they had; the difference is that it is now a real minimum rather than whatever the build machine happened to use. Nothing else changed. Forge and NeoForge builds are unaffected, and no API changed, so there is no reason to raise your version range.

# CodxLib 1.5.1 *This file is for **Fabric 26.1**. It requires **Fabric Loader 0.18.4 or newer** — exactly what Fabric API already needs on 26.1, so CodxLib adds no restriction of its own — and **Fabric API 0.145.1+26.1 or newer**.* **Fabric only, one fix: CodxLib no longer refuses older builds of Fabric API.** Every Fabric jar was declaring the exact Fabric API build it had been compiled against as its minimum, instead of the oldest one it actually works with. Anything older was rejected outright — even though nothing in the library needed the newer build. Because mods that use CodxLib depend on it hard, that floor was theirs too: a mod could declare a lower Fabric API requirement of its own and still be blocked, because the library's number won. On **1.20.1** that meant Fabric API 0.92.11 or nothing. It now accepts **0.92.8 and up**, which is what people asked for — 0.92.11 clashes with a couple of other mods. The other Minecraft versions keep the same floor they had; the difference is that it is now a real minimum rather than whatever the build machine happened to use. Nothing else changed. Forge and NeoForge builds are unaffected, and no API changed, so there is no reason to raise your version range.

# CodxLib 1.5.1 *This file is for **NeoForge 1.21.11**. Every loader ships the same CodxLib version, so the notes below apply here too.* **Fabric only, one fix: CodxLib no longer refuses older builds of Fabric API.** Every Fabric jar was declaring the exact Fabric API build it had been compiled against as its minimum, instead of the oldest one it actually works with. Anything older was rejected outright — even though nothing in the library needed the newer build. Because mods that use CodxLib depend on it hard, that floor was theirs too: a mod could declare a lower Fabric API requirement of its own and still be blocked, because the library's number won. On **1.20.1** that meant Fabric API 0.92.11 or nothing. It now accepts **0.92.8 and up**, which is what people asked for — 0.92.11 clashes with a couple of other mods. The other Minecraft versions keep the same floor they had; the difference is that it is now a real minimum rather than whatever the build machine happened to use. Nothing else changed. Forge and NeoForge builds are unaffected, and no API changed, so there is no reason to raise your version range.

# CodxLib 1.5.1 *This file is for **Forge 1.21.11**. Every loader ships the same CodxLib version, so the notes below apply here too.* **Fabric only, one fix: CodxLib no longer refuses older builds of Fabric API.** Every Fabric jar was declaring the exact Fabric API build it had been compiled against as its minimum, instead of the oldest one it actually works with. Anything older was rejected outright — even though nothing in the library needed the newer build. Because mods that use CodxLib depend on it hard, that floor was theirs too: a mod could declare a lower Fabric API requirement of its own and still be blocked, because the library's number won. On **1.20.1** that meant Fabric API 0.92.11 or nothing. It now accepts **0.92.8 and up**, which is what people asked for — 0.92.11 clashes with a couple of other mods. The other Minecraft versions keep the same floor they had; the difference is that it is now a real minimum rather than whatever the build machine happened to use. Nothing else changed. Forge and NeoForge builds are unaffected, and no API changed, so there is no reason to raise your version range.

# CodxLib 1.5.1 *This file is for **Fabric 1.21.11**. It requires **Fabric Loader 0.17.3 or newer** — exactly what Fabric API already needs on 1.21.11, so CodxLib adds no restriction of its own — and **Fabric API 0.141.5+1.21.11 or newer**.* **Fabric only, one fix: CodxLib no longer refuses older builds of Fabric API.** Every Fabric jar was declaring the exact Fabric API build it had been compiled against as its minimum, instead of the oldest one it actually works with. Anything older was rejected outright — even though nothing in the library needed the newer build. Because mods that use CodxLib depend on it hard, that floor was theirs too: a mod could declare a lower Fabric API requirement of its own and still be blocked, because the library's number won. On **1.20.1** that meant Fabric API 0.92.11 or nothing. It now accepts **0.92.8 and up**, which is what people asked for — 0.92.11 clashes with a couple of other mods. The other Minecraft versions keep the same floor they had; the difference is that it is now a real minimum rather than whatever the build machine happened to use. Nothing else changed. Forge and NeoForge builds are unaffected, and no API changed, so there is no reason to raise your version range.

# CodxLib 1.5.1 *This file is for **NeoForge 1.21.10**. Every loader ships the same CodxLib version, so the notes below apply here too.* **Fabric only, one fix: CodxLib no longer refuses older builds of Fabric API.** Every Fabric jar was declaring the exact Fabric API build it had been compiled against as its minimum, instead of the oldest one it actually works with. Anything older was rejected outright — even though nothing in the library needed the newer build. Because mods that use CodxLib depend on it hard, that floor was theirs too: a mod could declare a lower Fabric API requirement of its own and still be blocked, because the library's number won. On **1.20.1** that meant Fabric API 0.92.11 or nothing. It now accepts **0.92.8 and up**, which is what people asked for — 0.92.11 clashes with a couple of other mods. The other Minecraft versions keep the same floor they had; the difference is that it is now a real minimum rather than whatever the build machine happened to use. Nothing else changed. Forge and NeoForge builds are unaffected, and no API changed, so there is no reason to raise your version range.

# CodxLib 1.5.1 *This file is for **Forge 1.21.10**. Every loader ships the same CodxLib version, so the notes below apply here too.* **Fabric only, one fix: CodxLib no longer refuses older builds of Fabric API.** Every Fabric jar was declaring the exact Fabric API build it had been compiled against as its minimum, instead of the oldest one it actually works with. Anything older was rejected outright — even though nothing in the library needed the newer build. Because mods that use CodxLib depend on it hard, that floor was theirs too: a mod could declare a lower Fabric API requirement of its own and still be blocked, because the library's number won. On **1.20.1** that meant Fabric API 0.92.11 or nothing. It now accepts **0.92.8 and up**, which is what people asked for — 0.92.11 clashes with a couple of other mods. The other Minecraft versions keep the same floor they had; the difference is that it is now a real minimum rather than whatever the build machine happened to use. Nothing else changed. Forge and NeoForge builds are unaffected, and no API changed, so there is no reason to raise your version range.

# CodxLib 1.5.1 *This file is for **Fabric 1.21.10**. It requires **Fabric Loader 0.17.0 or newer** — exactly what Fabric API already needs on 1.21.10, so CodxLib adds no restriction of its own — and **Fabric API 0.138.4+1.21.10 or newer**.* **Fabric only, one fix: CodxLib no longer refuses older builds of Fabric API.** Every Fabric jar was declaring the exact Fabric API build it had been compiled against as its minimum, instead of the oldest one it actually works with. Anything older was rejected outright — even though nothing in the library needed the newer build. Because mods that use CodxLib depend on it hard, that floor was theirs too: a mod could declare a lower Fabric API requirement of its own and still be blocked, because the library's number won. On **1.20.1** that meant Fabric API 0.92.11 or nothing. It now accepts **0.92.8 and up**, which is what people asked for — 0.92.11 clashes with a couple of other mods. The other Minecraft versions keep the same floor they had; the difference is that it is now a real minimum rather than whatever the build machine happened to use. Nothing else changed. Forge and NeoForge builds are unaffected, and no API changed, so there is no reason to raise your version range.

# CodxLib 1.5.1 *This file is for **NeoForge 1.21.9**. Every loader ships the same CodxLib version, so the notes below apply here too.* **Fabric only, one fix: CodxLib no longer refuses older builds of Fabric API.** Every Fabric jar was declaring the exact Fabric API build it had been compiled against as its minimum, instead of the oldest one it actually works with. Anything older was rejected outright — even though nothing in the library needed the newer build. Because mods that use CodxLib depend on it hard, that floor was theirs too: a mod could declare a lower Fabric API requirement of its own and still be blocked, because the library's number won. On **1.20.1** that meant Fabric API 0.92.11 or nothing. It now accepts **0.92.8 and up**, which is what people asked for — 0.92.11 clashes with a couple of other mods. The other Minecraft versions keep the same floor they had; the difference is that it is now a real minimum rather than whatever the build machine happened to use. Nothing else changed. Forge and NeoForge builds are unaffected, and no API changed, so there is no reason to raise your version range.

# CodxLib 1.5.1 *This file is for **Forge 1.21.9**. Every loader ships the same CodxLib version, so the notes below apply here too.* **Fabric only, one fix: CodxLib no longer refuses older builds of Fabric API.** Every Fabric jar was declaring the exact Fabric API build it had been compiled against as its minimum, instead of the oldest one it actually works with. Anything older was rejected outright — even though nothing in the library needed the newer build. Because mods that use CodxLib depend on it hard, that floor was theirs too: a mod could declare a lower Fabric API requirement of its own and still be blocked, because the library's number won. On **1.20.1** that meant Fabric API 0.92.11 or nothing. It now accepts **0.92.8 and up**, which is what people asked for — 0.92.11 clashes with a couple of other mods. The other Minecraft versions keep the same floor they had; the difference is that it is now a real minimum rather than whatever the build machine happened to use. Nothing else changed. Forge and NeoForge builds are unaffected, and no API changed, so there is no reason to raise your version range.

# CodxLib 1.5.1 *This file is for **Fabric 1.21.9**. It requires **Fabric Loader 0.17.0 or newer** — exactly what Fabric API already needs on 1.21.9, so CodxLib adds no restriction of its own — and **Fabric API 0.134.1+1.21.9 or newer**.* **Fabric only, one fix: CodxLib no longer refuses older builds of Fabric API.** Every Fabric jar was declaring the exact Fabric API build it had been compiled against as its minimum, instead of the oldest one it actually works with. Anything older was rejected outright — even though nothing in the library needed the newer build. Because mods that use CodxLib depend on it hard, that floor was theirs too: a mod could declare a lower Fabric API requirement of its own and still be blocked, because the library's number won. On **1.20.1** that meant Fabric API 0.92.11 or nothing. It now accepts **0.92.8 and up**, which is what people asked for — 0.92.11 clashes with a couple of other mods. The other Minecraft versions keep the same floor they had; the difference is that it is now a real minimum rather than whatever the build machine happened to use. Nothing else changed. Forge and NeoForge builds are unaffected, and no API changed, so there is no reason to raise your version range.

# CodxLib 1.5.1 *This file is for **NeoForge 1.21.8**. Every loader ships the same CodxLib version, so the notes below apply here too.* **Fabric only, one fix: CodxLib no longer refuses older builds of Fabric API.** Every Fabric jar was declaring the exact Fabric API build it had been compiled against as its minimum, instead of the oldest one it actually works with. Anything older was rejected outright — even though nothing in the library needed the newer build. Because mods that use CodxLib depend on it hard, that floor was theirs too: a mod could declare a lower Fabric API requirement of its own and still be blocked, because the library's number won. On **1.20.1** that meant Fabric API 0.92.11 or nothing. It now accepts **0.92.8 and up**, which is what people asked for — 0.92.11 clashes with a couple of other mods. The other Minecraft versions keep the same floor they had; the difference is that it is now a real minimum rather than whatever the build machine happened to use. Nothing else changed. Forge and NeoForge builds are unaffected, and no API changed, so there is no reason to raise your version range.

# CodxLib 1.5.1 *This file is for **Forge 1.21.8**. Every loader ships the same CodxLib version, so the notes below apply here too.* **Fabric only, one fix: CodxLib no longer refuses older builds of Fabric API.** Every Fabric jar was declaring the exact Fabric API build it had been compiled against as its minimum, instead of the oldest one it actually works with. Anything older was rejected outright — even though nothing in the library needed the newer build. Because mods that use CodxLib depend on it hard, that floor was theirs too: a mod could declare a lower Fabric API requirement of its own and still be blocked, because the library's number won. On **1.20.1** that meant Fabric API 0.92.11 or nothing. It now accepts **0.92.8 and up**, which is what people asked for — 0.92.11 clashes with a couple of other mods. The other Minecraft versions keep the same floor they had; the difference is that it is now a real minimum rather than whatever the build machine happened to use. Nothing else changed. Forge and NeoForge builds are unaffected, and no API changed, so there is no reason to raise your version range.

# CodxLib 1.5.1 *This file is for **Fabric 1.21.8**. It requires **Fabric Loader 0.16.13 or newer** — exactly what Fabric API already needs on 1.21.8, so CodxLib adds no restriction of its own — and **Fabric API 0.136.1+1.21.8 or newer**.* **Fabric only, one fix: CodxLib no longer refuses older builds of Fabric API.** Every Fabric jar was declaring the exact Fabric API build it had been compiled against as its minimum, instead of the oldest one it actually works with. Anything older was rejected outright — even though nothing in the library needed the newer build. Because mods that use CodxLib depend on it hard, that floor was theirs too: a mod could declare a lower Fabric API requirement of its own and still be blocked, because the library's number won. On **1.20.1** that meant Fabric API 0.92.11 or nothing. It now accepts **0.92.8 and up**, which is what people asked for — 0.92.11 clashes with a couple of other mods. The other Minecraft versions keep the same floor they had; the difference is that it is now a real minimum rather than whatever the build machine happened to use. Nothing else changed. Forge and NeoForge builds are unaffected, and no API changed, so there is no reason to raise your version range.

# CodxLib 1.5.1 *This file is for **NeoForge 1.21.7**. Every loader ships the same CodxLib version, so the notes below apply here too.* **Fabric only, one fix: CodxLib no longer refuses older builds of Fabric API.** Every Fabric jar was declaring the exact Fabric API build it had been compiled against as its minimum, instead of the oldest one it actually works with. Anything older was rejected outright — even though nothing in the library needed the newer build. Because mods that use CodxLib depend on it hard, that floor was theirs too: a mod could declare a lower Fabric API requirement of its own and still be blocked, because the library's number won. On **1.20.1** that meant Fabric API 0.92.11 or nothing. It now accepts **0.92.8 and up**, which is what people asked for — 0.92.11 clashes with a couple of other mods. The other Minecraft versions keep the same floor they had; the difference is that it is now a real minimum rather than whatever the build machine happened to use. Nothing else changed. Forge and NeoForge builds are unaffected, and no API changed, so there is no reason to raise your version range.

# CodxLib 1.5.1 *This file is for **Forge 1.21.7**. Every loader ships the same CodxLib version, so the notes below apply here too.* **Fabric only, one fix: CodxLib no longer refuses older builds of Fabric API.** Every Fabric jar was declaring the exact Fabric API build it had been compiled against as its minimum, instead of the oldest one it actually works with. Anything older was rejected outright — even though nothing in the library needed the newer build. Because mods that use CodxLib depend on it hard, that floor was theirs too: a mod could declare a lower Fabric API requirement of its own and still be blocked, because the library's number won. On **1.20.1** that meant Fabric API 0.92.11 or nothing. It now accepts **0.92.8 and up**, which is what people asked for — 0.92.11 clashes with a couple of other mods. The other Minecraft versions keep the same floor they had; the difference is that it is now a real minimum rather than whatever the build machine happened to use. Nothing else changed. Forge and NeoForge builds are unaffected, and no API changed, so there is no reason to raise your version range.

# CodxLib 1.5.1 *This file is for **Fabric 1.21.7**. It requires **Fabric Loader 0.16.13 or newer** — exactly what Fabric API already needs on 1.21.7, so CodxLib adds no restriction of its own — and **Fabric API 0.129.0+1.21.7 or newer**.* **Fabric only, one fix: CodxLib no longer refuses older builds of Fabric API.** Every Fabric jar was declaring the exact Fabric API build it had been compiled against as its minimum, instead of the oldest one it actually works with. Anything older was rejected outright — even though nothing in the library needed the newer build. Because mods that use CodxLib depend on it hard, that floor was theirs too: a mod could declare a lower Fabric API requirement of its own and still be blocked, because the library's number won. On **1.20.1** that meant Fabric API 0.92.11 or nothing. It now accepts **0.92.8 and up**, which is what people asked for — 0.92.11 clashes with a couple of other mods. The other Minecraft versions keep the same floor they had; the difference is that it is now a real minimum rather than whatever the build machine happened to use. Nothing else changed. Forge and NeoForge builds are unaffected, and no API changed, so there is no reason to raise your version range.

# CodxLib 1.5.1 *This file is for **NeoForge 1.21.6**. Every loader ships the same CodxLib version, so the notes below apply here too.* **Fabric only, one fix: CodxLib no longer refuses older builds of Fabric API.** Every Fabric jar was declaring the exact Fabric API build it had been compiled against as its minimum, instead of the oldest one it actually works with. Anything older was rejected outright — even though nothing in the library needed the newer build. Because mods that use CodxLib depend on it hard, that floor was theirs too: a mod could declare a lower Fabric API requirement of its own and still be blocked, because the library's number won. On **1.20.1** that meant Fabric API 0.92.11 or nothing. It now accepts **0.92.8 and up**, which is what people asked for — 0.92.11 clashes with a couple of other mods. The other Minecraft versions keep the same floor they had; the difference is that it is now a real minimum rather than whatever the build machine happened to use. Nothing else changed. Forge and NeoForge builds are unaffected, and no API changed, so there is no reason to raise your version range.

# CodxLib 1.5.1 *This file is for **Forge 1.21.6**. Every loader ships the same CodxLib version, so the notes below apply here too.* **Fabric only, one fix: CodxLib no longer refuses older builds of Fabric API.** Every Fabric jar was declaring the exact Fabric API build it had been compiled against as its minimum, instead of the oldest one it actually works with. Anything older was rejected outright — even though nothing in the library needed the newer build. Because mods that use CodxLib depend on it hard, that floor was theirs too: a mod could declare a lower Fabric API requirement of its own and still be blocked, because the library's number won. On **1.20.1** that meant Fabric API 0.92.11 or nothing. It now accepts **0.92.8 and up**, which is what people asked for — 0.92.11 clashes with a couple of other mods. The other Minecraft versions keep the same floor they had; the difference is that it is now a real minimum rather than whatever the build machine happened to use. Nothing else changed. Forge and NeoForge builds are unaffected, and no API changed, so there is no reason to raise your version range.

# CodxLib 1.5.1 *This file is for **Fabric 1.21.6**. It requires **Fabric Loader 0.16.13 or newer** — exactly what Fabric API already needs on 1.21.6, so CodxLib adds no restriction of its own — and **Fabric API 0.128.2+1.21.6 or newer**.* **Fabric only, one fix: CodxLib no longer refuses older builds of Fabric API.** Every Fabric jar was declaring the exact Fabric API build it had been compiled against as its minimum, instead of the oldest one it actually works with. Anything older was rejected outright — even though nothing in the library needed the newer build. Because mods that use CodxLib depend on it hard, that floor was theirs too: a mod could declare a lower Fabric API requirement of its own and still be blocked, because the library's number won. On **1.20.1** that meant Fabric API 0.92.11 or nothing. It now accepts **0.92.8 and up**, which is what people asked for — 0.92.11 clashes with a couple of other mods. The other Minecraft versions keep the same floor they had; the difference is that it is now a real minimum rather than whatever the build machine happened to use. Nothing else changed. Forge and NeoForge builds are unaffected, and no API changed, so there is no reason to raise your version range.

# CodxLib 1.5.1 *This file is for **NeoForge 1.21.5**. Every loader ships the same CodxLib version, so the notes below apply here too.* **Fabric only, one fix: CodxLib no longer refuses older builds of Fabric API.** Every Fabric jar was declaring the exact Fabric API build it had been compiled against as its minimum, instead of the oldest one it actually works with. Anything older was rejected outright — even though nothing in the library needed the newer build. Because mods that use CodxLib depend on it hard, that floor was theirs too: a mod could declare a lower Fabric API requirement of its own and still be blocked, because the library's number won. On **1.20.1** that meant Fabric API 0.92.11 or nothing. It now accepts **0.92.8 and up**, which is what people asked for — 0.92.11 clashes with a couple of other mods. The other Minecraft versions keep the same floor they had; the difference is that it is now a real minimum rather than whatever the build machine happened to use. Nothing else changed. Forge and NeoForge builds are unaffected, and no API changed, so there is no reason to raise your version range.

# CodxLib 1.5.1 *This file is for **Forge 1.21.5**. Every loader ships the same CodxLib version, so the notes below apply here too.* **Fabric only, one fix: CodxLib no longer refuses older builds of Fabric API.** Every Fabric jar was declaring the exact Fabric API build it had been compiled against as its minimum, instead of the oldest one it actually works with. Anything older was rejected outright — even though nothing in the library needed the newer build. Because mods that use CodxLib depend on it hard, that floor was theirs too: a mod could declare a lower Fabric API requirement of its own and still be blocked, because the library's number won. On **1.20.1** that meant Fabric API 0.92.11 or nothing. It now accepts **0.92.8 and up**, which is what people asked for — 0.92.11 clashes with a couple of other mods. The other Minecraft versions keep the same floor they had; the difference is that it is now a real minimum rather than whatever the build machine happened to use. Nothing else changed. Forge and NeoForge builds are unaffected, and no API changed, so there is no reason to raise your version range.

# CodxLib 1.5.1 *This file is for **Fabric 1.21.5**. It requires **Fabric Loader 0.16.10 or newer** — exactly what Fabric API already needs on 1.21.5, so CodxLib adds no restriction of its own — and **Fabric API 0.128.2+1.21.5 or newer**.* **Fabric only, one fix: CodxLib no longer refuses older builds of Fabric API.** Every Fabric jar was declaring the exact Fabric API build it had been compiled against as its minimum, instead of the oldest one it actually works with. Anything older was rejected outright — even though nothing in the library needed the newer build. Because mods that use CodxLib depend on it hard, that floor was theirs too: a mod could declare a lower Fabric API requirement of its own and still be blocked, because the library's number won. On **1.20.1** that meant Fabric API 0.92.11 or nothing. It now accepts **0.92.8 and up**, which is what people asked for — 0.92.11 clashes with a couple of other mods. The other Minecraft versions keep the same floor they had; the difference is that it is now a real minimum rather than whatever the build machine happened to use. Nothing else changed. Forge and NeoForge builds are unaffected, and no API changed, so there is no reason to raise your version range.

# CodxLib 1.5.1 *This file is for **NeoForge 1.21.4**. Every loader ships the same CodxLib version, so the notes below apply here too.* **Fabric only, one fix: CodxLib no longer refuses older builds of Fabric API.** Every Fabric jar was declaring the exact Fabric API build it had been compiled against as its minimum, instead of the oldest one it actually works with. Anything older was rejected outright — even though nothing in the library needed the newer build. Because mods that use CodxLib depend on it hard, that floor was theirs too: a mod could declare a lower Fabric API requirement of its own and still be blocked, because the library's number won. On **1.20.1** that meant Fabric API 0.92.11 or nothing. It now accepts **0.92.8 and up**, which is what people asked for — 0.92.11 clashes with a couple of other mods. The other Minecraft versions keep the same floor they had; the difference is that it is now a real minimum rather than whatever the build machine happened to use. Nothing else changed. Forge and NeoForge builds are unaffected, and no API changed, so there is no reason to raise your version range.

# CodxLib 1.5.1 *This file is for **Forge 1.21.4**. Every loader ships the same CodxLib version, so the notes below apply here too.* **Fabric only, one fix: CodxLib no longer refuses older builds of Fabric API.** Every Fabric jar was declaring the exact Fabric API build it had been compiled against as its minimum, instead of the oldest one it actually works with. Anything older was rejected outright — even though nothing in the library needed the newer build. Because mods that use CodxLib depend on it hard, that floor was theirs too: a mod could declare a lower Fabric API requirement of its own and still be blocked, because the library's number won. On **1.20.1** that meant Fabric API 0.92.11 or nothing. It now accepts **0.92.8 and up**, which is what people asked for — 0.92.11 clashes with a couple of other mods. The other Minecraft versions keep the same floor they had; the difference is that it is now a real minimum rather than whatever the build machine happened to use. Nothing else changed. Forge and NeoForge builds are unaffected, and no API changed, so there is no reason to raise your version range.

# CodxLib 1.5.1 *This file is for **Fabric 1.21.4**. It requires **Fabric Loader 0.16.9 or newer** — exactly what Fabric API already needs on 1.21.4, so CodxLib adds no restriction of its own — and **Fabric API 0.119.4+1.21.4 or newer**.* **Fabric only, one fix: CodxLib no longer refuses older builds of Fabric API.** Every Fabric jar was declaring the exact Fabric API build it had been compiled against as its minimum, instead of the oldest one it actually works with. Anything older was rejected outright — even though nothing in the library needed the newer build. Because mods that use CodxLib depend on it hard, that floor was theirs too: a mod could declare a lower Fabric API requirement of its own and still be blocked, because the library's number won. On **1.20.1** that meant Fabric API 0.92.11 or nothing. It now accepts **0.92.8 and up**, which is what people asked for — 0.92.11 clashes with a couple of other mods. The other Minecraft versions keep the same floor they had; the difference is that it is now a real minimum rather than whatever the build machine happened to use. Nothing else changed. Forge and NeoForge builds are unaffected, and no API changed, so there is no reason to raise your version range.

# CodxLib 1.5.1 *This file is for **NeoForge 1.21.3**. Every loader ships the same CodxLib version, so the notes below apply here too.* **Fabric only, one fix: CodxLib no longer refuses older builds of Fabric API.** Every Fabric jar was declaring the exact Fabric API build it had been compiled against as its minimum, instead of the oldest one it actually works with. Anything older was rejected outright — even though nothing in the library needed the newer build. Because mods that use CodxLib depend on it hard, that floor was theirs too: a mod could declare a lower Fabric API requirement of its own and still be blocked, because the library's number won. On **1.20.1** that meant Fabric API 0.92.11 or nothing. It now accepts **0.92.8 and up**, which is what people asked for — 0.92.11 clashes with a couple of other mods. The other Minecraft versions keep the same floor they had; the difference is that it is now a real minimum rather than whatever the build machine happened to use. Nothing else changed. Forge and NeoForge builds are unaffected, and no API changed, so there is no reason to raise your version range.

# CodxLib 1.5.1 *This file is for **Forge 1.21.3**. Every loader ships the same CodxLib version, so the notes below apply here too.* **Fabric only, one fix: CodxLib no longer refuses older builds of Fabric API.** Every Fabric jar was declaring the exact Fabric API build it had been compiled against as its minimum, instead of the oldest one it actually works with. Anything older was rejected outright — even though nothing in the library needed the newer build. Because mods that use CodxLib depend on it hard, that floor was theirs too: a mod could declare a lower Fabric API requirement of its own and still be blocked, because the library's number won. On **1.20.1** that meant Fabric API 0.92.11 or nothing. It now accepts **0.92.8 and up**, which is what people asked for — 0.92.11 clashes with a couple of other mods. The other Minecraft versions keep the same floor they had; the difference is that it is now a real minimum rather than whatever the build machine happened to use. Nothing else changed. Forge and NeoForge builds are unaffected, and no API changed, so there is no reason to raise your version range.

# CodxLib 1.5.1 *This file is for **Fabric 1.21.3**. It requires **Fabric Loader 0.16.8 or newer** — exactly what Fabric API already needs on 1.21.3, so CodxLib adds no restriction of its own — and **Fabric API 0.114.1+1.21.3 or newer**.* **Fabric only, one fix: CodxLib no longer refuses older builds of Fabric API.** Every Fabric jar was declaring the exact Fabric API build it had been compiled against as its minimum, instead of the oldest one it actually works with. Anything older was rejected outright — even though nothing in the library needed the newer build. Because mods that use CodxLib depend on it hard, that floor was theirs too: a mod could declare a lower Fabric API requirement of its own and still be blocked, because the library's number won. On **1.20.1** that meant Fabric API 0.92.11 or nothing. It now accepts **0.92.8 and up**, which is what people asked for — 0.92.11 clashes with a couple of other mods. The other Minecraft versions keep the same floor they had; the difference is that it is now a real minimum rather than whatever the build machine happened to use. Nothing else changed. Forge and NeoForge builds are unaffected, and no API changed, so there is no reason to raise your version range.

# CodxLib 1.5.1 *This file is for **NeoForge 1.21.2**. Every loader ships the same CodxLib version, so the notes below apply here too.* **Fabric only, one fix: CodxLib no longer refuses older builds of Fabric API.** Every Fabric jar was declaring the exact Fabric API build it had been compiled against as its minimum, instead of the oldest one it actually works with. Anything older was rejected outright — even though nothing in the library needed the newer build. Because mods that use CodxLib depend on it hard, that floor was theirs too: a mod could declare a lower Fabric API requirement of its own and still be blocked, because the library's number won. On **1.20.1** that meant Fabric API 0.92.11 or nothing. It now accepts **0.92.8 and up**, which is what people asked for — 0.92.11 clashes with a couple of other mods. The other Minecraft versions keep the same floor they had; the difference is that it is now a real minimum rather than whatever the build machine happened to use. Nothing else changed. Forge and NeoForge builds are unaffected, and no API changed, so there is no reason to raise your version range.

# CodxLib 1.5.1 *This file is for **Fabric 1.21.2**. It requires **Fabric Loader 0.16.7 or newer** — exactly what Fabric API already needs on 1.21.2, so CodxLib adds no restriction of its own — and **Fabric API 0.106.1+1.21.2 or newer**.* **Fabric only, one fix: CodxLib no longer refuses older builds of Fabric API.** Every Fabric jar was declaring the exact Fabric API build it had been compiled against as its minimum, instead of the oldest one it actually works with. Anything older was rejected outright — even though nothing in the library needed the newer build. Because mods that use CodxLib depend on it hard, that floor was theirs too: a mod could declare a lower Fabric API requirement of its own and still be blocked, because the library's number won. On **1.20.1** that meant Fabric API 0.92.11 or nothing. It now accepts **0.92.8 and up**, which is what people asked for — 0.92.11 clashes with a couple of other mods. The other Minecraft versions keep the same floor they had; the difference is that it is now a real minimum rather than whatever the build machine happened to use. Nothing else changed. Forge and NeoForge builds are unaffected, and no API changed, so there is no reason to raise your version range.

# CodxLib 1.5.1 *This file is for **NeoForge 1.21.1**. Every loader ships the same CodxLib version, so the notes below apply here too.* **Fabric only, one fix: CodxLib no longer refuses older builds of Fabric API.** Every Fabric jar was declaring the exact Fabric API build it had been compiled against as its minimum, instead of the oldest one it actually works with. Anything older was rejected outright — even though nothing in the library needed the newer build. Because mods that use CodxLib depend on it hard, that floor was theirs too: a mod could declare a lower Fabric API requirement of its own and still be blocked, because the library's number won. On **1.20.1** that meant Fabric API 0.92.11 or nothing. It now accepts **0.92.8 and up**, which is what people asked for — 0.92.11 clashes with a couple of other mods. The other Minecraft versions keep the same floor they had; the difference is that it is now a real minimum rather than whatever the build machine happened to use. Nothing else changed. Forge and NeoForge builds are unaffected, and no API changed, so there is no reason to raise your version range.

# CodxLib 1.5.1 *This file is for **Forge 1.21.1**. Every loader ships the same CodxLib version, so the notes below apply here too.* **Fabric only, one fix: CodxLib no longer refuses older builds of Fabric API.** Every Fabric jar was declaring the exact Fabric API build it had been compiled against as its minimum, instead of the oldest one it actually works with. Anything older was rejected outright — even though nothing in the library needed the newer build. Because mods that use CodxLib depend on it hard, that floor was theirs too: a mod could declare a lower Fabric API requirement of its own and still be blocked, because the library's number won. On **1.20.1** that meant Fabric API 0.92.11 or nothing. It now accepts **0.92.8 and up**, which is what people asked for — 0.92.11 clashes with a couple of other mods. The other Minecraft versions keep the same floor they had; the difference is that it is now a real minimum rather than whatever the build machine happened to use. Nothing else changed. Forge and NeoForge builds are unaffected, and no API changed, so there is no reason to raise your version range.

# CodxLib 1.5.1 *This file is for **Fabric 1.21.1**. It requires **Fabric Loader 0.15.11 or newer** — exactly what Fabric API already needs on 1.21.1, so CodxLib adds no restriction of its own — and **Fabric API 0.116.4+1.21.1 or newer**.* **Fabric only, one fix: CodxLib no longer refuses older builds of Fabric API.** Every Fabric jar was declaring the exact Fabric API build it had been compiled against as its minimum, instead of the oldest one it actually works with. Anything older was rejected outright — even though nothing in the library needed the newer build. Because mods that use CodxLib depend on it hard, that floor was theirs too: a mod could declare a lower Fabric API requirement of its own and still be blocked, because the library's number won. On **1.20.1** that meant Fabric API 0.92.11 or nothing. It now accepts **0.92.8 and up**, which is what people asked for — 0.92.11 clashes with a couple of other mods. The other Minecraft versions keep the same floor they had; the difference is that it is now a real minimum rather than whatever the build machine happened to use. Nothing else changed. Forge and NeoForge builds are unaffected, and no API changed, so there is no reason to raise your version range.

# CodxLib 1.5.1 *This file is for **NeoForge 1.21**. Every loader ships the same CodxLib version, so the notes below apply here too.* **Fabric only, one fix: CodxLib no longer refuses older builds of Fabric API.** Every Fabric jar was declaring the exact Fabric API build it had been compiled against as its minimum, instead of the oldest one it actually works with. Anything older was rejected outright — even though nothing in the library needed the newer build. Because mods that use CodxLib depend on it hard, that floor was theirs too: a mod could declare a lower Fabric API requirement of its own and still be blocked, because the library's number won. On **1.20.1** that meant Fabric API 0.92.11 or nothing. It now accepts **0.92.8 and up**, which is what people asked for — 0.92.11 clashes with a couple of other mods. The other Minecraft versions keep the same floor they had; the difference is that it is now a real minimum rather than whatever the build machine happened to use. Nothing else changed. Forge and NeoForge builds are unaffected, and no API changed, so there is no reason to raise your version range.

# CodxLib 1.5.1 *This file is for **Forge 1.21**. Every loader ships the same CodxLib version, so the notes below apply here too.* **Fabric only, one fix: CodxLib no longer refuses older builds of Fabric API.** Every Fabric jar was declaring the exact Fabric API build it had been compiled against as its minimum, instead of the oldest one it actually works with. Anything older was rejected outright — even though nothing in the library needed the newer build. Because mods that use CodxLib depend on it hard, that floor was theirs too: a mod could declare a lower Fabric API requirement of its own and still be blocked, because the library's number won. On **1.20.1** that meant Fabric API 0.92.11 or nothing. It now accepts **0.92.8 and up**, which is what people asked for — 0.92.11 clashes with a couple of other mods. The other Minecraft versions keep the same floor they had; the difference is that it is now a real minimum rather than whatever the build machine happened to use. Nothing else changed. Forge and NeoForge builds are unaffected, and no API changed, so there is no reason to raise your version range.

# CodxLib 1.5.1 *This file is for **Fabric 1.21**. It requires **Fabric Loader 0.15.11 or newer** — exactly what Fabric API already needs on 1.21, so CodxLib adds no restriction of its own — and **Fabric API 0.102.0+1.21 or newer**.* **Fabric only, one fix: CodxLib no longer refuses older builds of Fabric API.** Every Fabric jar was declaring the exact Fabric API build it had been compiled against as its minimum, instead of the oldest one it actually works with. Anything older was rejected outright — even though nothing in the library needed the newer build. Because mods that use CodxLib depend on it hard, that floor was theirs too: a mod could declare a lower Fabric API requirement of its own and still be blocked, because the library's number won. On **1.20.1** that meant Fabric API 0.92.11 or nothing. It now accepts **0.92.8 and up**, which is what people asked for — 0.92.11 clashes with a couple of other mods. The other Minecraft versions keep the same floor they had; the difference is that it is now a real minimum rather than whatever the build machine happened to use. Nothing else changed. Forge and NeoForge builds are unaffected, and no API changed, so there is no reason to raise your version range.

# CodxLib 1.5.1 *This file is for **NeoForge 1.20.6**. Every loader ships the same CodxLib version, so the notes below apply here too.* **Fabric only, one fix: CodxLib no longer refuses older builds of Fabric API.** Every Fabric jar was declaring the exact Fabric API build it had been compiled against as its minimum, instead of the oldest one it actually works with. Anything older was rejected outright — even though nothing in the library needed the newer build. Because mods that use CodxLib depend on it hard, that floor was theirs too: a mod could declare a lower Fabric API requirement of its own and still be blocked, because the library's number won. On **1.20.1** that meant Fabric API 0.92.11 or nothing. It now accepts **0.92.8 and up**, which is what people asked for — 0.92.11 clashes with a couple of other mods. The other Minecraft versions keep the same floor they had; the difference is that it is now a real minimum rather than whatever the build machine happened to use. Nothing else changed. Forge and NeoForge builds are unaffected, and no API changed, so there is no reason to raise your version range.

# CodxLib 1.5.1 *This file is for **Forge 1.20.6**. Every loader ships the same CodxLib version, so the notes below apply here too.* **Fabric only, one fix: CodxLib no longer refuses older builds of Fabric API.** Every Fabric jar was declaring the exact Fabric API build it had been compiled against as its minimum, instead of the oldest one it actually works with. Anything older was rejected outright — even though nothing in the library needed the newer build. Because mods that use CodxLib depend on it hard, that floor was theirs too: a mod could declare a lower Fabric API requirement of its own and still be blocked, because the library's number won. On **1.20.1** that meant Fabric API 0.92.11 or nothing. It now accepts **0.92.8 and up**, which is what people asked for — 0.92.11 clashes with a couple of other mods. The other Minecraft versions keep the same floor they had; the difference is that it is now a real minimum rather than whatever the build machine happened to use. Nothing else changed. Forge and NeoForge builds are unaffected, and no API changed, so there is no reason to raise your version range.

# CodxLib 1.5.1 *This file is for **Fabric 1.20.6**. It requires **Fabric Loader 0.15.6 or newer** — exactly what Fabric API already needs on 1.20.6, so CodxLib adds no restriction of its own — and **Fabric API 0.100.8+1.20.6 or newer**.* **Fabric only, one fix: CodxLib no longer refuses older builds of Fabric API.** Every Fabric jar was declaring the exact Fabric API build it had been compiled against as its minimum, instead of the oldest one it actually works with. Anything older was rejected outright — even though nothing in the library needed the newer build. Because mods that use CodxLib depend on it hard, that floor was theirs too: a mod could declare a lower Fabric API requirement of its own and still be blocked, because the library's number won. On **1.20.1** that meant Fabric API 0.92.11 or nothing. It now accepts **0.92.8 and up**, which is what people asked for — 0.92.11 clashes with a couple of other mods. The other Minecraft versions keep the same floor they had; the difference is that it is now a real minimum rather than whatever the build machine happened to use. Nothing else changed. Forge and NeoForge builds are unaffected, and no API changed, so there is no reason to raise your version range.

# CodxLib 1.5.1 *This file is for **Fabric 1.20.5**. It requires **Fabric Loader 0.15.6 or newer** — exactly what Fabric API already needs on 1.20.5, so CodxLib adds no restriction of its own — and **Fabric API 0.97.8+1.20.5 or newer**.* **Fabric only, one fix: CodxLib no longer refuses older builds of Fabric API.** Every Fabric jar was declaring the exact Fabric API build it had been compiled against as its minimum, instead of the oldest one it actually works with. Anything older was rejected outright — even though nothing in the library needed the newer build. Because mods that use CodxLib depend on it hard, that floor was theirs too: a mod could declare a lower Fabric API requirement of its own and still be blocked, because the library's number won. On **1.20.1** that meant Fabric API 0.92.11 or nothing. It now accepts **0.92.8 and up**, which is what people asked for — 0.92.11 clashes with a couple of other mods. The other Minecraft versions keep the same floor they had; the difference is that it is now a real minimum rather than whatever the build machine happened to use. Nothing else changed. Forge and NeoForge builds are unaffected, and no API changed, so there is no reason to raise your version range.

# CodxLib 1.5.1 *This file is for **NeoForge 1.20.4**. Every loader ships the same CodxLib version, so the notes below apply here too.* **Fabric only, one fix: CodxLib no longer refuses older builds of Fabric API.** Every Fabric jar was declaring the exact Fabric API build it had been compiled against as its minimum, instead of the oldest one it actually works with. Anything older was rejected outright — even though nothing in the library needed the newer build. Because mods that use CodxLib depend on it hard, that floor was theirs too: a mod could declare a lower Fabric API requirement of its own and still be blocked, because the library's number won. On **1.20.1** that meant Fabric API 0.92.11 or nothing. It now accepts **0.92.8 and up**, which is what people asked for — 0.92.11 clashes with a couple of other mods. The other Minecraft versions keep the same floor they had; the difference is that it is now a real minimum rather than whatever the build machine happened to use. Nothing else changed. Forge and NeoForge builds are unaffected, and no API changed, so there is no reason to raise your version range.

# CodxLib 1.5.1 *This file is for **Forge 1.20.4**. Every loader ships the same CodxLib version, so the notes below apply here too.* **Fabric only, one fix: CodxLib no longer refuses older builds of Fabric API.** Every Fabric jar was declaring the exact Fabric API build it had been compiled against as its minimum, instead of the oldest one it actually works with. Anything older was rejected outright — even though nothing in the library needed the newer build. Because mods that use CodxLib depend on it hard, that floor was theirs too: a mod could declare a lower Fabric API requirement of its own and still be blocked, because the library's number won. On **1.20.1** that meant Fabric API 0.92.11 or nothing. It now accepts **0.92.8 and up**, which is what people asked for — 0.92.11 clashes with a couple of other mods. The other Minecraft versions keep the same floor they had; the difference is that it is now a real minimum rather than whatever the build machine happened to use. Nothing else changed. Forge and NeoForge builds are unaffected, and no API changed, so there is no reason to raise your version range.

# CodxLib 1.5.1 *This file is for **Fabric 1.20.4**. It requires **Fabric Loader 0.15.1 or newer** — exactly what Fabric API already needs on 1.20.4, so CodxLib adds no restriction of its own — and **Fabric API 0.97.3+1.20.4 or newer**.* **Fabric only, one fix: CodxLib no longer refuses older builds of Fabric API.** Every Fabric jar was declaring the exact Fabric API build it had been compiled against as its minimum, instead of the oldest one it actually works with. Anything older was rejected outright — even though nothing in the library needed the newer build. Because mods that use CodxLib depend on it hard, that floor was theirs too: a mod could declare a lower Fabric API requirement of its own and still be blocked, because the library's number won. On **1.20.1** that meant Fabric API 0.92.11 or nothing. It now accepts **0.92.8 and up**, which is what people asked for — 0.92.11 clashes with a couple of other mods. The other Minecraft versions keep the same floor they had; the difference is that it is now a real minimum rather than whatever the build machine happened to use. Nothing else changed. Forge and NeoForge builds are unaffected, and no API changed, so there is no reason to raise your version range.

# CodxLib 1.5.1 *This file is for **Fabric 1.20.3**. It requires **Fabric Loader 0.14.23 or newer** — exactly what Fabric API already needs on 1.20.3, so CodxLib adds no restriction of its own — and **Fabric API 0.91.1+1.20.3 or newer**.* **Fabric only, one fix: CodxLib no longer refuses older builds of Fabric API.** Every Fabric jar was declaring the exact Fabric API build it had been compiled against as its minimum, instead of the oldest one it actually works with. Anything older was rejected outright — even though nothing in the library needed the newer build. Because mods that use CodxLib depend on it hard, that floor was theirs too: a mod could declare a lower Fabric API requirement of its own and still be blocked, because the library's number won. On **1.20.1** that meant Fabric API 0.92.11 or nothing. It now accepts **0.92.8 and up**, which is what people asked for — 0.92.11 clashes with a couple of other mods. The other Minecraft versions keep the same floor they had; the difference is that it is now a real minimum rather than whatever the build machine happened to use. Nothing else changed. Forge and NeoForge builds are unaffected, and no API changed, so there is no reason to raise your version range.

# CodxLib 1.5.1 *This file is for **Fabric 1.20.2**. It requires **Fabric Loader 0.14.22 or newer** — exactly what Fabric API already needs on 1.20.2, so CodxLib adds no restriction of its own — and **Fabric API 0.91.6+1.20.2 or newer**.* **Fabric only, one fix: CodxLib no longer refuses older builds of Fabric API.** Every Fabric jar was declaring the exact Fabric API build it had been compiled against as its minimum, instead of the oldest one it actually works with. Anything older was rejected outright — even though nothing in the library needed the newer build. Because mods that use CodxLib depend on it hard, that floor was theirs too: a mod could declare a lower Fabric API requirement of its own and still be blocked, because the library's number won. On **1.20.1** that meant Fabric API 0.92.11 or nothing. It now accepts **0.92.8 and up**, which is what people asked for — 0.92.11 clashes with a couple of other mods. The other Minecraft versions keep the same floor they had; the difference is that it is now a real minimum rather than whatever the build machine happened to use. Nothing else changed. Forge and NeoForge builds are unaffected, and no API changed, so there is no reason to raise your version range.

# CodxLib 1.5.1 *This file is for **Forge 1.20.1**. Every loader ships the same CodxLib version, so the notes below apply here too.* **Fabric only, one fix: CodxLib no longer refuses older builds of Fabric API.** Every Fabric jar was declaring the exact Fabric API build it had been compiled against as its minimum, instead of the oldest one it actually works with. Anything older was rejected outright — even though nothing in the library needed the newer build. Because mods that use CodxLib depend on it hard, that floor was theirs too: a mod could declare a lower Fabric API requirement of its own and still be blocked, because the library's number won. On **1.20.1** that meant Fabric API 0.92.11 or nothing. It now accepts **0.92.8 and up**, which is what people asked for — 0.92.11 clashes with a couple of other mods. The other Minecraft versions keep the same floor they had; the difference is that it is now a real minimum rather than whatever the build machine happened to use. Nothing else changed. Forge and NeoForge builds are unaffected, and no API changed, so there is no reason to raise your version range.

# CodxLib 1.5.1 *This file is for **Fabric 1.20.1**. It requires **Fabric Loader 0.16.10 or newer** — exactly what Fabric API already needs on 1.20.1, so CodxLib adds no restriction of its own — and **Fabric API 0.92.8+1.20.1 or newer**.* **Fabric only, one fix: CodxLib no longer refuses older builds of Fabric API.** Every Fabric jar was declaring the exact Fabric API build it had been compiled against as its minimum, instead of the oldest one it actually works with. Anything older was rejected outright — even though nothing in the library needed the newer build. Because mods that use CodxLib depend on it hard, that floor was theirs too: a mod could declare a lower Fabric API requirement of its own and still be blocked, because the library's number won. On **1.20.1** that meant Fabric API 0.92.11 or nothing. It now accepts **0.92.8 and up**, which is what people asked for — 0.92.11 clashes with a couple of other mods. The other Minecraft versions keep the same floor they had; the difference is that it is now a real minimum rather than whatever the build machine happened to use. Nothing else changed. Forge and NeoForge builds are unaffected, and no API changed, so there is no reason to raise your version range.

# CodxLib 1.5.0 *This file is for **NeoForge 26.2**. Every loader ships the same CodxLib version, so the notes below apply here too.* **`/codxlib help` now also writes a `.mrpack`.** Drop that one file into the Modrinth App (**Add instance → From file**) and it rebuilds the instance the report came from: same Minecraft version, same loader, every mod it can find on Modrinth, the codx mods' settings, and a world on **the same seed**. "It crashes on my world" becomes a single attachment. - The world travels as settings, not terrain — only `level.dat`, so Minecraft regenerates from your seed. A few kilobytes, and nothing you have built is in it. - Mods that aren't on Modrinth (CurseForge-only, private, self-edited) are listed in the pack's `codxlib-debug/README.txt` to add by hand, never dropped silently. No jars are copied in. - **`/codxlib pack`** writes just the modpack. Same permissions as `/codxlib help`. **Developers:** new `CodxInstancePack.writeAsync(server)` and `CodxLib.gameDir()` / `IPlatformHelper#getGameDir()` — **a mod shipping its own `IPlatformHelper` must implement it.** Nothing else from 1.4.x changed; raise your range to `[1.5.0,)` only if you use the new API.

# CodxLib 1.5.0 *This file is for **Forge 26.2**. Every loader ships the same CodxLib version, so the notes below apply here too.* **`/codxlib help` now also writes a `.mrpack`.** Drop that one file into the Modrinth App (**Add instance → From file**) and it rebuilds the instance the report came from: same Minecraft version, same loader, every mod it can find on Modrinth, the codx mods' settings, and a world on **the same seed**. "It crashes on my world" becomes a single attachment. - The world travels as settings, not terrain — only `level.dat`, so Minecraft regenerates from your seed. A few kilobytes, and nothing you have built is in it. - Mods that aren't on Modrinth (CurseForge-only, private, self-edited) are listed in the pack's `codxlib-debug/README.txt` to add by hand, never dropped silently. No jars are copied in. - **`/codxlib pack`** writes just the modpack. Same permissions as `/codxlib help`. **Developers:** new `CodxInstancePack.writeAsync(server)` and `CodxLib.gameDir()` / `IPlatformHelper#getGameDir()` — **a mod shipping its own `IPlatformHelper` must implement it.** Nothing else from 1.4.x changed; raise your range to `[1.5.0,)` only if you use the new API.

# CodxLib 1.5.0 *This file is for **Fabric 26.2**. It requires **Fabric Loader 0.18.4 or newer** — exactly what Fabric API already needs on 26.2, so CodxLib adds no restriction of its own.* **`/codxlib help` now also writes a `.mrpack`.** Drop that one file into the Modrinth App (**Add instance → From file**) and it rebuilds the instance the report came from: same Minecraft version, same loader, every mod it can find on Modrinth, the codx mods' settings, and a world on **the same seed**. "It crashes on my world" becomes a single attachment. - The world travels as settings, not terrain — only `level.dat`, so Minecraft regenerates from your seed. A few kilobytes, and nothing you have built is in it. - Mods that aren't on Modrinth (CurseForge-only, private, self-edited) are listed in the pack's `codxlib-debug/README.txt` to add by hand, never dropped silently. No jars are copied in. - **`/codxlib pack`** writes just the modpack. Same permissions as `/codxlib help`. **Developers:** new `CodxInstancePack.writeAsync(server)` and `CodxLib.gameDir()` / `IPlatformHelper#getGameDir()` — **a mod shipping its own `IPlatformHelper` must implement it.** Nothing else from 1.4.x changed; raise your range to `[1.5.0,)` only if you use the new API.

# CodxLib 1.5.0 *This file is for **NeoForge 26.1.2**. Every loader ships the same CodxLib version, so the notes below apply here too.* **`/codxlib help` now also writes a `.mrpack`.** Drop that one file into the Modrinth App (**Add instance → From file**) and it rebuilds the instance the report came from: same Minecraft version, same loader, every mod it can find on Modrinth, the codx mods' settings, and a world on **the same seed**. "It crashes on my world" becomes a single attachment. - The world travels as settings, not terrain — only `level.dat`, so Minecraft regenerates from your seed. A few kilobytes, and nothing you have built is in it. - Mods that aren't on Modrinth (CurseForge-only, private, self-edited) are listed in the pack's `codxlib-debug/README.txt` to add by hand, never dropped silently. No jars are copied in. - **`/codxlib pack`** writes just the modpack. Same permissions as `/codxlib help`. **Developers:** new `CodxInstancePack.writeAsync(server)` and `CodxLib.gameDir()` / `IPlatformHelper#getGameDir()` — **a mod shipping its own `IPlatformHelper` must implement it.** Nothing else from 1.4.x changed; raise your range to `[1.5.0,)` only if you use the new API.

# CodxLib 1.5.0 *This file is for **Forge 26.1.2**. Every loader ships the same CodxLib version, so the notes below apply here too.* **`/codxlib help` now also writes a `.mrpack`.** Drop that one file into the Modrinth App (**Add instance → From file**) and it rebuilds the instance the report came from: same Minecraft version, same loader, every mod it can find on Modrinth, the codx mods' settings, and a world on **the same seed**. "It crashes on my world" becomes a single attachment. - The world travels as settings, not terrain — only `level.dat`, so Minecraft regenerates from your seed. A few kilobytes, and nothing you have built is in it. - Mods that aren't on Modrinth (CurseForge-only, private, self-edited) are listed in the pack's `codxlib-debug/README.txt` to add by hand, never dropped silently. No jars are copied in. - **`/codxlib pack`** writes just the modpack. Same permissions as `/codxlib help`. **Developers:** new `CodxInstancePack.writeAsync(server)` and `CodxLib.gameDir()` / `IPlatformHelper#getGameDir()` — **a mod shipping its own `IPlatformHelper` must implement it.** Nothing else from 1.4.x changed; raise your range to `[1.5.0,)` only if you use the new API.

# CodxLib 1.5.0 *This file is for **Fabric 26.1.2**. It requires **Fabric Loader 0.18.4 or newer** — exactly what Fabric API already needs on 26.1.2, so CodxLib adds no restriction of its own.* **`/codxlib help` now also writes a `.mrpack`.** Drop that one file into the Modrinth App (**Add instance → From file**) and it rebuilds the instance the report came from: same Minecraft version, same loader, every mod it can find on Modrinth, the codx mods' settings, and a world on **the same seed**. "It crashes on my world" becomes a single attachment. - The world travels as settings, not terrain — only `level.dat`, so Minecraft regenerates from your seed. A few kilobytes, and nothing you have built is in it. - Mods that aren't on Modrinth (CurseForge-only, private, self-edited) are listed in the pack's `codxlib-debug/README.txt` to add by hand, never dropped silently. No jars are copied in. - **`/codxlib pack`** writes just the modpack. Same permissions as `/codxlib help`. **Developers:** new `CodxInstancePack.writeAsync(server)` and `CodxLib.gameDir()` / `IPlatformHelper#getGameDir()` — **a mod shipping its own `IPlatformHelper` must implement it.** Nothing else from 1.4.x changed; raise your range to `[1.5.0,)` only if you use the new API.

# CodxLib 1.5.0 *This file is for **NeoForge 26.1.1**. Every loader ships the same CodxLib version, so the notes below apply here too.* **`/codxlib help` now also writes a `.mrpack`.** Drop that one file into the Modrinth App (**Add instance → From file**) and it rebuilds the instance the report came from: same Minecraft version, same loader, every mod it can find on Modrinth, the codx mods' settings, and a world on **the same seed**. "It crashes on my world" becomes a single attachment. - The world travels as settings, not terrain — only `level.dat`, so Minecraft regenerates from your seed. A few kilobytes, and nothing you have built is in it. - Mods that aren't on Modrinth (CurseForge-only, private, self-edited) are listed in the pack's `codxlib-debug/README.txt` to add by hand, never dropped silently. No jars are copied in. - **`/codxlib pack`** writes just the modpack. Same permissions as `/codxlib help`. **Developers:** new `CodxInstancePack.writeAsync(server)` and `CodxLib.gameDir()` / `IPlatformHelper#getGameDir()` — **a mod shipping its own `IPlatformHelper` must implement it.** Nothing else from 1.4.x changed; raise your range to `[1.5.0,)` only if you use the new API.

# CodxLib 1.5.0 *This file is for **Forge 26.1.1**. Every loader ships the same CodxLib version, so the notes below apply here too.* **`/codxlib help` now also writes a `.mrpack`.** Drop that one file into the Modrinth App (**Add instance → From file**) and it rebuilds the instance the report came from: same Minecraft version, same loader, every mod it can find on Modrinth, the codx mods' settings, and a world on **the same seed**. "It crashes on my world" becomes a single attachment. - The world travels as settings, not terrain — only `level.dat`, so Minecraft regenerates from your seed. A few kilobytes, and nothing you have built is in it. - Mods that aren't on Modrinth (CurseForge-only, private, self-edited) are listed in the pack's `codxlib-debug/README.txt` to add by hand, never dropped silently. No jars are copied in. - **`/codxlib pack`** writes just the modpack. Same permissions as `/codxlib help`. **Developers:** new `CodxInstancePack.writeAsync(server)` and `CodxLib.gameDir()` / `IPlatformHelper#getGameDir()` — **a mod shipping its own `IPlatformHelper` must implement it.** Nothing else from 1.4.x changed; raise your range to `[1.5.0,)` only if you use the new API.

# CodxLib 1.5.0 *This file is for **Fabric 26.1.1**. It requires **Fabric Loader 0.18.4 or newer** — exactly what Fabric API already needs on 26.1.1, so CodxLib adds no restriction of its own.* **`/codxlib help` now also writes a `.mrpack`.** Drop that one file into the Modrinth App (**Add instance → From file**) and it rebuilds the instance the report came from: same Minecraft version, same loader, every mod it can find on Modrinth, the codx mods' settings, and a world on **the same seed**. "It crashes on my world" becomes a single attachment. - The world travels as settings, not terrain — only `level.dat`, so Minecraft regenerates from your seed. A few kilobytes, and nothing you have built is in it. - Mods that aren't on Modrinth (CurseForge-only, private, self-edited) are listed in the pack's `codxlib-debug/README.txt` to add by hand, never dropped silently. No jars are copied in. - **`/codxlib pack`** writes just the modpack. Same permissions as `/codxlib help`. **Developers:** new `CodxInstancePack.writeAsync(server)` and `CodxLib.gameDir()` / `IPlatformHelper#getGameDir()` — **a mod shipping its own `IPlatformHelper` must implement it.** Nothing else from 1.4.x changed; raise your range to `[1.5.0,)` only if you use the new API.

# CodxLib 1.5.0 *This file is for **NeoForge 26.1**. Every loader ships the same CodxLib version, so the notes below apply here too.* **`/codxlib help` now also writes a `.mrpack`.** Drop that one file into the Modrinth App (**Add instance → From file**) and it rebuilds the instance the report came from: same Minecraft version, same loader, every mod it can find on Modrinth, the codx mods' settings, and a world on **the same seed**. "It crashes on my world" becomes a single attachment. - The world travels as settings, not terrain — only `level.dat`, so Minecraft regenerates from your seed. A few kilobytes, and nothing you have built is in it. - Mods that aren't on Modrinth (CurseForge-only, private, self-edited) are listed in the pack's `codxlib-debug/README.txt` to add by hand, never dropped silently. No jars are copied in. - **`/codxlib pack`** writes just the modpack. Same permissions as `/codxlib help`. **Developers:** new `CodxInstancePack.writeAsync(server)` and `CodxLib.gameDir()` / `IPlatformHelper#getGameDir()` — **a mod shipping its own `IPlatformHelper` must implement it.** Nothing else from 1.4.x changed; raise your range to `[1.5.0,)` only if you use the new API.

# CodxLib 1.5.0 *This file is for **Forge 26.1**. Every loader ships the same CodxLib version, so the notes below apply here too.* **`/codxlib help` now also writes a `.mrpack`.** Drop that one file into the Modrinth App (**Add instance → From file**) and it rebuilds the instance the report came from: same Minecraft version, same loader, every mod it can find on Modrinth, the codx mods' settings, and a world on **the same seed**. "It crashes on my world" becomes a single attachment. - The world travels as settings, not terrain — only `level.dat`, so Minecraft regenerates from your seed. A few kilobytes, and nothing you have built is in it. - Mods that aren't on Modrinth (CurseForge-only, private, self-edited) are listed in the pack's `codxlib-debug/README.txt` to add by hand, never dropped silently. No jars are copied in. - **`/codxlib pack`** writes just the modpack. Same permissions as `/codxlib help`. **Developers:** new `CodxInstancePack.writeAsync(server)` and `CodxLib.gameDir()` / `IPlatformHelper#getGameDir()` — **a mod shipping its own `IPlatformHelper` must implement it.** Nothing else from 1.4.x changed; raise your range to `[1.5.0,)` only if you use the new API.

# CodxLib 1.5.0 *This file is for **Fabric 26.1**. It requires **Fabric Loader 0.18.4 or newer** — exactly what Fabric API already needs on 26.1, so CodxLib adds no restriction of its own.* **`/codxlib help` now also writes a `.mrpack`.** Drop that one file into the Modrinth App (**Add instance → From file**) and it rebuilds the instance the report came from: same Minecraft version, same loader, every mod it can find on Modrinth, the codx mods' settings, and a world on **the same seed**. "It crashes on my world" becomes a single attachment. - The world travels as settings, not terrain — only `level.dat`, so Minecraft regenerates from your seed. A few kilobytes, and nothing you have built is in it. - Mods that aren't on Modrinth (CurseForge-only, private, self-edited) are listed in the pack's `codxlib-debug/README.txt` to add by hand, never dropped silently. No jars are copied in. - **`/codxlib pack`** writes just the modpack. Same permissions as `/codxlib help`. **Developers:** new `CodxInstancePack.writeAsync(server)` and `CodxLib.gameDir()` / `IPlatformHelper#getGameDir()` — **a mod shipping its own `IPlatformHelper` must implement it.** Nothing else from 1.4.x changed; raise your range to `[1.5.0,)` only if you use the new API.

# CodxLib 1.5.0 *This file is for **NeoForge 1.21.11**. Every loader ships the same CodxLib version, so the notes below apply here too.* **`/codxlib help` now also writes a `.mrpack`.** Drop that one file into the Modrinth App (**Add instance → From file**) and it rebuilds the instance the report came from: same Minecraft version, same loader, every mod it can find on Modrinth, the codx mods' settings, and a world on **the same seed**. "It crashes on my world" becomes a single attachment. - The world travels as settings, not terrain — only `level.dat`, so Minecraft regenerates from your seed. A few kilobytes, and nothing you have built is in it. - Mods that aren't on Modrinth (CurseForge-only, private, self-edited) are listed in the pack's `codxlib-debug/README.txt` to add by hand, never dropped silently. No jars are copied in. - **`/codxlib pack`** writes just the modpack. Same permissions as `/codxlib help`. **Developers:** new `CodxInstancePack.writeAsync(server)` and `CodxLib.gameDir()` / `IPlatformHelper#getGameDir()` — **a mod shipping its own `IPlatformHelper` must implement it.** Nothing else from 1.4.x changed; raise your range to `[1.5.0,)` only if you use the new API.

# CodxLib 1.5.0 *This file is for **Forge 1.21.11**. Every loader ships the same CodxLib version, so the notes below apply here too.* **`/codxlib help` now also writes a `.mrpack`.** Drop that one file into the Modrinth App (**Add instance → From file**) and it rebuilds the instance the report came from: same Minecraft version, same loader, every mod it can find on Modrinth, the codx mods' settings, and a world on **the same seed**. "It crashes on my world" becomes a single attachment. - The world travels as settings, not terrain — only `level.dat`, so Minecraft regenerates from your seed. A few kilobytes, and nothing you have built is in it. - Mods that aren't on Modrinth (CurseForge-only, private, self-edited) are listed in the pack's `codxlib-debug/README.txt` to add by hand, never dropped silently. No jars are copied in. - **`/codxlib pack`** writes just the modpack. Same permissions as `/codxlib help`. **Developers:** new `CodxInstancePack.writeAsync(server)` and `CodxLib.gameDir()` / `IPlatformHelper#getGameDir()` — **a mod shipping its own `IPlatformHelper` must implement it.** Nothing else from 1.4.x changed; raise your range to `[1.5.0,)` only if you use the new API.

# CodxLib 1.5.0 *This file is for **Fabric 1.21.11**. It requires **Fabric Loader 0.17.3 or newer** — exactly what Fabric API already needs on 1.21.11, so CodxLib adds no restriction of its own.* **`/codxlib help` now also writes a `.mrpack`.** Drop that one file into the Modrinth App (**Add instance → From file**) and it rebuilds the instance the report came from: same Minecraft version, same loader, every mod it can find on Modrinth, the codx mods' settings, and a world on **the same seed**. "It crashes on my world" becomes a single attachment. - The world travels as settings, not terrain — only `level.dat`, so Minecraft regenerates from your seed. A few kilobytes, and nothing you have built is in it. - Mods that aren't on Modrinth (CurseForge-only, private, self-edited) are listed in the pack's `codxlib-debug/README.txt` to add by hand, never dropped silently. No jars are copied in. - **`/codxlib pack`** writes just the modpack. Same permissions as `/codxlib help`. **Developers:** new `CodxInstancePack.writeAsync(server)` and `CodxLib.gameDir()` / `IPlatformHelper#getGameDir()` — **a mod shipping its own `IPlatformHelper` must implement it.** Nothing else from 1.4.x changed; raise your range to `[1.5.0,)` only if you use the new API.

# CodxLib 1.5.0 *This file is for **NeoForge 1.21.10**. Every loader ships the same CodxLib version, so the notes below apply here too.* **`/codxlib help` now also writes a `.mrpack`.** Drop that one file into the Modrinth App (**Add instance → From file**) and it rebuilds the instance the report came from: same Minecraft version, same loader, every mod it can find on Modrinth, the codx mods' settings, and a world on **the same seed**. "It crashes on my world" becomes a single attachment. - The world travels as settings, not terrain — only `level.dat`, so Minecraft regenerates from your seed. A few kilobytes, and nothing you have built is in it. - Mods that aren't on Modrinth (CurseForge-only, private, self-edited) are listed in the pack's `codxlib-debug/README.txt` to add by hand, never dropped silently. No jars are copied in. - **`/codxlib pack`** writes just the modpack. Same permissions as `/codxlib help`. **Developers:** new `CodxInstancePack.writeAsync(server)` and `CodxLib.gameDir()` / `IPlatformHelper#getGameDir()` — **a mod shipping its own `IPlatformHelper` must implement it.** Nothing else from 1.4.x changed; raise your range to `[1.5.0,)` only if you use the new API.

# CodxLib 1.5.0 *This file is for **Forge 1.21.10**. Every loader ships the same CodxLib version, so the notes below apply here too.* **`/codxlib help` now also writes a `.mrpack`.** Drop that one file into the Modrinth App (**Add instance → From file**) and it rebuilds the instance the report came from: same Minecraft version, same loader, every mod it can find on Modrinth, the codx mods' settings, and a world on **the same seed**. "It crashes on my world" becomes a single attachment. - The world travels as settings, not terrain — only `level.dat`, so Minecraft regenerates from your seed. A few kilobytes, and nothing you have built is in it. - Mods that aren't on Modrinth (CurseForge-only, private, self-edited) are listed in the pack's `codxlib-debug/README.txt` to add by hand, never dropped silently. No jars are copied in. - **`/codxlib pack`** writes just the modpack. Same permissions as `/codxlib help`. **Developers:** new `CodxInstancePack.writeAsync(server)` and `CodxLib.gameDir()` / `IPlatformHelper#getGameDir()` — **a mod shipping its own `IPlatformHelper` must implement it.** Nothing else from 1.4.x changed; raise your range to `[1.5.0,)` only if you use the new API.

# CodxLib 1.5.0 *This file is for **Fabric 1.21.10**. It requires **Fabric Loader 0.17.0 or newer** — exactly what Fabric API already needs on 1.21.10, so CodxLib adds no restriction of its own.* **`/codxlib help` now also writes a `.mrpack`.** Drop that one file into the Modrinth App (**Add instance → From file**) and it rebuilds the instance the report came from: same Minecraft version, same loader, every mod it can find on Modrinth, the codx mods' settings, and a world on **the same seed**. "It crashes on my world" becomes a single attachment. - The world travels as settings, not terrain — only `level.dat`, so Minecraft regenerates from your seed. A few kilobytes, and nothing you have built is in it. - Mods that aren't on Modrinth (CurseForge-only, private, self-edited) are listed in the pack's `codxlib-debug/README.txt` to add by hand, never dropped silently. No jars are copied in. - **`/codxlib pack`** writes just the modpack. Same permissions as `/codxlib help`. **Developers:** new `CodxInstancePack.writeAsync(server)` and `CodxLib.gameDir()` / `IPlatformHelper#getGameDir()` — **a mod shipping its own `IPlatformHelper` must implement it.** Nothing else from 1.4.x changed; raise your range to `[1.5.0,)` only if you use the new API.

# CodxLib 1.5.0 *This file is for **NeoForge 1.21.9**. Every loader ships the same CodxLib version, so the notes below apply here too.* **`/codxlib help` now also writes a `.mrpack`.** Drop that one file into the Modrinth App (**Add instance → From file**) and it rebuilds the instance the report came from: same Minecraft version, same loader, every mod it can find on Modrinth, the codx mods' settings, and a world on **the same seed**. "It crashes on my world" becomes a single attachment. - The world travels as settings, not terrain — only `level.dat`, so Minecraft regenerates from your seed. A few kilobytes, and nothing you have built is in it. - Mods that aren't on Modrinth (CurseForge-only, private, self-edited) are listed in the pack's `codxlib-debug/README.txt` to add by hand, never dropped silently. No jars are copied in. - **`/codxlib pack`** writes just the modpack. Same permissions as `/codxlib help`. **Developers:** new `CodxInstancePack.writeAsync(server)` and `CodxLib.gameDir()` / `IPlatformHelper#getGameDir()` — **a mod shipping its own `IPlatformHelper` must implement it.** Nothing else from 1.4.x changed; raise your range to `[1.5.0,)` only if you use the new API.

# CodxLib 1.5.0 *This file is for **Forge 1.21.9**. Every loader ships the same CodxLib version, so the notes below apply here too.* **`/codxlib help` now also writes a `.mrpack`.** Drop that one file into the Modrinth App (**Add instance → From file**) and it rebuilds the instance the report came from: same Minecraft version, same loader, every mod it can find on Modrinth, the codx mods' settings, and a world on **the same seed**. "It crashes on my world" becomes a single attachment. - The world travels as settings, not terrain — only `level.dat`, so Minecraft regenerates from your seed. A few kilobytes, and nothing you have built is in it. - Mods that aren't on Modrinth (CurseForge-only, private, self-edited) are listed in the pack's `codxlib-debug/README.txt` to add by hand, never dropped silently. No jars are copied in. - **`/codxlib pack`** writes just the modpack. Same permissions as `/codxlib help`. **Developers:** new `CodxInstancePack.writeAsync(server)` and `CodxLib.gameDir()` / `IPlatformHelper#getGameDir()` — **a mod shipping its own `IPlatformHelper` must implement it.** Nothing else from 1.4.x changed; raise your range to `[1.5.0,)` only if you use the new API.

# CodxLib 1.5.0 *This file is for **Fabric 1.21.9**. It requires **Fabric Loader 0.17.0 or newer** — exactly what Fabric API already needs on 1.21.9, so CodxLib adds no restriction of its own.* **`/codxlib help` now also writes a `.mrpack`.** Drop that one file into the Modrinth App (**Add instance → From file**) and it rebuilds the instance the report came from: same Minecraft version, same loader, every mod it can find on Modrinth, the codx mods' settings, and a world on **the same seed**. "It crashes on my world" becomes a single attachment. - The world travels as settings, not terrain — only `level.dat`, so Minecraft regenerates from your seed. A few kilobytes, and nothing you have built is in it. - Mods that aren't on Modrinth (CurseForge-only, private, self-edited) are listed in the pack's `codxlib-debug/README.txt` to add by hand, never dropped silently. No jars are copied in. - **`/codxlib pack`** writes just the modpack. Same permissions as `/codxlib help`. **Developers:** new `CodxInstancePack.writeAsync(server)` and `CodxLib.gameDir()` / `IPlatformHelper#getGameDir()` — **a mod shipping its own `IPlatformHelper` must implement it.** Nothing else from 1.4.x changed; raise your range to `[1.5.0,)` only if you use the new API.

# CodxLib 1.5.0 *This file is for **NeoForge 1.21.8**. Every loader ships the same CodxLib version, so the notes below apply here too.* **`/codxlib help` now also writes a `.mrpack`.** Drop that one file into the Modrinth App (**Add instance → From file**) and it rebuilds the instance the report came from: same Minecraft version, same loader, every mod it can find on Modrinth, the codx mods' settings, and a world on **the same seed**. "It crashes on my world" becomes a single attachment. - The world travels as settings, not terrain — only `level.dat`, so Minecraft regenerates from your seed. A few kilobytes, and nothing you have built is in it. - Mods that aren't on Modrinth (CurseForge-only, private, self-edited) are listed in the pack's `codxlib-debug/README.txt` to add by hand, never dropped silently. No jars are copied in. - **`/codxlib pack`** writes just the modpack. Same permissions as `/codxlib help`. **Developers:** new `CodxInstancePack.writeAsync(server)` and `CodxLib.gameDir()` / `IPlatformHelper#getGameDir()` — **a mod shipping its own `IPlatformHelper` must implement it.** Nothing else from 1.4.x changed; raise your range to `[1.5.0,)` only if you use the new API.

# CodxLib 1.5.0 *This file is for **Forge 1.21.8**. Every loader ships the same CodxLib version, so the notes below apply here too.* **`/codxlib help` now also writes a `.mrpack`.** Drop that one file into the Modrinth App (**Add instance → From file**) and it rebuilds the instance the report came from: same Minecraft version, same loader, every mod it can find on Modrinth, the codx mods' settings, and a world on **the same seed**. "It crashes on my world" becomes a single attachment. - The world travels as settings, not terrain — only `level.dat`, so Minecraft regenerates from your seed. A few kilobytes, and nothing you have built is in it. - Mods that aren't on Modrinth (CurseForge-only, private, self-edited) are listed in the pack's `codxlib-debug/README.txt` to add by hand, never dropped silently. No jars are copied in. - **`/codxlib pack`** writes just the modpack. Same permissions as `/codxlib help`. **Developers:** new `CodxInstancePack.writeAsync(server)` and `CodxLib.gameDir()` / `IPlatformHelper#getGameDir()` — **a mod shipping its own `IPlatformHelper` must implement it.** Nothing else from 1.4.x changed; raise your range to `[1.5.0,)` only if you use the new API.

# CodxLib 1.5.0 *This file is for **Fabric 1.21.8**. It requires **Fabric Loader 0.16.13 or newer** — exactly what Fabric API already needs on 1.21.8, so CodxLib adds no restriction of its own.* **`/codxlib help` now also writes a `.mrpack`.** Drop that one file into the Modrinth App (**Add instance → From file**) and it rebuilds the instance the report came from: same Minecraft version, same loader, every mod it can find on Modrinth, the codx mods' settings, and a world on **the same seed**. "It crashes on my world" becomes a single attachment. - The world travels as settings, not terrain — only `level.dat`, so Minecraft regenerates from your seed. A few kilobytes, and nothing you have built is in it. - Mods that aren't on Modrinth (CurseForge-only, private, self-edited) are listed in the pack's `codxlib-debug/README.txt` to add by hand, never dropped silently. No jars are copied in. - **`/codxlib pack`** writes just the modpack. Same permissions as `/codxlib help`. **Developers:** new `CodxInstancePack.writeAsync(server)` and `CodxLib.gameDir()` / `IPlatformHelper#getGameDir()` — **a mod shipping its own `IPlatformHelper` must implement it.** Nothing else from 1.4.x changed; raise your range to `[1.5.0,)` only if you use the new API.

# CodxLib 1.5.0 *This file is for **NeoForge 1.21.7**. Every loader ships the same CodxLib version, so the notes below apply here too.* **`/codxlib help` now also writes a `.mrpack`.** Drop that one file into the Modrinth App (**Add instance → From file**) and it rebuilds the instance the report came from: same Minecraft version, same loader, every mod it can find on Modrinth, the codx mods' settings, and a world on **the same seed**. "It crashes on my world" becomes a single attachment. - The world travels as settings, not terrain — only `level.dat`, so Minecraft regenerates from your seed. A few kilobytes, and nothing you have built is in it. - Mods that aren't on Modrinth (CurseForge-only, private, self-edited) are listed in the pack's `codxlib-debug/README.txt` to add by hand, never dropped silently. No jars are copied in. - **`/codxlib pack`** writes just the modpack. Same permissions as `/codxlib help`. **Developers:** new `CodxInstancePack.writeAsync(server)` and `CodxLib.gameDir()` / `IPlatformHelper#getGameDir()` — **a mod shipping its own `IPlatformHelper` must implement it.** Nothing else from 1.4.x changed; raise your range to `[1.5.0,)` only if you use the new API.

# CodxLib 1.5.0 *This file is for **Forge 1.21.7**. Every loader ships the same CodxLib version, so the notes below apply here too.* **`/codxlib help` now also writes a `.mrpack`.** Drop that one file into the Modrinth App (**Add instance → From file**) and it rebuilds the instance the report came from: same Minecraft version, same loader, every mod it can find on Modrinth, the codx mods' settings, and a world on **the same seed**. "It crashes on my world" becomes a single attachment. - The world travels as settings, not terrain — only `level.dat`, so Minecraft regenerates from your seed. A few kilobytes, and nothing you have built is in it. - Mods that aren't on Modrinth (CurseForge-only, private, self-edited) are listed in the pack's `codxlib-debug/README.txt` to add by hand, never dropped silently. No jars are copied in. - **`/codxlib pack`** writes just the modpack. Same permissions as `/codxlib help`. **Developers:** new `CodxInstancePack.writeAsync(server)` and `CodxLib.gameDir()` / `IPlatformHelper#getGameDir()` — **a mod shipping its own `IPlatformHelper` must implement it.** Nothing else from 1.4.x changed; raise your range to `[1.5.0,)` only if you use the new API.

# CodxLib 1.5.0 *This file is for **Fabric 1.21.7**. It requires **Fabric Loader 0.16.13 or newer** — exactly what Fabric API already needs on 1.21.7, so CodxLib adds no restriction of its own.* **`/codxlib help` now also writes a `.mrpack`.** Drop that one file into the Modrinth App (**Add instance → From file**) and it rebuilds the instance the report came from: same Minecraft version, same loader, every mod it can find on Modrinth, the codx mods' settings, and a world on **the same seed**. "It crashes on my world" becomes a single attachment. - The world travels as settings, not terrain — only `level.dat`, so Minecraft regenerates from your seed. A few kilobytes, and nothing you have built is in it. - Mods that aren't on Modrinth (CurseForge-only, private, self-edited) are listed in the pack's `codxlib-debug/README.txt` to add by hand, never dropped silently. No jars are copied in. - **`/codxlib pack`** writes just the modpack. Same permissions as `/codxlib help`. **Developers:** new `CodxInstancePack.writeAsync(server)` and `CodxLib.gameDir()` / `IPlatformHelper#getGameDir()` — **a mod shipping its own `IPlatformHelper` must implement it.** Nothing else from 1.4.x changed; raise your range to `[1.5.0,)` only if you use the new API.

# CodxLib 1.5.0 *This file is for **NeoForge 1.21.6**. Every loader ships the same CodxLib version, so the notes below apply here too.* **`/codxlib help` now also writes a `.mrpack`.** Drop that one file into the Modrinth App (**Add instance → From file**) and it rebuilds the instance the report came from: same Minecraft version, same loader, every mod it can find on Modrinth, the codx mods' settings, and a world on **the same seed**. "It crashes on my world" becomes a single attachment. - The world travels as settings, not terrain — only `level.dat`, so Minecraft regenerates from your seed. A few kilobytes, and nothing you have built is in it. - Mods that aren't on Modrinth (CurseForge-only, private, self-edited) are listed in the pack's `codxlib-debug/README.txt` to add by hand, never dropped silently. No jars are copied in. - **`/codxlib pack`** writes just the modpack. Same permissions as `/codxlib help`. **Developers:** new `CodxInstancePack.writeAsync(server)` and `CodxLib.gameDir()` / `IPlatformHelper#getGameDir()` — **a mod shipping its own `IPlatformHelper` must implement it.** Nothing else from 1.4.x changed; raise your range to `[1.5.0,)` only if you use the new API.

# CodxLib 1.5.0 *This file is for **Forge 1.21.6**. Every loader ships the same CodxLib version, so the notes below apply here too.* **`/codxlib help` now also writes a `.mrpack`.** Drop that one file into the Modrinth App (**Add instance → From file**) and it rebuilds the instance the report came from: same Minecraft version, same loader, every mod it can find on Modrinth, the codx mods' settings, and a world on **the same seed**. "It crashes on my world" becomes a single attachment. - The world travels as settings, not terrain — only `level.dat`, so Minecraft regenerates from your seed. A few kilobytes, and nothing you have built is in it. - Mods that aren't on Modrinth (CurseForge-only, private, self-edited) are listed in the pack's `codxlib-debug/README.txt` to add by hand, never dropped silently. No jars are copied in. - **`/codxlib pack`** writes just the modpack. Same permissions as `/codxlib help`. **Developers:** new `CodxInstancePack.writeAsync(server)` and `CodxLib.gameDir()` / `IPlatformHelper#getGameDir()` — **a mod shipping its own `IPlatformHelper` must implement it.** Nothing else from 1.4.x changed; raise your range to `[1.5.0,)` only if you use the new API.

# CodxLib 1.5.0 *This file is for **Fabric 1.21.6**. It requires **Fabric Loader 0.16.13 or newer** — exactly what Fabric API already needs on 1.21.6, so CodxLib adds no restriction of its own.* **`/codxlib help` now also writes a `.mrpack`.** Drop that one file into the Modrinth App (**Add instance → From file**) and it rebuilds the instance the report came from: same Minecraft version, same loader, every mod it can find on Modrinth, the codx mods' settings, and a world on **the same seed**. "It crashes on my world" becomes a single attachment. - The world travels as settings, not terrain — only `level.dat`, so Minecraft regenerates from your seed. A few kilobytes, and nothing you have built is in it. - Mods that aren't on Modrinth (CurseForge-only, private, self-edited) are listed in the pack's `codxlib-debug/README.txt` to add by hand, never dropped silently. No jars are copied in. - **`/codxlib pack`** writes just the modpack. Same permissions as `/codxlib help`. **Developers:** new `CodxInstancePack.writeAsync(server)` and `CodxLib.gameDir()` / `IPlatformHelper#getGameDir()` — **a mod shipping its own `IPlatformHelper` must implement it.** Nothing else from 1.4.x changed; raise your range to `[1.5.0,)` only if you use the new API.

# CodxLib 1.5.0 *This file is for **NeoForge 1.21.5**. Every loader ships the same CodxLib version, so the notes below apply here too.* **`/codxlib help` now also writes a `.mrpack`.** Drop that one file into the Modrinth App (**Add instance → From file**) and it rebuilds the instance the report came from: same Minecraft version, same loader, every mod it can find on Modrinth, the codx mods' settings, and a world on **the same seed**. "It crashes on my world" becomes a single attachment. - The world travels as settings, not terrain — only `level.dat`, so Minecraft regenerates from your seed. A few kilobytes, and nothing you have built is in it. - Mods that aren't on Modrinth (CurseForge-only, private, self-edited) are listed in the pack's `codxlib-debug/README.txt` to add by hand, never dropped silently. No jars are copied in. - **`/codxlib pack`** writes just the modpack. Same permissions as `/codxlib help`. **Developers:** new `CodxInstancePack.writeAsync(server)` and `CodxLib.gameDir()` / `IPlatformHelper#getGameDir()` — **a mod shipping its own `IPlatformHelper` must implement it.** Nothing else from 1.4.x changed; raise your range to `[1.5.0,)` only if you use the new API.

# CodxLib 1.5.0 *This file is for **Forge 1.21.5**. Every loader ships the same CodxLib version, so the notes below apply here too.* **`/codxlib help` now also writes a `.mrpack`.** Drop that one file into the Modrinth App (**Add instance → From file**) and it rebuilds the instance the report came from: same Minecraft version, same loader, every mod it can find on Modrinth, the codx mods' settings, and a world on **the same seed**. "It crashes on my world" becomes a single attachment. - The world travels as settings, not terrain — only `level.dat`, so Minecraft regenerates from your seed. A few kilobytes, and nothing you have built is in it. - Mods that aren't on Modrinth (CurseForge-only, private, self-edited) are listed in the pack's `codxlib-debug/README.txt` to add by hand, never dropped silently. No jars are copied in. - **`/codxlib pack`** writes just the modpack. Same permissions as `/codxlib help`. **Developers:** new `CodxInstancePack.writeAsync(server)` and `CodxLib.gameDir()` / `IPlatformHelper#getGameDir()` — **a mod shipping its own `IPlatformHelper` must implement it.** Nothing else from 1.4.x changed; raise your range to `[1.5.0,)` only if you use the new API.

# CodxLib 1.5.0 *This file is for **Fabric 1.21.5**. It requires **Fabric Loader 0.16.10 or newer** — exactly what Fabric API already needs on 1.21.5, so CodxLib adds no restriction of its own.* **`/codxlib help` now also writes a `.mrpack`.** Drop that one file into the Modrinth App (**Add instance → From file**) and it rebuilds the instance the report came from: same Minecraft version, same loader, every mod it can find on Modrinth, the codx mods' settings, and a world on **the same seed**. "It crashes on my world" becomes a single attachment. - The world travels as settings, not terrain — only `level.dat`, so Minecraft regenerates from your seed. A few kilobytes, and nothing you have built is in it. - Mods that aren't on Modrinth (CurseForge-only, private, self-edited) are listed in the pack's `codxlib-debug/README.txt` to add by hand, never dropped silently. No jars are copied in. - **`/codxlib pack`** writes just the modpack. Same permissions as `/codxlib help`. **Developers:** new `CodxInstancePack.writeAsync(server)` and `CodxLib.gameDir()` / `IPlatformHelper#getGameDir()` — **a mod shipping its own `IPlatformHelper` must implement it.** Nothing else from 1.4.x changed; raise your range to `[1.5.0,)` only if you use the new API.

# CodxLib 1.5.0 *This file is for **NeoForge 1.21.4**. Every loader ships the same CodxLib version, so the notes below apply here too.* **`/codxlib help` now also writes a `.mrpack`.** Drop that one file into the Modrinth App (**Add instance → From file**) and it rebuilds the instance the report came from: same Minecraft version, same loader, every mod it can find on Modrinth, the codx mods' settings, and a world on **the same seed**. "It crashes on my world" becomes a single attachment. - The world travels as settings, not terrain — only `level.dat`, so Minecraft regenerates from your seed. A few kilobytes, and nothing you have built is in it. - Mods that aren't on Modrinth (CurseForge-only, private, self-edited) are listed in the pack's `codxlib-debug/README.txt` to add by hand, never dropped silently. No jars are copied in. - **`/codxlib pack`** writes just the modpack. Same permissions as `/codxlib help`. **Developers:** new `CodxInstancePack.writeAsync(server)` and `CodxLib.gameDir()` / `IPlatformHelper#getGameDir()` — **a mod shipping its own `IPlatformHelper` must implement it.** Nothing else from 1.4.x changed; raise your range to `[1.5.0,)` only if you use the new API.

# CodxLib 1.5.0 *This file is for **Forge 1.21.4**. Every loader ships the same CodxLib version, so the notes below apply here too.* **`/codxlib help` now also writes a `.mrpack`.** Drop that one file into the Modrinth App (**Add instance → From file**) and it rebuilds the instance the report came from: same Minecraft version, same loader, every mod it can find on Modrinth, the codx mods' settings, and a world on **the same seed**. "It crashes on my world" becomes a single attachment. - The world travels as settings, not terrain — only `level.dat`, so Minecraft regenerates from your seed. A few kilobytes, and nothing you have built is in it. - Mods that aren't on Modrinth (CurseForge-only, private, self-edited) are listed in the pack's `codxlib-debug/README.txt` to add by hand, never dropped silently. No jars are copied in. - **`/codxlib pack`** writes just the modpack. Same permissions as `/codxlib help`. **Developers:** new `CodxInstancePack.writeAsync(server)` and `CodxLib.gameDir()` / `IPlatformHelper#getGameDir()` — **a mod shipping its own `IPlatformHelper` must implement it.** Nothing else from 1.4.x changed; raise your range to `[1.5.0,)` only if you use the new API.

# CodxLib 1.5.0 *This file is for **Fabric 1.21.4**. It requires **Fabric Loader 0.16.9 or newer** — exactly what Fabric API already needs on 1.21.4, so CodxLib adds no restriction of its own.* **`/codxlib help` now also writes a `.mrpack`.** Drop that one file into the Modrinth App (**Add instance → From file**) and it rebuilds the instance the report came from: same Minecraft version, same loader, every mod it can find on Modrinth, the codx mods' settings, and a world on **the same seed**. "It crashes on my world" becomes a single attachment. - The world travels as settings, not terrain — only `level.dat`, so Minecraft regenerates from your seed. A few kilobytes, and nothing you have built is in it. - Mods that aren't on Modrinth (CurseForge-only, private, self-edited) are listed in the pack's `codxlib-debug/README.txt` to add by hand, never dropped silently. No jars are copied in. - **`/codxlib pack`** writes just the modpack. Same permissions as `/codxlib help`. **Developers:** new `CodxInstancePack.writeAsync(server)` and `CodxLib.gameDir()` / `IPlatformHelper#getGameDir()` — **a mod shipping its own `IPlatformHelper` must implement it.** Nothing else from 1.4.x changed; raise your range to `[1.5.0,)` only if you use the new API.

# CodxLib 1.5.0 *This file is for **NeoForge 1.21.3**. Every loader ships the same CodxLib version, so the notes below apply here too.* **`/codxlib help` now also writes a `.mrpack`.** Drop that one file into the Modrinth App (**Add instance → From file**) and it rebuilds the instance the report came from: same Minecraft version, same loader, every mod it can find on Modrinth, the codx mods' settings, and a world on **the same seed**. "It crashes on my world" becomes a single attachment. - The world travels as settings, not terrain — only `level.dat`, so Minecraft regenerates from your seed. A few kilobytes, and nothing you have built is in it. - Mods that aren't on Modrinth (CurseForge-only, private, self-edited) are listed in the pack's `codxlib-debug/README.txt` to add by hand, never dropped silently. No jars are copied in. - **`/codxlib pack`** writes just the modpack. Same permissions as `/codxlib help`. **Developers:** new `CodxInstancePack.writeAsync(server)` and `CodxLib.gameDir()` / `IPlatformHelper#getGameDir()` — **a mod shipping its own `IPlatformHelper` must implement it.** Nothing else from 1.4.x changed; raise your range to `[1.5.0,)` only if you use the new API.

# CodxLib 1.5.0 *This file is for **Forge 1.21.3**. Every loader ships the same CodxLib version, so the notes below apply here too.* **`/codxlib help` now also writes a `.mrpack`.** Drop that one file into the Modrinth App (**Add instance → From file**) and it rebuilds the instance the report came from: same Minecraft version, same loader, every mod it can find on Modrinth, the codx mods' settings, and a world on **the same seed**. "It crashes on my world" becomes a single attachment. - The world travels as settings, not terrain — only `level.dat`, so Minecraft regenerates from your seed. A few kilobytes, and nothing you have built is in it. - Mods that aren't on Modrinth (CurseForge-only, private, self-edited) are listed in the pack's `codxlib-debug/README.txt` to add by hand, never dropped silently. No jars are copied in. - **`/codxlib pack`** writes just the modpack. Same permissions as `/codxlib help`. **Developers:** new `CodxInstancePack.writeAsync(server)` and `CodxLib.gameDir()` / `IPlatformHelper#getGameDir()` — **a mod shipping its own `IPlatformHelper` must implement it.** Nothing else from 1.4.x changed; raise your range to `[1.5.0,)` only if you use the new API.

# CodxLib 1.5.0 *This file is for **Fabric 1.21.3**. It requires **Fabric Loader 0.16.8 or newer** — exactly what Fabric API already needs on 1.21.3, so CodxLib adds no restriction of its own.* **`/codxlib help` now also writes a `.mrpack`.** Drop that one file into the Modrinth App (**Add instance → From file**) and it rebuilds the instance the report came from: same Minecraft version, same loader, every mod it can find on Modrinth, the codx mods' settings, and a world on **the same seed**. "It crashes on my world" becomes a single attachment. - The world travels as settings, not terrain — only `level.dat`, so Minecraft regenerates from your seed. A few kilobytes, and nothing you have built is in it. - Mods that aren't on Modrinth (CurseForge-only, private, self-edited) are listed in the pack's `codxlib-debug/README.txt` to add by hand, never dropped silently. No jars are copied in. - **`/codxlib pack`** writes just the modpack. Same permissions as `/codxlib help`. **Developers:** new `CodxInstancePack.writeAsync(server)` and `CodxLib.gameDir()` / `IPlatformHelper#getGameDir()` — **a mod shipping its own `IPlatformHelper` must implement it.** Nothing else from 1.4.x changed; raise your range to `[1.5.0,)` only if you use the new API.

# CodxLib 1.5.0 *This file is for **NeoForge 1.21.2**. Every loader ships the same CodxLib version, so the notes below apply here too.* **`/codxlib help` now also writes a `.mrpack`.** Drop that one file into the Modrinth App (**Add instance → From file**) and it rebuilds the instance the report came from: same Minecraft version, same loader, every mod it can find on Modrinth, the codx mods' settings, and a world on **the same seed**. "It crashes on my world" becomes a single attachment. - The world travels as settings, not terrain — only `level.dat`, so Minecraft regenerates from your seed. A few kilobytes, and nothing you have built is in it. - Mods that aren't on Modrinth (CurseForge-only, private, self-edited) are listed in the pack's `codxlib-debug/README.txt` to add by hand, never dropped silently. No jars are copied in. - **`/codxlib pack`** writes just the modpack. Same permissions as `/codxlib help`. **Developers:** new `CodxInstancePack.writeAsync(server)` and `CodxLib.gameDir()` / `IPlatformHelper#getGameDir()` — **a mod shipping its own `IPlatformHelper` must implement it.** Nothing else from 1.4.x changed; raise your range to `[1.5.0,)` only if you use the new API.

# CodxLib 1.5.0 *This file is for **Fabric 1.21.2**. It requires **Fabric Loader 0.16.7 or newer** — exactly what Fabric API already needs on 1.21.2, so CodxLib adds no restriction of its own.* **`/codxlib help` now also writes a `.mrpack`.** Drop that one file into the Modrinth App (**Add instance → From file**) and it rebuilds the instance the report came from: same Minecraft version, same loader, every mod it can find on Modrinth, the codx mods' settings, and a world on **the same seed**. "It crashes on my world" becomes a single attachment. - The world travels as settings, not terrain — only `level.dat`, so Minecraft regenerates from your seed. A few kilobytes, and nothing you have built is in it. - Mods that aren't on Modrinth (CurseForge-only, private, self-edited) are listed in the pack's `codxlib-debug/README.txt` to add by hand, never dropped silently. No jars are copied in. - **`/codxlib pack`** writes just the modpack. Same permissions as `/codxlib help`. **Developers:** new `CodxInstancePack.writeAsync(server)` and `CodxLib.gameDir()` / `IPlatformHelper#getGameDir()` — **a mod shipping its own `IPlatformHelper` must implement it.** Nothing else from 1.4.x changed; raise your range to `[1.5.0,)` only if you use the new API.

# CodxLib 1.5.0 *This file is for **NeoForge 1.21.1**. Every loader ships the same CodxLib version, so the notes below apply here too.* **`/codxlib help` now also writes a `.mrpack`.** Drop that one file into the Modrinth App (**Add instance → From file**) and it rebuilds the instance the report came from: same Minecraft version, same loader, every mod it can find on Modrinth, the codx mods' settings, and a world on **the same seed**. "It crashes on my world" becomes a single attachment. - The world travels as settings, not terrain — only `level.dat`, so Minecraft regenerates from your seed. A few kilobytes, and nothing you have built is in it. - Mods that aren't on Modrinth (CurseForge-only, private, self-edited) are listed in the pack's `codxlib-debug/README.txt` to add by hand, never dropped silently. No jars are copied in. - **`/codxlib pack`** writes just the modpack. Same permissions as `/codxlib help`. **Developers:** new `CodxInstancePack.writeAsync(server)` and `CodxLib.gameDir()` / `IPlatformHelper#getGameDir()` — **a mod shipping its own `IPlatformHelper` must implement it.** Nothing else from 1.4.x changed; raise your range to `[1.5.0,)` only if you use the new API.

# CodxLib 1.5.0 *This file is for **Forge 1.21.1**. Every loader ships the same CodxLib version, so the notes below apply here too.* **`/codxlib help` now also writes a `.mrpack`.** Drop that one file into the Modrinth App (**Add instance → From file**) and it rebuilds the instance the report came from: same Minecraft version, same loader, every mod it can find on Modrinth, the codx mods' settings, and a world on **the same seed**. "It crashes on my world" becomes a single attachment. - The world travels as settings, not terrain — only `level.dat`, so Minecraft regenerates from your seed. A few kilobytes, and nothing you have built is in it. - Mods that aren't on Modrinth (CurseForge-only, private, self-edited) are listed in the pack's `codxlib-debug/README.txt` to add by hand, never dropped silently. No jars are copied in. - **`/codxlib pack`** writes just the modpack. Same permissions as `/codxlib help`. **Developers:** new `CodxInstancePack.writeAsync(server)` and `CodxLib.gameDir()` / `IPlatformHelper#getGameDir()` — **a mod shipping its own `IPlatformHelper` must implement it.** Nothing else from 1.4.x changed; raise your range to `[1.5.0,)` only if you use the new API.

# CodxLib 1.5.0 *This file is for **Fabric 1.21.1**. It requires **Fabric Loader 0.15.11 or newer** — exactly what Fabric API already needs on 1.21.1, so CodxLib adds no restriction of its own.* **`/codxlib help` now also writes a `.mrpack`.** Drop that one file into the Modrinth App (**Add instance → From file**) and it rebuilds the instance the report came from: same Minecraft version, same loader, every mod it can find on Modrinth, the codx mods' settings, and a world on **the same seed**. "It crashes on my world" becomes a single attachment. - The world travels as settings, not terrain — only `level.dat`, so Minecraft regenerates from your seed. A few kilobytes, and nothing you have built is in it. - Mods that aren't on Modrinth (CurseForge-only, private, self-edited) are listed in the pack's `codxlib-debug/README.txt` to add by hand, never dropped silently. No jars are copied in. - **`/codxlib pack`** writes just the modpack. Same permissions as `/codxlib help`. **Developers:** new `CodxInstancePack.writeAsync(server)` and `CodxLib.gameDir()` / `IPlatformHelper#getGameDir()` — **a mod shipping its own `IPlatformHelper` must implement it.** Nothing else from 1.4.x changed; raise your range to `[1.5.0,)` only if you use the new API.

# CodxLib 1.5.0 *This file is for **NeoForge 1.21**. Every loader ships the same CodxLib version, so the notes below apply here too.* **`/codxlib help` now also writes a `.mrpack`.** Drop that one file into the Modrinth App (**Add instance → From file**) and it rebuilds the instance the report came from: same Minecraft version, same loader, every mod it can find on Modrinth, the codx mods' settings, and a world on **the same seed**. "It crashes on my world" becomes a single attachment. - The world travels as settings, not terrain — only `level.dat`, so Minecraft regenerates from your seed. A few kilobytes, and nothing you have built is in it. - Mods that aren't on Modrinth (CurseForge-only, private, self-edited) are listed in the pack's `codxlib-debug/README.txt` to add by hand, never dropped silently. No jars are copied in. - **`/codxlib pack`** writes just the modpack. Same permissions as `/codxlib help`. **Developers:** new `CodxInstancePack.writeAsync(server)` and `CodxLib.gameDir()` / `IPlatformHelper#getGameDir()` — **a mod shipping its own `IPlatformHelper` must implement it.** Nothing else from 1.4.x changed; raise your range to `[1.5.0,)` only if you use the new API.

# CodxLib 1.5.0 *This file is for **Forge 1.21**. Every loader ships the same CodxLib version, so the notes below apply here too.* **`/codxlib help` now also writes a `.mrpack`.** Drop that one file into the Modrinth App (**Add instance → From file**) and it rebuilds the instance the report came from: same Minecraft version, same loader, every mod it can find on Modrinth, the codx mods' settings, and a world on **the same seed**. "It crashes on my world" becomes a single attachment. - The world travels as settings, not terrain — only `level.dat`, so Minecraft regenerates from your seed. A few kilobytes, and nothing you have built is in it. - Mods that aren't on Modrinth (CurseForge-only, private, self-edited) are listed in the pack's `codxlib-debug/README.txt` to add by hand, never dropped silently. No jars are copied in. - **`/codxlib pack`** writes just the modpack. Same permissions as `/codxlib help`. **Developers:** new `CodxInstancePack.writeAsync(server)` and `CodxLib.gameDir()` / `IPlatformHelper#getGameDir()` — **a mod shipping its own `IPlatformHelper` must implement it.** Nothing else from 1.4.x changed; raise your range to `[1.5.0,)` only if you use the new API.

# CodxLib 1.5.0 *This file is for **Fabric 1.21**. It requires **Fabric Loader 0.15.11 or newer** — exactly what Fabric API already needs on 1.21, so CodxLib adds no restriction of its own.* **`/codxlib help` now also writes a `.mrpack`.** Drop that one file into the Modrinth App (**Add instance → From file**) and it rebuilds the instance the report came from: same Minecraft version, same loader, every mod it can find on Modrinth, the codx mods' settings, and a world on **the same seed**. "It crashes on my world" becomes a single attachment. - The world travels as settings, not terrain — only `level.dat`, so Minecraft regenerates from your seed. A few kilobytes, and nothing you have built is in it. - Mods that aren't on Modrinth (CurseForge-only, private, self-edited) are listed in the pack's `codxlib-debug/README.txt` to add by hand, never dropped silently. No jars are copied in. - **`/codxlib pack`** writes just the modpack. Same permissions as `/codxlib help`. **Developers:** new `CodxInstancePack.writeAsync(server)` and `CodxLib.gameDir()` / `IPlatformHelper#getGameDir()` — **a mod shipping its own `IPlatformHelper` must implement it.** Nothing else from 1.4.x changed; raise your range to `[1.5.0,)` only if you use the new API.

# CodxLib 1.5.0 *This file is for **NeoForge 1.20.6**. Every loader ships the same CodxLib version, so the notes below apply here too.* **`/codxlib help` now also writes a `.mrpack`.** Drop that one file into the Modrinth App (**Add instance → From file**) and it rebuilds the instance the report came from: same Minecraft version, same loader, every mod it can find on Modrinth, the codx mods' settings, and a world on **the same seed**. "It crashes on my world" becomes a single attachment. - The world travels as settings, not terrain — only `level.dat`, so Minecraft regenerates from your seed. A few kilobytes, and nothing you have built is in it. - Mods that aren't on Modrinth (CurseForge-only, private, self-edited) are listed in the pack's `codxlib-debug/README.txt` to add by hand, never dropped silently. No jars are copied in. - **`/codxlib pack`** writes just the modpack. Same permissions as `/codxlib help`. **Developers:** new `CodxInstancePack.writeAsync(server)` and `CodxLib.gameDir()` / `IPlatformHelper#getGameDir()` — **a mod shipping its own `IPlatformHelper` must implement it.** Nothing else from 1.4.x changed; raise your range to `[1.5.0,)` only if you use the new API.

# CodxLib 1.5.0 *This file is for **Forge 1.20.6**. Every loader ships the same CodxLib version, so the notes below apply here too.* **`/codxlib help` now also writes a `.mrpack`.** Drop that one file into the Modrinth App (**Add instance → From file**) and it rebuilds the instance the report came from: same Minecraft version, same loader, every mod it can find on Modrinth, the codx mods' settings, and a world on **the same seed**. "It crashes on my world" becomes a single attachment. - The world travels as settings, not terrain — only `level.dat`, so Minecraft regenerates from your seed. A few kilobytes, and nothing you have built is in it. - Mods that aren't on Modrinth (CurseForge-only, private, self-edited) are listed in the pack's `codxlib-debug/README.txt` to add by hand, never dropped silently. No jars are copied in. - **`/codxlib pack`** writes just the modpack. Same permissions as `/codxlib help`. **Developers:** new `CodxInstancePack.writeAsync(server)` and `CodxLib.gameDir()` / `IPlatformHelper#getGameDir()` — **a mod shipping its own `IPlatformHelper` must implement it.** Nothing else from 1.4.x changed; raise your range to `[1.5.0,)` only if you use the new API.

# CodxLib 1.5.0 *This file is for **Fabric 1.20.6**. It requires **Fabric Loader 0.15.6 or newer** — exactly what Fabric API already needs on 1.20.6, so CodxLib adds no restriction of its own.* **`/codxlib help` now also writes a `.mrpack`.** Drop that one file into the Modrinth App (**Add instance → From file**) and it rebuilds the instance the report came from: same Minecraft version, same loader, every mod it can find on Modrinth, the codx mods' settings, and a world on **the same seed**. "It crashes on my world" becomes a single attachment. - The world travels as settings, not terrain — only `level.dat`, so Minecraft regenerates from your seed. A few kilobytes, and nothing you have built is in it. - Mods that aren't on Modrinth (CurseForge-only, private, self-edited) are listed in the pack's `codxlib-debug/README.txt` to add by hand, never dropped silently. No jars are copied in. - **`/codxlib pack`** writes just the modpack. Same permissions as `/codxlib help`. **Developers:** new `CodxInstancePack.writeAsync(server)` and `CodxLib.gameDir()` / `IPlatformHelper#getGameDir()` — **a mod shipping its own `IPlatformHelper` must implement it.** Nothing else from 1.4.x changed; raise your range to `[1.5.0,)` only if you use the new API.

# CodxLib 1.5.0 *This file is for **Fabric 1.20.5**. It requires **Fabric Loader 0.15.6 or newer** — exactly what Fabric API already needs on 1.20.5, so CodxLib adds no restriction of its own.* **`/codxlib help` now also writes a `.mrpack`.** Drop that one file into the Modrinth App (**Add instance → From file**) and it rebuilds the instance the report came from: same Minecraft version, same loader, every mod it can find on Modrinth, the codx mods' settings, and a world on **the same seed**. "It crashes on my world" becomes a single attachment. - The world travels as settings, not terrain — only `level.dat`, so Minecraft regenerates from your seed. A few kilobytes, and nothing you have built is in it. - Mods that aren't on Modrinth (CurseForge-only, private, self-edited) are listed in the pack's `codxlib-debug/README.txt` to add by hand, never dropped silently. No jars are copied in. - **`/codxlib pack`** writes just the modpack. Same permissions as `/codxlib help`. **Developers:** new `CodxInstancePack.writeAsync(server)` and `CodxLib.gameDir()` / `IPlatformHelper#getGameDir()` — **a mod shipping its own `IPlatformHelper` must implement it.** Nothing else from 1.4.x changed; raise your range to `[1.5.0,)` only if you use the new API.

# CodxLib 1.5.0 *This file is for **NeoForge 1.20.4**. Every loader ships the same CodxLib version, so the notes below apply here too.* **`/codxlib help` now also writes a `.mrpack`.** Drop that one file into the Modrinth App (**Add instance → From file**) and it rebuilds the instance the report came from: same Minecraft version, same loader, every mod it can find on Modrinth, the codx mods' settings, and a world on **the same seed**. "It crashes on my world" becomes a single attachment. - The world travels as settings, not terrain — only `level.dat`, so Minecraft regenerates from your seed. A few kilobytes, and nothing you have built is in it. - Mods that aren't on Modrinth (CurseForge-only, private, self-edited) are listed in the pack's `codxlib-debug/README.txt` to add by hand, never dropped silently. No jars are copied in. - **`/codxlib pack`** writes just the modpack. Same permissions as `/codxlib help`. **Developers:** new `CodxInstancePack.writeAsync(server)` and `CodxLib.gameDir()` / `IPlatformHelper#getGameDir()` — **a mod shipping its own `IPlatformHelper` must implement it.** Nothing else from 1.4.x changed; raise your range to `[1.5.0,)` only if you use the new API.

# CodxLib 1.5.0 *This file is for **Forge 1.20.4**. Every loader ships the same CodxLib version, so the notes below apply here too.* **`/codxlib help` now also writes a `.mrpack`.** Drop that one file into the Modrinth App (**Add instance → From file**) and it rebuilds the instance the report came from: same Minecraft version, same loader, every mod it can find on Modrinth, the codx mods' settings, and a world on **the same seed**. "It crashes on my world" becomes a single attachment. - The world travels as settings, not terrain — only `level.dat`, so Minecraft regenerates from your seed. A few kilobytes, and nothing you have built is in it. - Mods that aren't on Modrinth (CurseForge-only, private, self-edited) are listed in the pack's `codxlib-debug/README.txt` to add by hand, never dropped silently. No jars are copied in. - **`/codxlib pack`** writes just the modpack. Same permissions as `/codxlib help`. **Developers:** new `CodxInstancePack.writeAsync(server)` and `CodxLib.gameDir()` / `IPlatformHelper#getGameDir()` — **a mod shipping its own `IPlatformHelper` must implement it.** Nothing else from 1.4.x changed; raise your range to `[1.5.0,)` only if you use the new API.

# CodxLib 1.5.0 *This file is for **Fabric 1.20.4**. It requires **Fabric Loader 0.15.1 or newer** — exactly what Fabric API already needs on 1.20.4, so CodxLib adds no restriction of its own.* **`/codxlib help` now also writes a `.mrpack`.** Drop that one file into the Modrinth App (**Add instance → From file**) and it rebuilds the instance the report came from: same Minecraft version, same loader, every mod it can find on Modrinth, the codx mods' settings, and a world on **the same seed**. "It crashes on my world" becomes a single attachment. - The world travels as settings, not terrain — only `level.dat`, so Minecraft regenerates from your seed. A few kilobytes, and nothing you have built is in it. - Mods that aren't on Modrinth (CurseForge-only, private, self-edited) are listed in the pack's `codxlib-debug/README.txt` to add by hand, never dropped silently. No jars are copied in. - **`/codxlib pack`** writes just the modpack. Same permissions as `/codxlib help`. **Developers:** new `CodxInstancePack.writeAsync(server)` and `CodxLib.gameDir()` / `IPlatformHelper#getGameDir()` — **a mod shipping its own `IPlatformHelper` must implement it.** Nothing else from 1.4.x changed; raise your range to `[1.5.0,)` only if you use the new API.

# CodxLib 1.5.0 *This file is for **Fabric 1.20.3**. It requires **Fabric Loader 0.14.23 or newer** — exactly what Fabric API already needs on 1.20.3, so CodxLib adds no restriction of its own.* **`/codxlib help` now also writes a `.mrpack`.** Drop that one file into the Modrinth App (**Add instance → From file**) and it rebuilds the instance the report came from: same Minecraft version, same loader, every mod it can find on Modrinth, the codx mods' settings, and a world on **the same seed**. "It crashes on my world" becomes a single attachment. - The world travels as settings, not terrain — only `level.dat`, so Minecraft regenerates from your seed. A few kilobytes, and nothing you have built is in it. - Mods that aren't on Modrinth (CurseForge-only, private, self-edited) are listed in the pack's `codxlib-debug/README.txt` to add by hand, never dropped silently. No jars are copied in. - **`/codxlib pack`** writes just the modpack. Same permissions as `/codxlib help`. **Developers:** new `CodxInstancePack.writeAsync(server)` and `CodxLib.gameDir()` / `IPlatformHelper#getGameDir()` — **a mod shipping its own `IPlatformHelper` must implement it.** Nothing else from 1.4.x changed; raise your range to `[1.5.0,)` only if you use the new API.

# CodxLib 1.5.0 *This file is for **Fabric 1.20.2**. It requires **Fabric Loader 0.14.22 or newer** — exactly what Fabric API already needs on 1.20.2, so CodxLib adds no restriction of its own.* **`/codxlib help` now also writes a `.mrpack`.** Drop that one file into the Modrinth App (**Add instance → From file**) and it rebuilds the instance the report came from: same Minecraft version, same loader, every mod it can find on Modrinth, the codx mods' settings, and a world on **the same seed**. "It crashes on my world" becomes a single attachment. - The world travels as settings, not terrain — only `level.dat`, so Minecraft regenerates from your seed. A few kilobytes, and nothing you have built is in it. - Mods that aren't on Modrinth (CurseForge-only, private, self-edited) are listed in the pack's `codxlib-debug/README.txt` to add by hand, never dropped silently. No jars are copied in. - **`/codxlib pack`** writes just the modpack. Same permissions as `/codxlib help`. **Developers:** new `CodxInstancePack.writeAsync(server)` and `CodxLib.gameDir()` / `IPlatformHelper#getGameDir()` — **a mod shipping its own `IPlatformHelper` must implement it.** Nothing else from 1.4.x changed; raise your range to `[1.5.0,)` only if you use the new API.

# CodxLib 1.5.0 *This file is for **Forge 1.20.1**. Every loader ships the same CodxLib version, so the notes below apply here too.* **`/codxlib help` now also writes a `.mrpack`.** Drop that one file into the Modrinth App (**Add instance → From file**) and it rebuilds the instance the report came from: same Minecraft version, same loader, every mod it can find on Modrinth, the codx mods' settings, and a world on **the same seed**. "It crashes on my world" becomes a single attachment. - The world travels as settings, not terrain — only `level.dat`, so Minecraft regenerates from your seed. A few kilobytes, and nothing you have built is in it. - Mods that aren't on Modrinth (CurseForge-only, private, self-edited) are listed in the pack's `codxlib-debug/README.txt` to add by hand, never dropped silently. No jars are copied in. - **`/codxlib pack`** writes just the modpack. Same permissions as `/codxlib help`. **Developers:** new `CodxInstancePack.writeAsync(server)` and `CodxLib.gameDir()` / `IPlatformHelper#getGameDir()` — **a mod shipping its own `IPlatformHelper` must implement it.** Nothing else from 1.4.x changed; raise your range to `[1.5.0,)` only if you use the new API.

# CodxLib 1.5.0 *This file is for **Fabric 1.20.1**. It requires **Fabric Loader 0.16.10 or newer** — exactly what Fabric API already needs on 1.20.1, so CodxLib adds no restriction of its own.* **`/codxlib help` now also writes a `.mrpack`.** Drop that one file into the Modrinth App (**Add instance → From file**) and it rebuilds the instance the report came from: same Minecraft version, same loader, every mod it can find on Modrinth, the codx mods' settings, and a world on **the same seed**. "It crashes on my world" becomes a single attachment. - The world travels as settings, not terrain — only `level.dat`, so Minecraft regenerates from your seed. A few kilobytes, and nothing you have built is in it. - Mods that aren't on Modrinth (CurseForge-only, private, self-edited) are listed in the pack's `codxlib-debug/README.txt` to add by hand, never dropped silently. No jars are copied in. - **`/codxlib pack`** writes just the modpack. Same permissions as `/codxlib help`. **Developers:** new `CodxInstancePack.writeAsync(server)` and `CodxLib.gameDir()` / `IPlatformHelper#getGameDir()` — **a mod shipping its own `IPlatformHelper` must implement it.** Nothing else from 1.4.x changed; raise your range to `[1.5.0,)` only if you use the new API.

# CodxLib 1.4.0 *This file is for **NeoForge 26.2**. Every loader ships the same CodxLib version, so the notes below apply here too.* **Update notices link to both stores again.** A notice now ends in a clickable **Modrinth** and **CurseForge** link, and you click whichever you installed the mod from. 1.3.6 had removed the link entirely because pointing at one store sent about half of you to the wrong place — offering both is the better answer to that. Both stores are also now checked for the newer version, so a release notifies you even if it has only landed on one of them so far. This applies to every codx mod, and only CodxLib needs updating for it. **New: a shared settings system for mods built on CodxLib.** A mod declares its options once and gets four things from that one declaration: the JSON config file, a `/… config` command, an in-game chest menu, and the handles its own code reads. Nothing changes for you unless a mod uses it — CodxLib on its own still adds no commands or menus of its own. When a mod does move onto it, its settings become changeable **without stopping the server**, and your existing config file is read once and carried over on any loader, so nothing is lost. Alex's Mobs Continued 2.0.15 is the first mod to use it. ### For developers - **`codx.codxlib.api.settings.CodxSettings`** — a loader-neutral config spec whose builder mirrors `ForgeConfigSpec.Builder` (`push`/`pop`/`comment`/`define`/`defineInRange`/`defineList`/ `configure`), so porting is a change of import. `CodxSettingsCommand.node(...)` generates the whole command tree from a spec; `CodxSettingsMenu.builder(spec)` generates the chest menu. Gson-backed, comments written as sibling `"// name"` keys, `Builder#legacyFiles(...)` imports an older file. ⚠️ Writes don't bake themselves — pass `Builder#onChange` if you copy handles into static fields. - **`ModInfo` names CurseForge too** — two new components, `curseforgeSlug` (for the link) and `curseforgeProjectId` (for the version check; the two routes need different keys). The old 4-argument constructor and `ModInfo.of(id, slug, version)` still compile unchanged, and CodxLib already knows the ids of the published codx mods, so existing ones get correct links with no rebuild. - **Menu toolkit**: `CodxMenuLayout#adjustDouble`, `CodxMenuLayout#cycle`, and `PagedMenuBuilder#decorate` (a widget applied to every page). **Compatibility:** everything from 1.3.x is unchanged. Only a mod that wants the settings system has to raise its `codxlib` range to `[1.4.0,)`.

# CodxLib 1.4.0 *This file is for **Forge 26.2**. Every loader ships the same CodxLib version, so the notes below apply here too.* **Update notices link to both stores again.** A notice now ends in a clickable **Modrinth** and **CurseForge** link, and you click whichever you installed the mod from. 1.3.6 had removed the link entirely because pointing at one store sent about half of you to the wrong place — offering both is the better answer to that. Both stores are also now checked for the newer version, so a release notifies you even if it has only landed on one of them so far. This applies to every codx mod, and only CodxLib needs updating for it. **New: a shared settings system for mods built on CodxLib.** A mod declares its options once and gets four things from that one declaration: the JSON config file, a `/… config` command, an in-game chest menu, and the handles its own code reads. Nothing changes for you unless a mod uses it — CodxLib on its own still adds no commands or menus of its own. When a mod does move onto it, its settings become changeable **without stopping the server**, and your existing config file is read once and carried over on any loader, so nothing is lost. Alex's Mobs Continued 2.0.15 is the first mod to use it. ### For developers - **`codx.codxlib.api.settings.CodxSettings`** — a loader-neutral config spec whose builder mirrors `ForgeConfigSpec.Builder` (`push`/`pop`/`comment`/`define`/`defineInRange`/`defineList`/ `configure`), so porting is a change of import. `CodxSettingsCommand.node(...)` generates the whole command tree from a spec; `CodxSettingsMenu.builder(spec)` generates the chest menu. Gson-backed, comments written as sibling `"// name"` keys, `Builder#legacyFiles(...)` imports an older file. ⚠️ Writes don't bake themselves — pass `Builder#onChange` if you copy handles into static fields. - **`ModInfo` names CurseForge too** — two new components, `curseforgeSlug` (for the link) and `curseforgeProjectId` (for the version check; the two routes need different keys). The old 4-argument constructor and `ModInfo.of(id, slug, version)` still compile unchanged, and CodxLib already knows the ids of the published codx mods, so existing ones get correct links with no rebuild. - **Menu toolkit**: `CodxMenuLayout#adjustDouble`, `CodxMenuLayout#cycle`, and `PagedMenuBuilder#decorate` (a widget applied to every page). **Compatibility:** everything from 1.3.x is unchanged. Only a mod that wants the settings system has to raise its `codxlib` range to `[1.4.0,)`.

# CodxLib 1.4.0 *This file is for **NeoForge 26.1.2**. Every loader ships the same CodxLib version, so the notes below apply here too.* **Update notices link to both stores again.** A notice now ends in a clickable **Modrinth** and **CurseForge** link, and you click whichever you installed the mod from. 1.3.6 had removed the link entirely because pointing at one store sent about half of you to the wrong place — offering both is the better answer to that. Both stores are also now checked for the newer version, so a release notifies you even if it has only landed on one of them so far. This applies to every codx mod, and only CodxLib needs updating for it. **New: a shared settings system for mods built on CodxLib.** A mod declares its options once and gets four things from that one declaration: the JSON config file, a `/… config` command, an in-game chest menu, and the handles its own code reads. Nothing changes for you unless a mod uses it — CodxLib on its own still adds no commands or menus of its own. When a mod does move onto it, its settings become changeable **without stopping the server**, and your existing config file is read once and carried over on any loader, so nothing is lost. Alex's Mobs Continued 2.0.15 is the first mod to use it. ### For developers - **`codx.codxlib.api.settings.CodxSettings`** — a loader-neutral config spec whose builder mirrors `ForgeConfigSpec.Builder` (`push`/`pop`/`comment`/`define`/`defineInRange`/`defineList`/ `configure`), so porting is a change of import. `CodxSettingsCommand.node(...)` generates the whole command tree from a spec; `CodxSettingsMenu.builder(spec)` generates the chest menu. Gson-backed, comments written as sibling `"// name"` keys, `Builder#legacyFiles(...)` imports an older file. ⚠️ Writes don't bake themselves — pass `Builder#onChange` if you copy handles into static fields. - **`ModInfo` names CurseForge too** — two new components, `curseforgeSlug` (for the link) and `curseforgeProjectId` (for the version check; the two routes need different keys). The old 4-argument constructor and `ModInfo.of(id, slug, version)` still compile unchanged, and CodxLib already knows the ids of the published codx mods, so existing ones get correct links with no rebuild. - **Menu toolkit**: `CodxMenuLayout#adjustDouble`, `CodxMenuLayout#cycle`, and `PagedMenuBuilder#decorate` (a widget applied to every page). **Compatibility:** everything from 1.3.x is unchanged. Only a mod that wants the settings system has to raise its `codxlib` range to `[1.4.0,)`.

# CodxLib 1.4.0 *This file is for **Forge 26.1.2**. Every loader ships the same CodxLib version, so the notes below apply here too.* **Update notices link to both stores again.** A notice now ends in a clickable **Modrinth** and **CurseForge** link, and you click whichever you installed the mod from. 1.3.6 had removed the link entirely because pointing at one store sent about half of you to the wrong place — offering both is the better answer to that. Both stores are also now checked for the newer version, so a release notifies you even if it has only landed on one of them so far. This applies to every codx mod, and only CodxLib needs updating for it. **New: a shared settings system for mods built on CodxLib.** A mod declares its options once and gets four things from that one declaration: the JSON config file, a `/… config` command, an in-game chest menu, and the handles its own code reads. Nothing changes for you unless a mod uses it — CodxLib on its own still adds no commands or menus of its own. When a mod does move onto it, its settings become changeable **without stopping the server**, and your existing config file is read once and carried over on any loader, so nothing is lost. Alex's Mobs Continued 2.0.15 is the first mod to use it. ### For developers - **`codx.codxlib.api.settings.CodxSettings`** — a loader-neutral config spec whose builder mirrors `ForgeConfigSpec.Builder` (`push`/`pop`/`comment`/`define`/`defineInRange`/`defineList`/ `configure`), so porting is a change of import. `CodxSettingsCommand.node(...)` generates the whole command tree from a spec; `CodxSettingsMenu.builder(spec)` generates the chest menu. Gson-backed, comments written as sibling `"// name"` keys, `Builder#legacyFiles(...)` imports an older file. ⚠️ Writes don't bake themselves — pass `Builder#onChange` if you copy handles into static fields. - **`ModInfo` names CurseForge too** — two new components, `curseforgeSlug` (for the link) and `curseforgeProjectId` (for the version check; the two routes need different keys). The old 4-argument constructor and `ModInfo.of(id, slug, version)` still compile unchanged, and CodxLib already knows the ids of the published codx mods, so existing ones get correct links with no rebuild. - **Menu toolkit**: `CodxMenuLayout#adjustDouble`, `CodxMenuLayout#cycle`, and `PagedMenuBuilder#decorate` (a widget applied to every page). **Compatibility:** everything from 1.3.x is unchanged. Only a mod that wants the settings system has to raise its `codxlib` range to `[1.4.0,)`.

# CodxLib 1.4.0 *This file is for **Fabric 26.1.2**. It requires **Fabric Loader 0.18.4 or newer** — exactly what Fabric API already needs on 26.1.2, so CodxLib adds no restriction of its own.* **Update notices link to both stores again.** A notice now ends in a clickable **Modrinth** and **CurseForge** link, and you click whichever you installed the mod from. 1.3.6 had removed the link entirely because pointing at one store sent about half of you to the wrong place — offering both is the better answer to that. Both stores are also now checked for the newer version, so a release notifies you even if it has only landed on one of them so far. This applies to every codx mod, and only CodxLib needs updating for it. **New: a shared settings system for mods built on CodxLib.** A mod declares its options once and gets four things from that one declaration: the JSON config file, a `/… config` command, an in-game chest menu, and the handles its own code reads. Nothing changes for you unless a mod uses it — CodxLib on its own still adds no commands or menus of its own. When a mod does move onto it, its settings become changeable **without stopping the server**, and your existing config file is read once and carried over on any loader, so nothing is lost. Alex's Mobs Continued 2.0.15 is the first mod to use it. ### For developers - **`codx.codxlib.api.settings.CodxSettings`** — a loader-neutral config spec whose builder mirrors `ForgeConfigSpec.Builder` (`push`/`pop`/`comment`/`define`/`defineInRange`/`defineList`/ `configure`), so porting is a change of import. `CodxSettingsCommand.node(...)` generates the whole command tree from a spec; `CodxSettingsMenu.builder(spec)` generates the chest menu. Gson-backed, comments written as sibling `"// name"` keys, `Builder#legacyFiles(...)` imports an older file. ⚠️ Writes don't bake themselves — pass `Builder#onChange` if you copy handles into static fields. - **`ModInfo` names CurseForge too** — two new components, `curseforgeSlug` (for the link) and `curseforgeProjectId` (for the version check; the two routes need different keys). The old 4-argument constructor and `ModInfo.of(id, slug, version)` still compile unchanged, and CodxLib already knows the ids of the published codx mods, so existing ones get correct links with no rebuild. - **Menu toolkit**: `CodxMenuLayout#adjustDouble`, `CodxMenuLayout#cycle`, and `PagedMenuBuilder#decorate` (a widget applied to every page). **Compatibility:** everything from 1.3.x is unchanged. Only a mod that wants the settings system has to raise its `codxlib` range to `[1.4.0,)`.

# CodxLib 1.4.0 *This file is for **NeoForge 26.1.1**. Every loader ships the same CodxLib version, so the notes below apply here too.* **Update notices link to both stores again.** A notice now ends in a clickable **Modrinth** and **CurseForge** link, and you click whichever you installed the mod from. 1.3.6 had removed the link entirely because pointing at one store sent about half of you to the wrong place — offering both is the better answer to that. Both stores are also now checked for the newer version, so a release notifies you even if it has only landed on one of them so far. This applies to every codx mod, and only CodxLib needs updating for it. **New: a shared settings system for mods built on CodxLib.** A mod declares its options once and gets four things from that one declaration: the JSON config file, a `/… config` command, an in-game chest menu, and the handles its own code reads. Nothing changes for you unless a mod uses it — CodxLib on its own still adds no commands or menus of its own. When a mod does move onto it, its settings become changeable **without stopping the server**, and your existing config file is read once and carried over on any loader, so nothing is lost. Alex's Mobs Continued 2.0.15 is the first mod to use it. ### For developers - **`codx.codxlib.api.settings.CodxSettings`** — a loader-neutral config spec whose builder mirrors `ForgeConfigSpec.Builder` (`push`/`pop`/`comment`/`define`/`defineInRange`/`defineList`/ `configure`), so porting is a change of import. `CodxSettingsCommand.node(...)` generates the whole command tree from a spec; `CodxSettingsMenu.builder(spec)` generates the chest menu. Gson-backed, comments written as sibling `"// name"` keys, `Builder#legacyFiles(...)` imports an older file. ⚠️ Writes don't bake themselves — pass `Builder#onChange` if you copy handles into static fields. - **`ModInfo` names CurseForge too** — two new components, `curseforgeSlug` (for the link) and `curseforgeProjectId` (for the version check; the two routes need different keys). The old 4-argument constructor and `ModInfo.of(id, slug, version)` still compile unchanged, and CodxLib already knows the ids of the published codx mods, so existing ones get correct links with no rebuild. - **Menu toolkit**: `CodxMenuLayout#adjustDouble`, `CodxMenuLayout#cycle`, and `PagedMenuBuilder#decorate` (a widget applied to every page). **Compatibility:** everything from 1.3.x is unchanged. Only a mod that wants the settings system has to raise its `codxlib` range to `[1.4.0,)`.

# CodxLib 1.4.0 *This file is for **Forge 26.1.1**. Every loader ships the same CodxLib version, so the notes below apply here too.* **Update notices link to both stores again.** A notice now ends in a clickable **Modrinth** and **CurseForge** link, and you click whichever you installed the mod from. 1.3.6 had removed the link entirely because pointing at one store sent about half of you to the wrong place — offering both is the better answer to that. Both stores are also now checked for the newer version, so a release notifies you even if it has only landed on one of them so far. This applies to every codx mod, and only CodxLib needs updating for it. **New: a shared settings system for mods built on CodxLib.** A mod declares its options once and gets four things from that one declaration: the JSON config file, a `/… config` command, an in-game chest menu, and the handles its own code reads. Nothing changes for you unless a mod uses it — CodxLib on its own still adds no commands or menus of its own. When a mod does move onto it, its settings become changeable **without stopping the server**, and your existing config file is read once and carried over on any loader, so nothing is lost. Alex's Mobs Continued 2.0.15 is the first mod to use it. ### For developers - **`codx.codxlib.api.settings.CodxSettings`** — a loader-neutral config spec whose builder mirrors `ForgeConfigSpec.Builder` (`push`/`pop`/`comment`/`define`/`defineInRange`/`defineList`/ `configure`), so porting is a change of import. `CodxSettingsCommand.node(...)` generates the whole command tree from a spec; `CodxSettingsMenu.builder(spec)` generates the chest menu. Gson-backed, comments written as sibling `"// name"` keys, `Builder#legacyFiles(...)` imports an older file. ⚠️ Writes don't bake themselves — pass `Builder#onChange` if you copy handles into static fields. - **`ModInfo` names CurseForge too** — two new components, `curseforgeSlug` (for the link) and `curseforgeProjectId` (for the version check; the two routes need different keys). The old 4-argument constructor and `ModInfo.of(id, slug, version)` still compile unchanged, and CodxLib already knows the ids of the published codx mods, so existing ones get correct links with no rebuild. - **Menu toolkit**: `CodxMenuLayout#adjustDouble`, `CodxMenuLayout#cycle`, and `PagedMenuBuilder#decorate` (a widget applied to every page). **Compatibility:** everything from 1.3.x is unchanged. Only a mod that wants the settings system has to raise its `codxlib` range to `[1.4.0,)`.

# CodxLib 1.4.0 *This file is for **Fabric 26.1.1**. It requires **Fabric Loader 0.18.4 or newer** — exactly what Fabric API already needs on 26.1.1, so CodxLib adds no restriction of its own.* **Update notices link to both stores again.** A notice now ends in a clickable **Modrinth** and **CurseForge** link, and you click whichever you installed the mod from. 1.3.6 had removed the link entirely because pointing at one store sent about half of you to the wrong place — offering both is the better answer to that. Both stores are also now checked for the newer version, so a release notifies you even if it has only landed on one of them so far. This applies to every codx mod, and only CodxLib needs updating for it. **New: a shared settings system for mods built on CodxLib.** A mod declares its options once and gets four things from that one declaration: the JSON config file, a `/… config` command, an in-game chest menu, and the handles its own code reads. Nothing changes for you unless a mod uses it — CodxLib on its own still adds no commands or menus of its own. When a mod does move onto it, its settings become changeable **without stopping the server**, and your existing config file is read once and carried over on any loader, so nothing is lost. Alex's Mobs Continued 2.0.15 is the first mod to use it. ### For developers - **`codx.codxlib.api.settings.CodxSettings`** — a loader-neutral config spec whose builder mirrors `ForgeConfigSpec.Builder` (`push`/`pop`/`comment`/`define`/`defineInRange`/`defineList`/ `configure`), so porting is a change of import. `CodxSettingsCommand.node(...)` generates the whole command tree from a spec; `CodxSettingsMenu.builder(spec)` generates the chest menu. Gson-backed, comments written as sibling `"// name"` keys, `Builder#legacyFiles(...)` imports an older file. ⚠️ Writes don't bake themselves — pass `Builder#onChange` if you copy handles into static fields. - **`ModInfo` names CurseForge too** — two new components, `curseforgeSlug` (for the link) and `curseforgeProjectId` (for the version check; the two routes need different keys). The old 4-argument constructor and `ModInfo.of(id, slug, version)` still compile unchanged, and CodxLib already knows the ids of the published codx mods, so existing ones get correct links with no rebuild. - **Menu toolkit**: `CodxMenuLayout#adjustDouble`, `CodxMenuLayout#cycle`, and `PagedMenuBuilder#decorate` (a widget applied to every page). **Compatibility:** everything from 1.3.x is unchanged. Only a mod that wants the settings system has to raise its `codxlib` range to `[1.4.0,)`.

# CodxLib 1.4.0 *This file is for **NeoForge 26.1**. Every loader ships the same CodxLib version, so the notes below apply here too.* **Update notices link to both stores again.** A notice now ends in a clickable **Modrinth** and **CurseForge** link, and you click whichever you installed the mod from. 1.3.6 had removed the link entirely because pointing at one store sent about half of you to the wrong place — offering both is the better answer to that. Both stores are also now checked for the newer version, so a release notifies you even if it has only landed on one of them so far. This applies to every codx mod, and only CodxLib needs updating for it. **New: a shared settings system for mods built on CodxLib.** A mod declares its options once and gets four things from that one declaration: the JSON config file, a `/… config` command, an in-game chest menu, and the handles its own code reads. Nothing changes for you unless a mod uses it — CodxLib on its own still adds no commands or menus of its own. When a mod does move onto it, its settings become changeable **without stopping the server**, and your existing config file is read once and carried over on any loader, so nothing is lost. Alex's Mobs Continued 2.0.15 is the first mod to use it. ### For developers - **`codx.codxlib.api.settings.CodxSettings`** — a loader-neutral config spec whose builder mirrors `ForgeConfigSpec.Builder` (`push`/`pop`/`comment`/`define`/`defineInRange`/`defineList`/ `configure`), so porting is a change of import. `CodxSettingsCommand.node(...)` generates the whole command tree from a spec; `CodxSettingsMenu.builder(spec)` generates the chest menu. Gson-backed, comments written as sibling `"// name"` keys, `Builder#legacyFiles(...)` imports an older file. ⚠️ Writes don't bake themselves — pass `Builder#onChange` if you copy handles into static fields. - **`ModInfo` names CurseForge too** — two new components, `curseforgeSlug` (for the link) and `curseforgeProjectId` (for the version check; the two routes need different keys). The old 4-argument constructor and `ModInfo.of(id, slug, version)` still compile unchanged, and CodxLib already knows the ids of the published codx mods, so existing ones get correct links with no rebuild. - **Menu toolkit**: `CodxMenuLayout#adjustDouble`, `CodxMenuLayout#cycle`, and `PagedMenuBuilder#decorate` (a widget applied to every page). **Compatibility:** everything from 1.3.x is unchanged. Only a mod that wants the settings system has to raise its `codxlib` range to `[1.4.0,)`.

# CodxLib 1.4.0 *This file is for **Forge 26.1**. Every loader ships the same CodxLib version, so the notes below apply here too.* **Update notices link to both stores again.** A notice now ends in a clickable **Modrinth** and **CurseForge** link, and you click whichever you installed the mod from. 1.3.6 had removed the link entirely because pointing at one store sent about half of you to the wrong place — offering both is the better answer to that. Both stores are also now checked for the newer version, so a release notifies you even if it has only landed on one of them so far. This applies to every codx mod, and only CodxLib needs updating for it. **New: a shared settings system for mods built on CodxLib.** A mod declares its options once and gets four things from that one declaration: the JSON config file, a `/… config` command, an in-game chest menu, and the handles its own code reads. Nothing changes for you unless a mod uses it — CodxLib on its own still adds no commands or menus of its own. When a mod does move onto it, its settings become changeable **without stopping the server**, and your existing config file is read once and carried over on any loader, so nothing is lost. Alex's Mobs Continued 2.0.15 is the first mod to use it. ### For developers - **`codx.codxlib.api.settings.CodxSettings`** — a loader-neutral config spec whose builder mirrors `ForgeConfigSpec.Builder` (`push`/`pop`/`comment`/`define`/`defineInRange`/`defineList`/ `configure`), so porting is a change of import. `CodxSettingsCommand.node(...)` generates the whole command tree from a spec; `CodxSettingsMenu.builder(spec)` generates the chest menu. Gson-backed, comments written as sibling `"// name"` keys, `Builder#legacyFiles(...)` imports an older file. ⚠️ Writes don't bake themselves — pass `Builder#onChange` if you copy handles into static fields. - **`ModInfo` names CurseForge too** — two new components, `curseforgeSlug` (for the link) and `curseforgeProjectId` (for the version check; the two routes need different keys). The old 4-argument constructor and `ModInfo.of(id, slug, version)` still compile unchanged, and CodxLib already knows the ids of the published codx mods, so existing ones get correct links with no rebuild. - **Menu toolkit**: `CodxMenuLayout#adjustDouble`, `CodxMenuLayout#cycle`, and `PagedMenuBuilder#decorate` (a widget applied to every page). **Compatibility:** everything from 1.3.x is unchanged. Only a mod that wants the settings system has to raise its `codxlib` range to `[1.4.0,)`.

# CodxLib 1.4.0 *This file is for **Fabric 26.1**. It requires **Fabric Loader 0.18.4 or newer** — exactly what Fabric API already needs on 26.1, so CodxLib adds no restriction of its own.* **Update notices link to both stores again.** A notice now ends in a clickable **Modrinth** and **CurseForge** link, and you click whichever you installed the mod from. 1.3.6 had removed the link entirely because pointing at one store sent about half of you to the wrong place — offering both is the better answer to that. Both stores are also now checked for the newer version, so a release notifies you even if it has only landed on one of them so far. This applies to every codx mod, and only CodxLib needs updating for it. **New: a shared settings system for mods built on CodxLib.** A mod declares its options once and gets four things from that one declaration: the JSON config file, a `/… config` command, an in-game chest menu, and the handles its own code reads. Nothing changes for you unless a mod uses it — CodxLib on its own still adds no commands or menus of its own. When a mod does move onto it, its settings become changeable **without stopping the server**, and your existing config file is read once and carried over on any loader, so nothing is lost. Alex's Mobs Continued 2.0.15 is the first mod to use it. ### For developers - **`codx.codxlib.api.settings.CodxSettings`** — a loader-neutral config spec whose builder mirrors `ForgeConfigSpec.Builder` (`push`/`pop`/`comment`/`define`/`defineInRange`/`defineList`/ `configure`), so porting is a change of import. `CodxSettingsCommand.node(...)` generates the whole command tree from a spec; `CodxSettingsMenu.builder(spec)` generates the chest menu. Gson-backed, comments written as sibling `"// name"` keys, `Builder#legacyFiles(...)` imports an older file. ⚠️ Writes don't bake themselves — pass `Builder#onChange` if you copy handles into static fields. - **`ModInfo` names CurseForge too** — two new components, `curseforgeSlug` (for the link) and `curseforgeProjectId` (for the version check; the two routes need different keys). The old 4-argument constructor and `ModInfo.of(id, slug, version)` still compile unchanged, and CodxLib already knows the ids of the published codx mods, so existing ones get correct links with no rebuild. - **Menu toolkit**: `CodxMenuLayout#adjustDouble`, `CodxMenuLayout#cycle`, and `PagedMenuBuilder#decorate` (a widget applied to every page). **Compatibility:** everything from 1.3.x is unchanged. Only a mod that wants the settings system has to raise its `codxlib` range to `[1.4.0,)`.

# CodxLib 1.4.0 *This file is for **NeoForge 1.21.11**. Every loader ships the same CodxLib version, so the notes below apply here too.* **Update notices link to both stores again.** A notice now ends in a clickable **Modrinth** and **CurseForge** link, and you click whichever you installed the mod from. 1.3.6 had removed the link entirely because pointing at one store sent about half of you to the wrong place — offering both is the better answer to that. Both stores are also now checked for the newer version, so a release notifies you even if it has only landed on one of them so far. This applies to every codx mod, and only CodxLib needs updating for it. **New: a shared settings system for mods built on CodxLib.** A mod declares its options once and gets four things from that one declaration: the JSON config file, a `/… config` command, an in-game chest menu, and the handles its own code reads. Nothing changes for you unless a mod uses it — CodxLib on its own still adds no commands or menus of its own. When a mod does move onto it, its settings become changeable **without stopping the server**, and your existing config file is read once and carried over on any loader, so nothing is lost. Alex's Mobs Continued 2.0.15 is the first mod to use it. ### For developers - **`codx.codxlib.api.settings.CodxSettings`** — a loader-neutral config spec whose builder mirrors `ForgeConfigSpec.Builder` (`push`/`pop`/`comment`/`define`/`defineInRange`/`defineList`/ `configure`), so porting is a change of import. `CodxSettingsCommand.node(...)` generates the whole command tree from a spec; `CodxSettingsMenu.builder(spec)` generates the chest menu. Gson-backed, comments written as sibling `"// name"` keys, `Builder#legacyFiles(...)` imports an older file. ⚠️ Writes don't bake themselves — pass `Builder#onChange` if you copy handles into static fields. - **`ModInfo` names CurseForge too** — two new components, `curseforgeSlug` (for the link) and `curseforgeProjectId` (for the version check; the two routes need different keys). The old 4-argument constructor and `ModInfo.of(id, slug, version)` still compile unchanged, and CodxLib already knows the ids of the published codx mods, so existing ones get correct links with no rebuild. - **Menu toolkit**: `CodxMenuLayout#adjustDouble`, `CodxMenuLayout#cycle`, and `PagedMenuBuilder#decorate` (a widget applied to every page). **Compatibility:** everything from 1.3.x is unchanged. Only a mod that wants the settings system has to raise its `codxlib` range to `[1.4.0,)`.

# CodxLib 1.4.0 *This file is for **Forge 1.21.11**. Every loader ships the same CodxLib version, so the notes below apply here too.* **Update notices link to both stores again.** A notice now ends in a clickable **Modrinth** and **CurseForge** link, and you click whichever you installed the mod from. 1.3.6 had removed the link entirely because pointing at one store sent about half of you to the wrong place — offering both is the better answer to that. Both stores are also now checked for the newer version, so a release notifies you even if it has only landed on one of them so far. This applies to every codx mod, and only CodxLib needs updating for it. **New: a shared settings system for mods built on CodxLib.** A mod declares its options once and gets four things from that one declaration: the JSON config file, a `/… config` command, an in-game chest menu, and the handles its own code reads. Nothing changes for you unless a mod uses it — CodxLib on its own still adds no commands or menus of its own. When a mod does move onto it, its settings become changeable **without stopping the server**, and your existing config file is read once and carried over on any loader, so nothing is lost. Alex's Mobs Continued 2.0.15 is the first mod to use it. ### For developers - **`codx.codxlib.api.settings.CodxSettings`** — a loader-neutral config spec whose builder mirrors `ForgeConfigSpec.Builder` (`push`/`pop`/`comment`/`define`/`defineInRange`/`defineList`/ `configure`), so porting is a change of import. `CodxSettingsCommand.node(...)` generates the whole command tree from a spec; `CodxSettingsMenu.builder(spec)` generates the chest menu. Gson-backed, comments written as sibling `"// name"` keys, `Builder#legacyFiles(...)` imports an older file. ⚠️ Writes don't bake themselves — pass `Builder#onChange` if you copy handles into static fields. - **`ModInfo` names CurseForge too** — two new components, `curseforgeSlug` (for the link) and `curseforgeProjectId` (for the version check; the two routes need different keys). The old 4-argument constructor and `ModInfo.of(id, slug, version)` still compile unchanged, and CodxLib already knows the ids of the published codx mods, so existing ones get correct links with no rebuild. - **Menu toolkit**: `CodxMenuLayout#adjustDouble`, `CodxMenuLayout#cycle`, and `PagedMenuBuilder#decorate` (a widget applied to every page). **Compatibility:** everything from 1.3.x is unchanged. Only a mod that wants the settings system has to raise its `codxlib` range to `[1.4.0,)`.

# CodxLib 1.4.0 *This file is for **Fabric 1.21.11**. It requires **Fabric Loader 0.17.3 or newer** — exactly what Fabric API already needs on 1.21.11, so CodxLib adds no restriction of its own.* **Update notices link to both stores again.** A notice now ends in a clickable **Modrinth** and **CurseForge** link, and you click whichever you installed the mod from. 1.3.6 had removed the link entirely because pointing at one store sent about half of you to the wrong place — offering both is the better answer to that. Both stores are also now checked for the newer version, so a release notifies you even if it has only landed on one of them so far. This applies to every codx mod, and only CodxLib needs updating for it. **New: a shared settings system for mods built on CodxLib.** A mod declares its options once and gets four things from that one declaration: the JSON config file, a `/… config` command, an in-game chest menu, and the handles its own code reads. Nothing changes for you unless a mod uses it — CodxLib on its own still adds no commands or menus of its own. When a mod does move onto it, its settings become changeable **without stopping the server**, and your existing config file is read once and carried over on any loader, so nothing is lost. Alex's Mobs Continued 2.0.15 is the first mod to use it. ### For developers - **`codx.codxlib.api.settings.CodxSettings`** — a loader-neutral config spec whose builder mirrors `ForgeConfigSpec.Builder` (`push`/`pop`/`comment`/`define`/`defineInRange`/`defineList`/ `configure`), so porting is a change of import. `CodxSettingsCommand.node(...)` generates the whole command tree from a spec; `CodxSettingsMenu.builder(spec)` generates the chest menu. Gson-backed, comments written as sibling `"// name"` keys, `Builder#legacyFiles(...)` imports an older file. ⚠️ Writes don't bake themselves — pass `Builder#onChange` if you copy handles into static fields. - **`ModInfo` names CurseForge too** — two new components, `curseforgeSlug` (for the link) and `curseforgeProjectId` (for the version check; the two routes need different keys). The old 4-argument constructor and `ModInfo.of(id, slug, version)` still compile unchanged, and CodxLib already knows the ids of the published codx mods, so existing ones get correct links with no rebuild. - **Menu toolkit**: `CodxMenuLayout#adjustDouble`, `CodxMenuLayout#cycle`, and `PagedMenuBuilder#decorate` (a widget applied to every page). **Compatibility:** everything from 1.3.x is unchanged. Only a mod that wants the settings system has to raise its `codxlib` range to `[1.4.0,)`.

# CodxLib 1.4.0 *This file is for **NeoForge 1.21.10**. Every loader ships the same CodxLib version, so the notes below apply here too.* **Update notices link to both stores again.** A notice now ends in a clickable **Modrinth** and **CurseForge** link, and you click whichever you installed the mod from. 1.3.6 had removed the link entirely because pointing at one store sent about half of you to the wrong place — offering both is the better answer to that. Both stores are also now checked for the newer version, so a release notifies you even if it has only landed on one of them so far. This applies to every codx mod, and only CodxLib needs updating for it. **New: a shared settings system for mods built on CodxLib.** A mod declares its options once and gets four things from that one declaration: the JSON config file, a `/… config` command, an in-game chest menu, and the handles its own code reads. Nothing changes for you unless a mod uses it — CodxLib on its own still adds no commands or menus of its own. When a mod does move onto it, its settings become changeable **without stopping the server**, and your existing config file is read once and carried over on any loader, so nothing is lost. Alex's Mobs Continued 2.0.15 is the first mod to use it. ### For developers - **`codx.codxlib.api.settings.CodxSettings`** — a loader-neutral config spec whose builder mirrors `ForgeConfigSpec.Builder` (`push`/`pop`/`comment`/`define`/`defineInRange`/`defineList`/ `configure`), so porting is a change of import. `CodxSettingsCommand.node(...)` generates the whole command tree from a spec; `CodxSettingsMenu.builder(spec)` generates the chest menu. Gson-backed, comments written as sibling `"// name"` keys, `Builder#legacyFiles(...)` imports an older file. ⚠️ Writes don't bake themselves — pass `Builder#onChange` if you copy handles into static fields. - **`ModInfo` names CurseForge too** — two new components, `curseforgeSlug` (for the link) and `curseforgeProjectId` (for the version check; the two routes need different keys). The old 4-argument constructor and `ModInfo.of(id, slug, version)` still compile unchanged, and CodxLib already knows the ids of the published codx mods, so existing ones get correct links with no rebuild. - **Menu toolkit**: `CodxMenuLayout#adjustDouble`, `CodxMenuLayout#cycle`, and `PagedMenuBuilder#decorate` (a widget applied to every page). **Compatibility:** everything from 1.3.x is unchanged. Only a mod that wants the settings system has to raise its `codxlib` range to `[1.4.0,)`.

# CodxLib 1.4.0 *This file is for **Forge 1.21.10**. Every loader ships the same CodxLib version, so the notes below apply here too.* **Update notices link to both stores again.** A notice now ends in a clickable **Modrinth** and **CurseForge** link, and you click whichever you installed the mod from. 1.3.6 had removed the link entirely because pointing at one store sent about half of you to the wrong place — offering both is the better answer to that. Both stores are also now checked for the newer version, so a release notifies you even if it has only landed on one of them so far. This applies to every codx mod, and only CodxLib needs updating for it. **New: a shared settings system for mods built on CodxLib.** A mod declares its options once and gets four things from that one declaration: the JSON config file, a `/… config` command, an in-game chest menu, and the handles its own code reads. Nothing changes for you unless a mod uses it — CodxLib on its own still adds no commands or menus of its own. When a mod does move onto it, its settings become changeable **without stopping the server**, and your existing config file is read once and carried over on any loader, so nothing is lost. Alex's Mobs Continued 2.0.15 is the first mod to use it. ### For developers - **`codx.codxlib.api.settings.CodxSettings`** — a loader-neutral config spec whose builder mirrors `ForgeConfigSpec.Builder` (`push`/`pop`/`comment`/`define`/`defineInRange`/`defineList`/ `configure`), so porting is a change of import. `CodxSettingsCommand.node(...)` generates the whole command tree from a spec; `CodxSettingsMenu.builder(spec)` generates the chest menu. Gson-backed, comments written as sibling `"// name"` keys, `Builder#legacyFiles(...)` imports an older file. ⚠️ Writes don't bake themselves — pass `Builder#onChange` if you copy handles into static fields. - **`ModInfo` names CurseForge too** — two new components, `curseforgeSlug` (for the link) and `curseforgeProjectId` (for the version check; the two routes need different keys). The old 4-argument constructor and `ModInfo.of(id, slug, version)` still compile unchanged, and CodxLib already knows the ids of the published codx mods, so existing ones get correct links with no rebuild. - **Menu toolkit**: `CodxMenuLayout#adjustDouble`, `CodxMenuLayout#cycle`, and `PagedMenuBuilder#decorate` (a widget applied to every page). **Compatibility:** everything from 1.3.x is unchanged. Only a mod that wants the settings system has to raise its `codxlib` range to `[1.4.0,)`.

# CodxLib 1.4.0 *This file is for **Fabric 1.21.10**. It requires **Fabric Loader 0.17.0 or newer** — exactly what Fabric API already needs on 1.21.10, so CodxLib adds no restriction of its own.* **Update notices link to both stores again.** A notice now ends in a clickable **Modrinth** and **CurseForge** link, and you click whichever you installed the mod from. 1.3.6 had removed the link entirely because pointing at one store sent about half of you to the wrong place — offering both is the better answer to that. Both stores are also now checked for the newer version, so a release notifies you even if it has only landed on one of them so far. This applies to every codx mod, and only CodxLib needs updating for it. **New: a shared settings system for mods built on CodxLib.** A mod declares its options once and gets four things from that one declaration: the JSON config file, a `/… config` command, an in-game chest menu, and the handles its own code reads. Nothing changes for you unless a mod uses it — CodxLib on its own still adds no commands or menus of its own. When a mod does move onto it, its settings become changeable **without stopping the server**, and your existing config file is read once and carried over on any loader, so nothing is lost. Alex's Mobs Continued 2.0.15 is the first mod to use it. ### For developers - **`codx.codxlib.api.settings.CodxSettings`** — a loader-neutral config spec whose builder mirrors `ForgeConfigSpec.Builder` (`push`/`pop`/`comment`/`define`/`defineInRange`/`defineList`/ `configure`), so porting is a change of import. `CodxSettingsCommand.node(...)` generates the whole command tree from a spec; `CodxSettingsMenu.builder(spec)` generates the chest menu. Gson-backed, comments written as sibling `"// name"` keys, `Builder#legacyFiles(...)` imports an older file. ⚠️ Writes don't bake themselves — pass `Builder#onChange` if you copy handles into static fields. - **`ModInfo` names CurseForge too** — two new components, `curseforgeSlug` (for the link) and `curseforgeProjectId` (for the version check; the two routes need different keys). The old 4-argument constructor and `ModInfo.of(id, slug, version)` still compile unchanged, and CodxLib already knows the ids of the published codx mods, so existing ones get correct links with no rebuild. - **Menu toolkit**: `CodxMenuLayout#adjustDouble`, `CodxMenuLayout#cycle`, and `PagedMenuBuilder#decorate` (a widget applied to every page). **Compatibility:** everything from 1.3.x is unchanged. Only a mod that wants the settings system has to raise its `codxlib` range to `[1.4.0,)`.

# CodxLib 1.4.0 *This file is for **NeoForge 1.21.9**. Every loader ships the same CodxLib version, so the notes below apply here too.* **Update notices link to both stores again.** A notice now ends in a clickable **Modrinth** and **CurseForge** link, and you click whichever you installed the mod from. 1.3.6 had removed the link entirely because pointing at one store sent about half of you to the wrong place — offering both is the better answer to that. Both stores are also now checked for the newer version, so a release notifies you even if it has only landed on one of them so far. This applies to every codx mod, and only CodxLib needs updating for it. **New: a shared settings system for mods built on CodxLib.** A mod declares its options once and gets four things from that one declaration: the JSON config file, a `/… config` command, an in-game chest menu, and the handles its own code reads. Nothing changes for you unless a mod uses it — CodxLib on its own still adds no commands or menus of its own. When a mod does move onto it, its settings become changeable **without stopping the server**, and your existing config file is read once and carried over on any loader, so nothing is lost. Alex's Mobs Continued 2.0.15 is the first mod to use it. ### For developers - **`codx.codxlib.api.settings.CodxSettings`** — a loader-neutral config spec whose builder mirrors `ForgeConfigSpec.Builder` (`push`/`pop`/`comment`/`define`/`defineInRange`/`defineList`/ `configure`), so porting is a change of import. `CodxSettingsCommand.node(...)` generates the whole command tree from a spec; `CodxSettingsMenu.builder(spec)` generates the chest menu. Gson-backed, comments written as sibling `"// name"` keys, `Builder#legacyFiles(...)` imports an older file. ⚠️ Writes don't bake themselves — pass `Builder#onChange` if you copy handles into static fields. - **`ModInfo` names CurseForge too** — two new components, `curseforgeSlug` (for the link) and `curseforgeProjectId` (for the version check; the two routes need different keys). The old 4-argument constructor and `ModInfo.of(id, slug, version)` still compile unchanged, and CodxLib already knows the ids of the published codx mods, so existing ones get correct links with no rebuild. - **Menu toolkit**: `CodxMenuLayout#adjustDouble`, `CodxMenuLayout#cycle`, and `PagedMenuBuilder#decorate` (a widget applied to every page). **Compatibility:** everything from 1.3.x is unchanged. Only a mod that wants the settings system has to raise its `codxlib` range to `[1.4.0,)`.

# CodxLib 1.4.0 *This file is for **Forge 1.21.9**. Every loader ships the same CodxLib version, so the notes below apply here too.* **Update notices link to both stores again.** A notice now ends in a clickable **Modrinth** and **CurseForge** link, and you click whichever you installed the mod from. 1.3.6 had removed the link entirely because pointing at one store sent about half of you to the wrong place — offering both is the better answer to that. Both stores are also now checked for the newer version, so a release notifies you even if it has only landed on one of them so far. This applies to every codx mod, and only CodxLib needs updating for it. **New: a shared settings system for mods built on CodxLib.** A mod declares its options once and gets four things from that one declaration: the JSON config file, a `/… config` command, an in-game chest menu, and the handles its own code reads. Nothing changes for you unless a mod uses it — CodxLib on its own still adds no commands or menus of its own. When a mod does move onto it, its settings become changeable **without stopping the server**, and your existing config file is read once and carried over on any loader, so nothing is lost. Alex's Mobs Continued 2.0.15 is the first mod to use it. ### For developers - **`codx.codxlib.api.settings.CodxSettings`** — a loader-neutral config spec whose builder mirrors `ForgeConfigSpec.Builder` (`push`/`pop`/`comment`/`define`/`defineInRange`/`defineList`/ `configure`), so porting is a change of import. `CodxSettingsCommand.node(...)` generates the whole command tree from a spec; `CodxSettingsMenu.builder(spec)` generates the chest menu. Gson-backed, comments written as sibling `"// name"` keys, `Builder#legacyFiles(...)` imports an older file. ⚠️ Writes don't bake themselves — pass `Builder#onChange` if you copy handles into static fields. - **`ModInfo` names CurseForge too** — two new components, `curseforgeSlug` (for the link) and `curseforgeProjectId` (for the version check; the two routes need different keys). The old 4-argument constructor and `ModInfo.of(id, slug, version)` still compile unchanged, and CodxLib already knows the ids of the published codx mods, so existing ones get correct links with no rebuild. - **Menu toolkit**: `CodxMenuLayout#adjustDouble`, `CodxMenuLayout#cycle`, and `PagedMenuBuilder#decorate` (a widget applied to every page). **Compatibility:** everything from 1.3.x is unchanged. Only a mod that wants the settings system has to raise its `codxlib` range to `[1.4.0,)`.

# CodxLib 1.4.0 *This file is for **Fabric 1.21.9**. It requires **Fabric Loader 0.17.0 or newer** — exactly what Fabric API already needs on 1.21.9, so CodxLib adds no restriction of its own.* **Update notices link to both stores again.** A notice now ends in a clickable **Modrinth** and **CurseForge** link, and you click whichever you installed the mod from. 1.3.6 had removed the link entirely because pointing at one store sent about half of you to the wrong place — offering both is the better answer to that. Both stores are also now checked for the newer version, so a release notifies you even if it has only landed on one of them so far. This applies to every codx mod, and only CodxLib needs updating for it. **New: a shared settings system for mods built on CodxLib.** A mod declares its options once and gets four things from that one declaration: the JSON config file, a `/… config` command, an in-game chest menu, and the handles its own code reads. Nothing changes for you unless a mod uses it — CodxLib on its own still adds no commands or menus of its own. When a mod does move onto it, its settings become changeable **without stopping the server**, and your existing config file is read once and carried over on any loader, so nothing is lost. Alex's Mobs Continued 2.0.15 is the first mod to use it. ### For developers - **`codx.codxlib.api.settings.CodxSettings`** — a loader-neutral config spec whose builder mirrors `ForgeConfigSpec.Builder` (`push`/`pop`/`comment`/`define`/`defineInRange`/`defineList`/ `configure`), so porting is a change of import. `CodxSettingsCommand.node(...)` generates the whole command tree from a spec; `CodxSettingsMenu.builder(spec)` generates the chest menu. Gson-backed, comments written as sibling `"// name"` keys, `Builder#legacyFiles(...)` imports an older file. ⚠️ Writes don't bake themselves — pass `Builder#onChange` if you copy handles into static fields. - **`ModInfo` names CurseForge too** — two new components, `curseforgeSlug` (for the link) and `curseforgeProjectId` (for the version check; the two routes need different keys). The old 4-argument constructor and `ModInfo.of(id, slug, version)` still compile unchanged, and CodxLib already knows the ids of the published codx mods, so existing ones get correct links with no rebuild. - **Menu toolkit**: `CodxMenuLayout#adjustDouble`, `CodxMenuLayout#cycle`, and `PagedMenuBuilder#decorate` (a widget applied to every page). **Compatibility:** everything from 1.3.x is unchanged. Only a mod that wants the settings system has to raise its `codxlib` range to `[1.4.0,)`.

# CodxLib 1.4.0 *This file is for **NeoForge 1.21.8**. Every loader ships the same CodxLib version, so the notes below apply here too.* **Update notices link to both stores again.** A notice now ends in a clickable **Modrinth** and **CurseForge** link, and you click whichever you installed the mod from. 1.3.6 had removed the link entirely because pointing at one store sent about half of you to the wrong place — offering both is the better answer to that. Both stores are also now checked for the newer version, so a release notifies you even if it has only landed on one of them so far. This applies to every codx mod, and only CodxLib needs updating for it. **New: a shared settings system for mods built on CodxLib.** A mod declares its options once and gets four things from that one declaration: the JSON config file, a `/… config` command, an in-game chest menu, and the handles its own code reads. Nothing changes for you unless a mod uses it — CodxLib on its own still adds no commands or menus of its own. When a mod does move onto it, its settings become changeable **without stopping the server**, and your existing config file is read once and carried over on any loader, so nothing is lost. Alex's Mobs Continued 2.0.15 is the first mod to use it. ### For developers - **`codx.codxlib.api.settings.CodxSettings`** — a loader-neutral config spec whose builder mirrors `ForgeConfigSpec.Builder` (`push`/`pop`/`comment`/`define`/`defineInRange`/`defineList`/ `configure`), so porting is a change of import. `CodxSettingsCommand.node(...)` generates the whole command tree from a spec; `CodxSettingsMenu.builder(spec)` generates the chest menu. Gson-backed, comments written as sibling `"// name"` keys, `Builder#legacyFiles(...)` imports an older file. ⚠️ Writes don't bake themselves — pass `Builder#onChange` if you copy handles into static fields. - **`ModInfo` names CurseForge too** — two new components, `curseforgeSlug` (for the link) and `curseforgeProjectId` (for the version check; the two routes need different keys). The old 4-argument constructor and `ModInfo.of(id, slug, version)` still compile unchanged, and CodxLib already knows the ids of the published codx mods, so existing ones get correct links with no rebuild. - **Menu toolkit**: `CodxMenuLayout#adjustDouble`, `CodxMenuLayout#cycle`, and `PagedMenuBuilder#decorate` (a widget applied to every page). **Compatibility:** everything from 1.3.x is unchanged. Only a mod that wants the settings system has to raise its `codxlib` range to `[1.4.0,)`.

# CodxLib 1.4.0 *This file is for **Forge 1.21.8**. Every loader ships the same CodxLib version, so the notes below apply here too.* **Update notices link to both stores again.** A notice now ends in a clickable **Modrinth** and **CurseForge** link, and you click whichever you installed the mod from. 1.3.6 had removed the link entirely because pointing at one store sent about half of you to the wrong place — offering both is the better answer to that. Both stores are also now checked for the newer version, so a release notifies you even if it has only landed on one of them so far. This applies to every codx mod, and only CodxLib needs updating for it. **New: a shared settings system for mods built on CodxLib.** A mod declares its options once and gets four things from that one declaration: the JSON config file, a `/… config` command, an in-game chest menu, and the handles its own code reads. Nothing changes for you unless a mod uses it — CodxLib on its own still adds no commands or menus of its own. When a mod does move onto it, its settings become changeable **without stopping the server**, and your existing config file is read once and carried over on any loader, so nothing is lost. Alex's Mobs Continued 2.0.15 is the first mod to use it. ### For developers - **`codx.codxlib.api.settings.CodxSettings`** — a loader-neutral config spec whose builder mirrors `ForgeConfigSpec.Builder` (`push`/`pop`/`comment`/`define`/`defineInRange`/`defineList`/ `configure`), so porting is a change of import. `CodxSettingsCommand.node(...)` generates the whole command tree from a spec; `CodxSettingsMenu.builder(spec)` generates the chest menu. Gson-backed, comments written as sibling `"// name"` keys, `Builder#legacyFiles(...)` imports an older file. ⚠️ Writes don't bake themselves — pass `Builder#onChange` if you copy handles into static fields. - **`ModInfo` names CurseForge too** — two new components, `curseforgeSlug` (for the link) and `curseforgeProjectId` (for the version check; the two routes need different keys). The old 4-argument constructor and `ModInfo.of(id, slug, version)` still compile unchanged, and CodxLib already knows the ids of the published codx mods, so existing ones get correct links with no rebuild. - **Menu toolkit**: `CodxMenuLayout#adjustDouble`, `CodxMenuLayout#cycle`, and `PagedMenuBuilder#decorate` (a widget applied to every page). **Compatibility:** everything from 1.3.x is unchanged. Only a mod that wants the settings system has to raise its `codxlib` range to `[1.4.0,)`.

# CodxLib 1.4.0 *This file is for **Fabric 1.21.8**. It requires **Fabric Loader 0.16.13 or newer** — exactly what Fabric API already needs on 1.21.8, so CodxLib adds no restriction of its own.* **Update notices link to both stores again.** A notice now ends in a clickable **Modrinth** and **CurseForge** link, and you click whichever you installed the mod from. 1.3.6 had removed the link entirely because pointing at one store sent about half of you to the wrong place — offering both is the better answer to that. Both stores are also now checked for the newer version, so a release notifies you even if it has only landed on one of them so far. This applies to every codx mod, and only CodxLib needs updating for it. **New: a shared settings system for mods built on CodxLib.** A mod declares its options once and gets four things from that one declaration: the JSON config file, a `/… config` command, an in-game chest menu, and the handles its own code reads. Nothing changes for you unless a mod uses it — CodxLib on its own still adds no commands or menus of its own. When a mod does move onto it, its settings become changeable **without stopping the server**, and your existing config file is read once and carried over on any loader, so nothing is lost. Alex's Mobs Continued 2.0.15 is the first mod to use it. ### For developers - **`codx.codxlib.api.settings.CodxSettings`** — a loader-neutral config spec whose builder mirrors `ForgeConfigSpec.Builder` (`push`/`pop`/`comment`/`define`/`defineInRange`/`defineList`/ `configure`), so porting is a change of import. `CodxSettingsCommand.node(...)` generates the whole command tree from a spec; `CodxSettingsMenu.builder(spec)` generates the chest menu. Gson-backed, comments written as sibling `"// name"` keys, `Builder#legacyFiles(...)` imports an older file. ⚠️ Writes don't bake themselves — pass `Builder#onChange` if you copy handles into static fields. - **`ModInfo` names CurseForge too** — two new components, `curseforgeSlug` (for the link) and `curseforgeProjectId` (for the version check; the two routes need different keys). The old 4-argument constructor and `ModInfo.of(id, slug, version)` still compile unchanged, and CodxLib already knows the ids of the published codx mods, so existing ones get correct links with no rebuild. - **Menu toolkit**: `CodxMenuLayout#adjustDouble`, `CodxMenuLayout#cycle`, and `PagedMenuBuilder#decorate` (a widget applied to every page). **Compatibility:** everything from 1.3.x is unchanged. Only a mod that wants the settings system has to raise its `codxlib` range to `[1.4.0,)`.