v1.8.2

Full Changelog: v1.8.1...v1.8.2

v1.8.1

Full Changelog: v1.8.0...v1.8.1

v1.8.0

Full Changelog: v1.7.2...v1.8.0

DayZ Inventory 1.7.2 — corrected Fabric files

DayZ Inventory 1.7.2 — the Fabric files were development jars; this fixes that

If you downloaded DayZ Inventory for 1.21.1 or 1.21.11 on Fabric from the 1.7.1 release, replace
it with 1.7.2. Those two files were Loom's development jar and will not work in a normal
game. Nothing else was affected: 26.2 on Fabric and every NeoForge and Forge file were correct, and
the jars attached to the GitHub releases were always correct.

The mod itself is unchanged.

What went wrong

Below 26.1 Minecraft is obfuscated, and Loom splits the build in two:

• its jar task writes a development jar named <...>-dev.jar, compiled against official
  Mojang names, into build/devlibs;
• its remapJar task writes the shippable jar, remapped to intermediary names, into
  build/libs.

The publish configuration picked between them with tasks.names.contains("remapJar"), intending
"use remapJar when Loom provides one". But Loom registers remapJar from its own afterEvaluate,
which runs after the publish configuration is set up, so the check was always false and the
development jar was the one uploaded. Both Fabric nodes below 26.1 were affected; 26.2 has no remap
step at all, which is why it was fine.

The selection now uses the Minecraft version — the same condition loom-back-compat uses to choose
the Loom flavour — and the task is resolved after evaluation. A build-time check refuses to publish
anything whose name contains -dev, so a regression fails loudly instead of reaching users.

The matching Modrinth versions have been deleted. The two CurseForge files have to be removed from
the project dashboard by hand, because the upload token cannot delete files.

---

Full Changelog: v1.7.1...v1.7.2

DayZ Inventory 1.7.1 — now actually on Modrinth and CurseForge

DayZ Inventory 1.7.1 — the same build, actually on Modrinth and CurseForge

Same code as 1.7.0. This release exists because 1.7.0's automated publishing run stopped partway:
the CurseForge upload was rejected and, because Gradle aborts on the first failure, most of the
Modrinth uploads never ran either.

Two build bugs caused it, both fixed here:

• The token fallback did not work. MODRINTH_TOKEN / CURSEFORGE_API_KEY were read with
  Provider.orElse, which only falls back when a variable is absent — but CI forwards every
  accepted name, so the unset ones arrived as empty strings and shadowed
  MODRINTH_TOKEN / CURSEFORGE_TOKEN, which were both set. The lookup now ignores blank values.
• The published version number was the bare mod version, so every Minecraft version of the same
  release wanted the same number in the same Modrinth project. It is now 1.7.1+mc<version>, which
  also matches the jar filenames.

./gradlew publishModrinthAll and ./gradlew publishCurseforgeAll were added so one platform can
be re-run on its own, and the publish job can now be started by hand with a platform selector.

Nothing about the mod changed.

---

Full Changelog: v1.7.0...v1.7.1

DayZ Inventory 1.7.0 — Forge on 1.21.1

DayZ Inventory 1.7.0 — Forge on 1.21.1, and the whole matrix publishes itself

Forge support is back, on 1.21.1. The unified build now produces seven jars from one source
tree: Fabric and NeoForge for 26.2, 1.21.11 and 1.21.1, plus Forge for 1.21.1.

Nothing about the inventory screen changed. The Vicinity grid, Proximity Scanner, 2x2 crafting, the
2.0x Hands slot, drag-to-equip and every optional integration behave exactly as before.

What is available now

Minecraft	Fabric	NeoForge	Forge	Java
26.2	✅	✅	—	25
1.21.11	✅	✅	—	21
1.21.1	✅	✅	✅	21

Forge stopped at 1.20.x — the ecosystem moved to NeoForge — so 1.21.1 is the newest version Forge
can be built for at all.

Why Forge needed real work

The Forge module was still the 1.20.1-era SimpleChannel / NetworkRegistry /
registerMessage stack, which no longer exists. It has been ported to the same typed-payload model
the Fabric and NeoForge modules use, against net.minecraftforge packages, and shares the same
DayZInventoryPayload and packet-dispatch code as the rest of the mod.

Building it took three attempts, which is worth writing down:

• ForgeGradle 6 only supports Gradle 8, and the newer Minecraft targets need Gradle 9 for Loom.
• ModDevGradle's legacyforge asks for net.minecraftforge:forge:<version>:universal-srg — a
  classifier that only exists for the pre-1.20.2 SRG layout — so it cannot build 1.21.1 at all.
• ForgeGradle 7 is the rewrite that runs on Gradle 9, and is what the module now uses.

