All versions
20.2.0
Release
Epic Fight: Tinkers Integration 20.2.03 months ago 114
Compatibility
Minecraft: Java Edition
1.20.1
Platform
Forge
Supported environments
Client and server
Required content
Any compatible version
Any compatible version
Any compatible version
Changes
Changelog
New Features
- Added modular TConstruct weapon capability profiles and move sets for better combat behavior customization.
- Added new modifier profile handling for special tools and weapons.
- New modifier-based tool behaviors now use move sets from the WOM mod where applicable.
- Added a new throwing restriction: tools with the Throwing modifier can now only be thrown while crouching in Epic Fight mode.
- Added client-side rendering support for TConstruct longbow and shield items through dedicated client mixins.
- Added support for fixing armor rendering issues on TConstruct addons.
Bug Fixes
- Fixed a crash when using Epic Fight version
20.14.16or newer. - Fixed dedicated server crash issues by moving client-only mixins out of the common mixin group.
- Fixed weapon capability resolution by replacing the old switch-case mapping with preset-based mapping.
- Fixed attribute modifier UUID conflicts by generating deterministic UUIDs per tool and stat type.
- Fixed throwing module behavior so standing throws are blocked correctly in Epic Fight mode.
Compatibility / Refactor
- Refactored TConstruct weapon capability handling into reusable capability, move set, and modifier profile classes.
- Updated mixin configuration to separate common and client-only injections properly.
- Cleaned up legacy capability code and removed obsolete javelin/shield rendering logic.
Tested against:
- Minecraft: 1.20.1
- Forge: 47.4.10
- Epic Fight: 20.14.16
- Tinkers' Construct: 3.11.2.166
- Mantle: 1.11.104
Optional dependencies
Any compatible version
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:wN34gDMH:9gxUh0SD"
}
// Legacy Loom dependency
dependencies {
modImplementation "maven.modrinth:wN34gDMH:9gxUh0SD"
}

