Included content
| Name | |
|---|---|
![]() | Static Data |
The main reason for this release is to fix a pretty bad bug where scarves fail to position correctly when Sodium is present. A lot of math is "factored out" by Sodium, resulting in efficient reuse of pre-computed values, but this prevents me from grabbing some data directly off the models. If Sodium is detected, the missing data is estimated. It's not perfect, but it's actually pretty darn close considering what is lost.
Known bugs in this system: Elytra flight, especially in third person, has poor scarf adhesion. This has always been a problem case because the player doesn't lean from the same pivot that they do when swimming or crouching.
This release also cuts two mixins by moving some information from code to data. Bees and foxes are implemented internally using the same system mods can use to add their own support for scarves.
To add support, you need to do two things:
scarves/slot_configs path. (as in, src/main/resources/staticdata/scarves/slot_configs/whatever.json). You don't need to depend on staticdata, just have the json in your mod jar. Check the Scarves source for examples, or ask me for details!Known bugs in this system: Tameable entities that prioritize sitting over item use, such as cats and wolves, will prevent the scarf item from pinning to them automatically. Additionally, highly animated entities may visually "bug out" or flicker if scarves are pinned to a modelpart like "body" instead of "". Minecraft's animations appear to rely on stateful behavior in the entity model. Pin to the entity root if possible, it's faster!
| Name | |
|---|---|
![]() | Static Data |
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.
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:vhY4Cys8:OdqtKB6n"
}
// Legacy Loom dependency
dependencies {
modImplementation "maven.modrinth:vhY4Cys8:OdqtKB6n"
}