Download File

# CodxLib 1.3.5 *This file is for **Forge 1.20.1**. Every loader ships the same CodxLib version, so the notes below apply here too.* **Fixes update notifications naming the wrong mod loader.** On Fabric you could be told that a NeoForge file was available — and if you followed it, you'd download a jar your game can't load. The notice looked like this on a Fabric client: > [OneBlock] Update available: 3.3.1+26.1.2-neoforge (current 3.2.0) The version number was right; the file it pointed at was not. **No API changes.** This is purely a fix to the update checker. ### For players / server admins - **Update notices now only mention builds for the loader you're actually running.** A Fabric game is offered the Fabric file, NeoForge the NeoForge file, and so on. - This affects **every codx mod** that uses CodxLib's update checker — OneBlock, CleanHUD, QuickCraft, Reflex, Health-hud, EnhancedTooltips, Chunky-Extended, ElytraPlus. You only need to update CodxLib; the mods themselves are unchanged. - If a notice previously sent you to the wrong file, nothing is broken — the wrong-loader jar simply wouldn't have loaded. Grab the file matching your loader as usual. - Nothing else changed: `/codxlib versions`, `/codxlib help`, and the rest behave exactly as in 1.3.4. ### For developers (consumer mods) - **No API changes.** `codx.codxlib.api.*` is unchanged from 1.3.4, so there's nothing to adjust in your code or your `codxlib` version range. - Cause, in case you have your own checker: the Modrinth version query asked for all three loaders at once and then picked the newest version number. When every loader publishes the *same* version of a release, that comparison is a tie, so the winner was whichever entry the API happened to return first. The query is now filtered to the running loader (`Services.PLATFORM.getLoaderName()`), which is the real fix — a tie-break wouldn't have helped, since all three were equally "newest".