Tags
Creators
Details
3.0.0
Compatibility
Required content
Changes
Elytra Trims 3.0 - The Doomsday Update
Update notes
- In 1.20.5, due to ItemStack changes, converted elytras will lose their glow, all other features will remain. This will be looked into in a future release, but until then you can afford an extra glow ink sac, right?
- Trimming and dyeing currently can't be disabled on the server side, as it is now controlled by tags.
Elytra preview
Elytra trims now renders elytra entity model for its item - just like shields, banners and beds do:

If you don't like it - it can be disabled in the mod config. To access it you need YACL and on Fabric Mod Menu. On Forge it is accessible via default mods menu.
Kotlin migration - who asked?
First of all, I asked. 1.20.5 brought an enormous amount of changes, which was especially bad for Elytra Trims, because it is developed for multiple Minecraft versions. Kotlin provides several ways (such as type aliases, extension and inline functions) that simplify code versioning. So here it is, cope with it.
Texture processing rewrite
Elytra Trims generates textures dynamically to adjust for dozens of trims and now unlimited amount of banner patterns.
Since I got more skill in modding and had to look through the entire codebase, this process has been optimised.
Notably:
- Elytra model mask is no longer duplicated for each texture pass.
- Armor trims are now queried from atlas definitions.
- Texture rendering now extensively uses caching and reports missing textures.
Other changes
boltandflowtrims have been added, available with 1.21 datapack (@masik16u)- DashLoader is no longer incompatible

Supplementary resources
| File | Type | Size | |
|---|---|---|---|
| elytratrims-forge-3.0.0+1.20.1-sources.jar | Unknown | 103.16 KiB |
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:XpzGz7KD:DjxSyAqI"
}
// Legacy Loom dependency
dependencies {
modImplementation "maven.modrinth:XpzGz7KD:DjxSyAqI"
}


