Tags
Creators
Details
Licensed LGPL-3.0-or-later
Published last week
All versions
2.6.4
Release
InvCatalogue 2.6.4 for Minecraft 1.21.11last month 1
Uploaded by
Compatibility
Minecraft: Java Edition
1.21.11
Platform
Fabric
Supported environments
Client-side
Required content
Any compatible version
Changes
Changed
- Changed the repo and Fabric metadata license to LGPL-3.0-only to match the Modrinth projects.
- Added
AGENTS.mdwith the project workflow for updatingTODO.md, updating this changelog, verifying, and committing after each major change. - Recorded the split and multi-version migration roadmap in
TODO.mdso it survives future context compaction. - Added the initial Core foundation with shared mod id/logger ownership and event contracts for namespace changes, container snapshots, and inventory snapshots.
- Routed container/inventory snapshot handling and namespace-change handling through Core events, with Search and Catalogue now subscribed via feature bridge classes.
- Split catalogue and world-profile command implementation into separate command classes.
- Moved split-mod commands to feature-specific roots:
/inventorycatalogue ...,/inventorycatalogue world ..., and/inventorysearch world .... - Split sort/search screen-button ownership and added separate Core/Search/Catalogue client entrypoints as preparation for public modules.
- Added Gradle subprojects for Core, Sort, Search, and Catalogue. The three public feature jars now build separately and each nests the shared Core jar.
- Added
collectReleaseJarsand updatedbuildAllModsso publish-ready Sort, Search, and Catalogue jars are collected underbuild/release/<profile_id>/. - Added Minecraft version profiles and upgraded the Gradle wrapper to 9.4.0 so 26.x migration profiles can be configured separately from the current release target.
- Extended Minecraft version profiles into compatibility-group build profiles with
profile_id,minecraft_dependency,modrinth_game_versions, andcompat_groupmetadata. - Release jars now collect under
build/release/<profile_id>/, andverifyReleaseJarschecks generated Fabric metadata against the active profile. - Added
src/compat/<compat_group>/overlay wiring for version-specific API adapter sources. - Added separate public mod icon assets for Inventory Sort, Inventory Search, and Inventory Catalogue, and wired each module's Fabric metadata to its own icon.
- Added CI validation tasks for supported and candidate Minecraft profiles, including a smoke-test matrix gate for publishable profiles.
- Added automated client smoke launches through a dedicated
smokelaunchproject. CI now launches packaged release jars as Sort-only, Search-only, Catalogue-only, and all-three installs across the validation runtimes. - Added a
1.21.9-1.21.10candidate compatibility profile that compiles and builds release jars with range metadata, and now passes automated client smoke launches on both1.21.9and1.21.10. - Added broad candidate compatibility groups for
1.21.6-1.21.8,1.21-1.21.5,1.20.5-1.20.6, and1.20-1.20.4, with exact runtime smoke profiles for every covered1.20.xand1.21.xversion. - Added compatibility shims for older Minecraft API shapes, including chest neighbor lookup, window handle access, HUD pose/matrix calls, single-player server directory paths, item stack components vs tags, recipe book screen presence, mouse wheel method signatures, and older button render overrides.
- Recorded passing automated smoke results for the full
1.20.xand1.21.xcandidate matrix. These profiles remain non-publishable until deliberately promoted from candidate to supported. - Added
publishValidationandsmokeTestSupportedClientsas a fast supported-only pre-publish gate, plussmokeTestSelectedClientsfilters for local smoke-test spot checks. - Added guarded Modrinth publishing automation for the three public projects,
including dry-run upload planning, supported-profile-only publishing, token
handling through
MODRINTH_TOKEN, and a manual GitHub Actions workflow. - Bumped the focused Modrinth validation release to
2.6.4and corrected the InvSearch project id used by publishing automation. - Moved target-specific custom button render hooks into
1.21.9-1.21.10and1.21.11compat overlays while keeping the shared drawing logic in Core. - Added
COMPATIBILITY.mdwith the Minecraft version probe matrix and Modrinth listing recommendation. - Confirmed the current split release jars should be published for Minecraft
1.21.11only until version-specific builds pass compile and launch testing. - Documented the compatibility-group profile strategy: one build profile may produce one jar for a tested range of Minecraft versions, with CI smoke testing required before Modrinth publishing.
- Expanded the roadmap so CI validation becomes step 8 and Modrinth publishing automation moves to step 9.
- Confirmed the rebuilt split release jars launch in normal launcher installs individually and together.
Fixed
- Fixed split release jars embedding the development-namespaced Core jar, which could crash client entrypoints in normal launcher installs. Public jars now embed the remapped Core jar and
clean buildverifies this. - Corrected the Fabric metadata icon path to use the checked-in
assets/inventory-sort/icon.pngasset. verifyReleaseJarsnow checks that each public jar's declared icon path is present in the packaged jar.- GitHub Actions now runs
ciValidation, building both supported and candidate profile artifacts while keeping pending smoke tests out of the publishable set. - Fixed the first
1.21.9-1.21.10compile blockers by adapting dimension id access and avoiding version-specific minecart entity class imports in shared identity code. - Fixed broad
1.20.xand earlier1.21.xcompile/runtime launch blockers by moving API-sensitive calls behind version-selected compat overlays.
Removed
- Removed unused Fabric template scaffolding: the unused
InventorySortinitializer, unusedExampleMixin, and unused client mixin config referencing the missingExampleClientMixin.
Projects on Modrinth are automatically available through a Maven repository for use with JVM build tools such as Gradle. To learn more about the Modrinth Maven API, click here.
Note: When available, you should use the creator's maven repo instead as it will have transitive dependency information that the Modrinth Maven API does not. You may also end up with duplicate dependencies if you use a mix of Modrinth and non-Modrinth Maven repositories for your dependencies, because the group identifier will be different when served through the Modrinth Maven API.
Maven coordinates:
Version ID:
build.gradle:
repositories {
exclusiveContent {
forRepository {
maven {
name = "Modrinth"
url = "https://api.modrinth.com/maven"
}
}
// forRepositories(fg.repository) // Uncomment when using ForgeGradle
filter {
includeGroup "maven.modrinth"
}
}
}
// Standard Gradle dependency
dependencies {
implementation "maven.modrinth:rV7fRk8Z:k3rNn4zA"
}
// Legacy Loom dependency
dependencies {
modImplementation "maven.modrinth:rV7fRk8Z:k3rNn4zA"
}

