Tags
Creators
Details
Licensed MIT
Published 3 weeks ago
Updated last month
All versions
5.5.0
Release
Kagurabachi Craft 5.5.0last month 49
Compatibility
Minecraft: Java Edition
1.21.1
Platform
NeoForge
Supported environments
Client and server
Changes
Kagurabachi Craft 5.5.0 NPC Signatures & Encounters Update
- Combat NPCs can now use their canonical signature techniques.
- Samura can now use Iai, while Chihiro Masumi uses a deliberately weaker Iai variant.
- Hiruhiko can now use his signature Freedom Style technique.
- Azami can now use his signature Villains' Execution technique.
- Added server-owned NPC signature movement, action locks, cooldowns and cleanup.
- Expanded NPC combat decision-making, ability selection and encounter balance.
- Added Azami Kamunabi with a dedicated combat kit and presentation.
- Added Ariu Mikaboshi and the Mikaboshi NPC faction.
- Expanded Chihiro Masumi, Hiruhiko, Hiyuki, Samura and Azami combat kits.
- Canonicalized NPC identities, spawn eggs, faction tags and combat profiles.
- Refined the True Realm of Sumika cinematic and spatial piercing VFX.
- Fixed camera restoration after death during the Sumika cinematic.
- Restored legacy Coin Sorcery VFX and aligned Ariu with canonical Sumika combat.
- Expanded Samura's Suzaku and Black Flames combat behavior.
- Improved NPC damage scaling, cooldown handling, fatigue and combat reactions.
- Raised Samura Traitor to Sorcery Level 18 and adjusted encounter balance.
- Reworked English and Russian faction, rank, contract, trainer and vendor localization.
- Replaced artificial faction titles with lore-aligned Hishaku and Kamunabi terminology.
- Expanded regression coverage for NPC signatures, identities, encounters and combat balance.
- Updated public documentation, NPC framework references and command guides.
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:OskTPBVe:gninQ2AG"
}
// Legacy Loom dependency
dependencies {
modImplementation "maven.modrinth:OskTPBVe:gninQ2AG"
}

