Tags
Creators
Details
Licensed LGPL-3.0-only
Published 3 years ago
All versions
2.2.2
Release
NeoForge - 1.212 years ago 3,545
Compatibility
Minecraft: Java Edition
1.21–1.21.1
Platform
NeoForge
Supported environments
Client-side
Required content
Changes
- now requires ETF 6.2.1 or newer
- fixed a model setup error that would break villager and warden, clothing and glowing textures with custom models that declared textures
- is_hover now respects the players current block interaction range for block entities
- id variable now matches OptiFine's value exactly
- reworked the player_cape.jem implementation to be more mod compatible, e.g.
wavey capesmod can now correctly overwrite it & essentials works with it now - swapped subfolder load priority for models.
optifine/cem/skeleton/skeleton.jemnow loads beforeoptifine/cem/skeleton.jemmatching optifine behaviour - added an OptiFine compat setting to require submodel folders to have variants, e.g.
optifine/cem/skeleton/skeleton.jemwill not load without aoptifine/cem/skeleton/skeleton2.jemor a valid .properties file. - model exports no longer print rotation float values as doubles
- model exports now also log all box values for exported and non-exported parts
- fixed texture overrides not applying to
attach=trueor vanilla parts - fixed animations breaking when the same part transform or variable is declared / updated more than once over all the animation entries
- added tickdelta to the death time variable (fixes jittering in packs like skeleton death physics)
- fixed not all instances of
thisbeing correctly resolved in animation math - added spelling correction warnings for frequently misspelled variables like
is_aggressive - variables not being found now log as errors rather than warnings and will now correctly default to false for unknown booleans
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:4I1XuqiY:ea3GXWH4"
}
// Legacy Loom dependency
dependencies {
modImplementation "maven.modrinth:4I1XuqiY:ea3GXWH4"
}![[EMF] Entity Model Features](https://cdn.modrinth.com/data/4I1XuqiY/6e5bbd0d06b1741bfdab6c0cfab6de8fdaf0064c_96.webp)


