1.4.5+26.2
Compatibility
Changes
1.4.5
This release ports the mod to the now-stable Minecraft 26.3, plus one real bug fix found while double-checking the mod's health beyond the porting itself. No changes to the public API; every method/event/DTO documented for 1.4.4 behaves exactly as before.
Minecraft 26.3 support
- Minecraft 26.3 is now a fully supported version, no longer marked experimental. The previous
release's
26.3 Pre-Release 1jar is replaced by a jar built against the final stable 26.3. - Fabric Loader requirement raised to
0.19.5(from0.19.3) for all three published versions (26.1, 26.2, 26.3), matching the official recommendation for 26.3. This is a backward-compatible bump — it doesn't change anything for players already on 26.1/26.2. - The two compatibility shims added for the 26.3 pre-release (an internal input-type rename, and an advancement-display API that changed shape) needed no changes for the stable release — verified by diffing the actual game/API classes the mod touches between the pre-release and the stable build, not just by compiling.
- Fabric API bumped to
0.160.5+26.3for the 26.3 jar.
Fixed
- Memory/VRAM leak when playing multiple worlds in one session. 1.4.4 fixed the leak that happened when deleting a photo from the World Journal. This release fixes the other half of the same problem: browsing journal photos in a world, then leaving it (back to the title screen, or into a different world) never freed those photos' GPU textures — they stayed allocated for the rest of the game session. A session that visits several worlds and looks at photos in each one now releases each world's photo textures on disconnect, instead of accumulating them indefinitely.
Compatibility
No settings, journal file format, or dependency changes beyond the Fabric Loader bump above — updating from 1.4.4 requires no action.
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:DinbWefJ:cRMVvFsT"
}
// Legacy Loom dependency
dependencies {
modImplementation "maven.modrinth:DinbWefJ:cRMVvFsT"
}

