1.1.1
Compatibility
Changes
Fix bug:
● The reflection was looking for relevantPartsByName directly on PosableEntityModel's superclass, but in Cobblemon 1.7.x that field was moved to a separate
PosableModel object, accessed via a posableModel field on the entity model. So the old single-step lookup always failed with NoSuchFieldException.
The fix does a two-step reflection: first it gets the posableModel field from the entity model instance, then it reads relevantPartsByName from that composed
object. It also walks the full class hierarchy instead of only checking one superclass level, and keeps a fallback for older Cobblemon versions where the field
lived directly on the model.
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:UnZwG5gK:LSxFbkSe"
}
// Legacy Loom dependency
dependencies {
modImplementation "maven.modrinth:UnZwG5gK:LSxFbkSe"
}