Since Forge has run on official Mojang names since 1.20.2, there is no reobfuscation step and no
Searge refmap, exactly as on NeoForge.

1.20.1 is still on its own branch

1.20.1 predates the 1.20.5 networking rewrite — no custom payload records, and
ExtendedScreenHandlerType does not take an opening-data codec yet — so it needs a genuine source
port rather than a rebuild. It keeps shipping from the 1.20.1 branch, and the exact breakpoints
are documented in docs/BUILDING.en.md for whoever picks it up.

Publishing

Every jar now goes up with its own Minecraft version and loader tags, read from the build rather than
typed per release, so nothing can be filed under the wrong game version. ./gradlew publishAll
publishes the matrix; on a v* tag CI builds everything, attaches the jars to the GitHub Release and
publishes to both platforms.

Note that CurseForge routes every upload through human review and never returns a link, so a green
CurseForge run means submitted, not live.

---

Full Changelog: v1.6.0...v1.7.0

DayZ Inventory 1.6.0 — one source tree, three Minecraft versions

DayZ Inventory 1.6.0 — one source tree, three Minecraft versions

The mod is unchanged. How it is built is not.

Until now every Minecraft version lived on its own Git branch: main for 1.20.1, and 1.21.1,
1.21.11 and 26.2 alongside it. A bug fix had to be merged into each of them, and each merge had
to be built and tested on its own. This release replaces that with a single branch that builds
1.21.1, 1.21.11 and 26.2 for both Fabric and NeoForge from one source tree, and publishes all of
them automatically.

Nothing about the inventory screen changed. The Vicinity grid, Proximity Scanner, 2x2 crafting, the
2.0x Hands slot, drag-to-equip and every optional integration behave exactly as before.

What this means for you

• Download the same way. The files on Modrinth and CurseForge are still one per Minecraft
  version and loader; the names now look like dayz-inventory-fabric-26.2-1.6.0+mc26.2.jar, with the
  Minecraft version spelled out.
• 1.20.1 is not gone. The 1.20.1 files (Fabric and Forge) remain published and still work. They
  come from the older per-version build and are not part of the unified tree yet — see below.
• Forge is not in the unified tree either. Forge stopped at 1.20.x, so the only Forge targets
  ever were 1.20.1 and 1.21.1.

How it is built now

Stonecutter preprocesses one shared source tree for several
Minecraft versions, and the loader modules stay exactly as they were:

common/     loader-agnostic code, shared by every version
fabric/     Fabric entrypoints
neoforge/   NeoForge entrypoints
forge/      legacy Forge module (present, not built)

Version differences are marked inline with //? if comments, so a method whose signature changed
between 1.21.1 and 26.2 reads as one file with the two variants next to each other instead of as two
branches that drift apart. Renames that touch dozens of lines — ResourceLocation to Identifier,
isClientSide to isClientSide(), GuiGraphics to GuiGraphicsExtractor — are declared once in the
build and applied automatically.

Minecraft	Fabric	NeoForge	Java
26.2	✅	✅	25
1.21.11	✅	✅	21
1.21.1	✅	✅	21

./gradlew chiseledBuild          # every version × every loader
./gradlew :fabric:26.2:build     # one target

Automated publishing

Every jar is now published with its own Minecraft version and loader tags, taken from
versions/<mc>/gradle.properties rather than typed per release, so an artifact can no longer go up
under the wrong game version. ./gradlew publishAll releases the whole matrix; on a v* tag CI
builds everything, attaches the jars to the GitHub Release and publishes to both platforms.

Note that CurseForge routes every upload through human review: the API accepts the file and never
returns a link, so a green CurseForge run means submitted, not live.

Still to come

1.20.1 and Forge are scaffolded but not ported. 1.20.1 predates the 1.20.5 networking rewrite, so it
has no custom payload records at all, and forge/ still holds 1.20.1-era SimpleChannel code. The
breakpoints are written down in docs/BUILDING.en.md so the port is a matter of following the list.

---

What's Changed

• refactor: unify via Stonecutter, multi-version + multi-loader, automated CF/Modrinth publishing by @aacanadaa in #4

Full Changelog: v1.4.3...v1.6.0

v1.5.0

Full Changelog: v1.4.0...v1.5.0

v1.4.3

Full Changelog: v1.4.2...v1.4.3

v1.4.2-1.21.1

What's Changed

• Add a Minecraft Forge build for 1.21.1 (1.4.2) by @aacanadaa in #1

Full Changelog: v1.4.0-1.21.1...v1.4.2-1.21.1

What's Changed

• Add a Minecraft Forge build for 1.21.1 (1.4.2) by @aacanadaa in #1

New Contributors

• @aacanadaa made their first contribution in #1

Full Changelog: v1.4.0-1.21.1...v1.4.2-1.21.1