3.0
Compatibility
Changes
Config Overhaul & More
- The configuration menu has been completely reworked.
- Added the ability to grant non-admin players access to the config menu.
- The world owner no longer needs operator permissions to edit the config. (This allows config changes in hardcore worlds and worlds without cheats enabled.)
The world owner is defined as the first player who joins the world. They are granted access to the config. This access can be revoked using a command (detailed further down).
New Config Options:
Armor bypass: If enabled, damage from the black flash will ignore armor.
Cooldown: The cooldown between black flashes is now configurable.
Heal: The black flash can now heal the player. Set the value to 0 to disable healing.
Other changes:
- Fixed the "Entity HP affects chance" config.
- Added descriptions for all config options.
- Black flash damage now bypasses entity invincibility frames.
- New black flash particles.
- Reworked the spawning logic for black flash particles.
- Some advancement icons have been redrawn.
- Some advancement icons are now animated.
- The overlay has been improved; it now fades out much more smoothly.
- Fixed a server-client synchronization issue that previously prevented some configs from being changed without using commands.
- Removed the server synchronization warning message.
- Removed the old /blackflash commands.
- Added new /blackflash commands:
/blackflash accessToConfig grant Player-Target- Grants access to the config./blackflash accessToConfig revoke Player-Target- Grants access to the config` - Revokes access to the config./blackflash config- Opens the config menu.
All of these commands require an execution permission level 4 (i.e., operator rights).
- Some other minor changes that I don't remember.
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:YIxVXqog:O3fdm7bc"
}
// Legacy Loom dependency
dependencies {
modImplementation "maven.modrinth:YIxVXqog:O3fdm7bc"
}

