Tags
Creators
Details
Licensed ARR
Published 5 months ago
Updated 4 months ago
All versions
0.8.5
Beta
Lattice 0.8.54 months ago 5
Uploaded by
Compatibility
Minecraft: Java Edition
1.21.11
Platform
Paper
Changes
Added
- Added optional lifecycle failure context on
LifecycleException, including runtime id, phase, failed operation, and module id when available. - Added structured startup report entries while keeping the existing string-based startup event list.
- Added optional config failure context on
ConfigException, including config path and operation when Lattice can identify them. - Added lifecycle diagnostics details for failed runtime operations, including event count, failed operation, module id, and failure message.
Changed
- Module lifecycle callback failures now preserve module id and operation context across load, enable, ready, and disable paths.
- YAML config load, parse, render, defaults, deserialize, validate, migrate, serialize, save, and update validation failures now use context-aware
ConfigExceptionreporting. - Public diagnostics and getting-started docs now describe how plugin-owned logging and diagnostics commands can surface lifecycle and config context.
Fixed
- Lifecycle diagnostics no longer report a failure finding for a fresh runtime that has not started.
- Lifecycle diagnostics now keep an error status when a failed lifecycle entry remains after a later phase transition.
- Disable failures now use lifecycle-neutral diagnostic wording instead of startup-specific wording.
Compatibility
- Existing
LifecycleExceptionandConfigExceptionconstructors remain supported. - Existing
StartupReport#events()callers continue to receive the legacy string event list. - Structured startup report write helpers remain runtime-owned and are not exposed as stable plugin authoring API.
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:Ed95iBPq:RxZLdjEg"
}
// Legacy Loom dependency
dependencies {
modImplementation "maven.modrinth:Ed95iBPq:RxZLdjEg"
}

